
PrestaShop 8 kisokos #4: PrestaShop ügyfélkezelés mesterfokon: Így lesz a látogatóból törzsvásárló
2026-01-26SAP/ERP integráció, egyedi árak és a „kényelem csapdája” – avagy miért nem lehet egy Suzuki Swifttel kamiont vontatni.
Amikor a gyerek kinőtte a rugdalózót: Miért véreznek el a B2B nagykereskedések WordPress alatt? Valahol mindenki ugyanúgy kezdi. Egy jó ötlet, egy kis WordPress oldal, talán egy WooCommerce bővítmény, és bumm: kész a webshop. Jönnek a rendelések, csilingel a kassza, mindenki boldog. A rendszer olcsó, ismerjük, szeretjük, „kézre áll”.
De aztán történik valami. A cég nőni kezd.
Már nem 50 termék van, hanem 5000. Már nem csak Kis Pistának adunk el egy pólót, hanem a Kovács Kft.-nek szállítunk 32 raklap terméket. Belép a képbe az SAP/ERP vagy egy komoly vállalatirányítási rendszer. És hirtelen az a kedves, megszokott, kényelmes WordPress oldal elkezd köhögni. Lassul. Akad. Összeomlik.
A fejlesztő vakarja a fejét, a cégvezető dühös, a vevő pedig átmegy a konkurenciához.
Mi történt? Egyszerűen annyi, hogy kinőttétek a digitális rugdalózót.
Ebben a cikkben őszintén beszélünk arról a technológiai váltásról, ami minden sikeres kereskedőcégnél eljön: a WordPress és a dedikált e-kereskedelmi rendszerek (pl. PrestaShop) közötti választásról B2B környezetben.
A „Kényelem Csapdája”
Miért ragaszkodnak a cégek a WordPresshez még akkor is, amikor már milliárdos forgalmat bonyolítanak? A válasz emberi: a megszokás miatt. „Ezt már ismerjük, a kollégák tudják kezelni az admint.”
Ez egy veszélyes illúzió. Egy B2B nagykereskedelmi portál nem arról szól, hogy milyen színű a „Vásárlás” gomb. Itt adatbiztonságról, logisztikáról és pénzügyi folyamatokról beszélünk.
Képzeljük el, hogy egy kamiont kell elhúznunk A-ból B-be. A Suzuki Swiftünk (WordPress) eddig remekül szuperált a városban. Kényelmes az ülése. De ha mögé kötjük a 40 tonnás pótkocsit (SAP/ERP adatbázis), két dolog történhet: vagy el sem indul, vagy az első emelkedőn elég a motor.
A B2B nem csak egy „nagyra nőtt” webshop
Sokan ott tévednek, hogy azt hiszik, a nagykereskedelem csak annyiban különbözik a kiskereskedelemtől, hogy többet rendelnek. Ez óriási tévedés. A B2B egy teljesen más sportág, más szabályokkal:
-
- A „Ki vagy te?” árazás: Egy webshopban a cipő ára mindenkinek 20.000 Ft. Egy nagykerben? A „Kiemelt Partnernek” 15.000, az „Új Belépőnek” 19.000, a „Viszonteladónak” pedig sávos kedvezménye van. Ezt a logikát a WordPress csak tucatnyi, egymást gáncsoló bővítménnyel tudja (vagy nem tudja) lekezelni. A PrestaShopnál ez az alapműködés része.
- A fizetési bizalom: Itt ritka az azonnali kártyás fizetés. Itt 8 napos, 30 napos, 60 napos átutalások vannak, hitelkeretek és tartozások. Ha a webshop nem tudja valós időben, hogy a partnernek van-e még szabad hitelkerete, akkor ingyen osztogatjuk az árut.
- A logisztika súlya: Nem egy csomagot adunk fel a futárral. Raklapokról, kamionokról, telephelyekről beszélünk.
Az SAP/ERP-szörnyeteg megszelídítése
Itt érkezünk el a legfájóbb ponthoz. Amikor egy cég bevezet egy SAP Business One szintű rendszert, vagy egy ERP rendszert, azzal egy ipari teljesítményű motort kap. Ha erre rákötünk egy blogmotorból átalakított webshopot (WooCommerce), az katasztrófához vezethet.
A legnagyobb tévhit, amivel találkozunk: „Elég, ha ritkábban frissülnek az adatok.”
Ez a mondat a modern kereskedelem halála.
Képzeld el a szituációt: A partnered hétfőn reggel látja, hogy van készleten 10 raklap áru. Megrendeli. De az árut valójában már pénteken elvitte más, csak a webshop még nem frissült. Eredmény? Egy dühös partner, egy felesleges adminisztrációs kör, és hitelvesztés.
Egy professzionális B2B rendszernek közel valós időben (akár 15 percenként) kell kommunikálnia az ERP rendszerrel. Ehhez olyan stabil adatbázis-szerkezet kell, ami nem rogyik össze, ha percenként tízezer árfolyamot és készletadatot kell módosítani. A PrestaShop erre született. A WordPress nem.
Ne kémkedj az ERP-vel, használd a profitra!
Gyakori igény: „Szeretnénk látni az ERP-ben, hogy mit nézegetett a vevő a weboldalon.”
Szakmai tanácsunk: Ne tegyétek. Az ERP / SAP rendszerek egy könyvelési és vállalatirányítási rendszerek, nem marketingeszközök. Ne tömjétek tele „szeméttel” (log adatokkal), mert lelassul a számlázás, a készletkezelés.
A modern megoldás a dedikált marketing automatizáció (pl. Klaviyo). Ez a rendszer „látja”, hogy a vevő betette a kosárba a terméket, de nem vette meg. És mit csinál? Nem csak egy jelentést ír róla, hanem cselekszik:
-
- 1 óra múlva küld egy e-mailt: „Segíthetünk a döntésben?”
- 2 nap múlva küld egy kupont.
- Értesíti az értékesítőt: „Hívd fel Kovács urat, megnézte a terméket, de nem vette meg!”
Ez hozza a pénzt. Az SAP pedig végezze a dolgát: számolja a készletet és a profitot.
Funkcionális Összehasonlítás: B2B Képességek
A táblázat célja bemutatni, hogy amihez a PrestaShopban csak egy „pipa” kell a beállításokban, ahhoz a WooCommerce-ben külön fizetős bővítményt (plugin) kell telepíteni, karbantartani és frissíteni – ami növeli a biztonsági kockázatot és az összeakadás esélyét.
| Funkció / Igény | WordPress + WooCommerce | PrestaShop | B2B Relevancia |
| Vevőcsoportok kezelése | ⚠️ Korlátozott. Alapból csak admin/vevő van. Bővítmény kell a csoportokhoz. | ✅ Natív. Korlátlan vevőcsoport (pl. Kiemelt, Viszonteladó, VIP) hozható létre. | KRITIKUS(eltérő árak alapja) |
| Egyedi árak (Árlisták) | ❌ Nincs. Csak bővítménnyel (pl. Role Based Pricing) oldható meg. Instabil lehet. | ✅ Natív. „Specifikus árak” funkció: vevőre, csoportra, országra, valutára szabható árak alapból. | KRITIKUS(SAP árak szinkronja) |
| Katalógus mód (Árak rejtése) | ❌ Nincs. Kódolást vagy plugint igényel. | ✅ Natív. Egy gombnyomás: árak elrejtése vendégeknek, láthatóvá tétele belépés után. | MAGAS(B2B védelem) |
| Minimális rendelési mennyiség (MOQ) | ❌ Nincs. Plugint igényel. | ✅ Natív. Termékenként vagy variációnként beállítható (pl. min. 1 raklap). | MAGAS(Logisztika) |
| Nettó/Bruttó kijelzés | ⚠️ Bonyolult. Keveredhet a kijelzés, nehézkes a B2B (nettó) fókusz beállítása. | ✅ Natív. Vevőcsoportonként állítható (pl. a cégek nettót látnak, a magánszemélyek bruttót). | MAGAS(Számlázás) |
| Adószám / Cégadatok kezelése | ❌ Nincs. A checkout mezőket külön bővítménnyel kell szerkeszteni. | ✅ Natív. Beépített „B2B mód”, bekéri a cégnevet, adószámot (EU VIES validálással). | KÖZEPES |
| Raktárkezelés / Készletmozgás | ⚠️ Alapszintű. Csak egy darabszám van. | ✅ Fejlett. Részletesebb készletnapló, fizikai készlet vs. elérhető készlet. | MAGAS(SAP szinkron) |
| SAP Integrálhatóság | ⚠️ Nehézkes. API van, de az adatstruktúra (lásd lentebb) miatt lassú és sérülékeny. | ✅ Kiváló. Strukturált SQL táblák, Webservice API, nagy tömegű adatot jobban bír. | KRITIKUS |
A „Motorháztető alatt”: Adatbázis és Teljesítmény
Itt vérzik el a WordPress a nagykereskedelemben. Ez a rész a legfontosabb technikai érv, amit a fejlesztők és az IT vezetők azonnal értenek és átlátnak.
A WordPress (WooCommerce) problémája: A wp_postmeta pokol
A WordPress eredetileg blogmotornak készült. Hogy rugalmas legyen, egy úgynevezett EAV (Entity-Attribute-Value) modellt használ, de nagyon rossz hatásfokkal.
-
-
Minden adat egy „Post”: A termék egy „post”. A rendelés egy „post”. A kupon egy „post”. Mindent a
wp_poststáblába ömleszt. -
A meta-adat katasztrófa: Ha egy terméknek van ára, súlya, színe, cikkszáma, SAP ID-ja, azok nem külön oszlopokba kerülnek, hanem a
wp_postmetatáblába, mindegyik külön sorként.-
Példa: 10.000 termék x 20 tulajdonság (ár, leírás, meta, SAP kód) = 200.000 sor a meta táblában csak a termékekre. És akkor még nem jöttek a rendelések, nem hoztunk létre kupont, vagy vevőkre egyedi árakat.
-
-
Következmény: Ha le akarod kérdezni az SAP-ból érkező „Kiemelt Partnerek” árlistáját, a rendszernek több millió soros táblákat kell összekapcsolnia (JOIN). Ez exponenciálisan lassul, ahogy nő a termékszám és a rendelésállomány. Csökken a teljesítmény!
-
A PrestaShop ereje: Relációs Adatbázis Szerkezet
A PrestaShop dedikált e-kereskedelmi rendszer, logikusan felépített, relációs adatbázissal.
-
-
Külön táblák mindennek:
-
ps_product: Itt vannak a termékek. -
ps_customer: Itt vannak a vevők. -
ps_specific_price: Itt vannak az egyedi árak. -
ps_orders: Itt vannak a rendelések.
-
-
Sebesség: Ha az SAP beküldi az árakat, a rendszernek csak a
ps_specific_pricetáblába kell írnia. Nem kell átnyálaznia milliónyi meta-adatot. -
Skálázhatóság: 100.000 terméknél és 500.000 rendelésnél is stabil marad, mert az indexelés (kereshetőség) optimalizált.
-
Összegzés a döntéshez
| Szempont | WordPress (WooCommerce) | PrestaShop |
| Ideális felhasználás | B2C, kevés termék (max 1-2 ezer), egyszerű árazás. | B2B/B2C, sok termék (10e+), összetett árazás, ERP integráció. |
| Fejlesztési rizikó | MAGAS. Sok plugin kell a B2B-hez, amik frissítéskor összeomolhatnak. | ALACSONY. A B2B funkciók a rendszer részei („Core features”). |
| Üzemeltetési költség | Kezdetben olcsó, de ahogy lassul, drága a tuningolás és hibajavítás. | Stabil, kiszámíthatóbb fenntartás. |
Konklúzió: Építs várat, ne homokvárat
Mivel SAP/ERP integráció, egyedi partnerárak esetleg több telephely kezelése a cél, a WordPress választása olyan, mintha egy személyautóval akarnánk kamionpótkocsit húzni. Elindul, de az első emelkedőn (az első 5000 terméknél vagy a szezonális csúcsforgalomban) „megfő a motor”. A PrestaShop a teherautó, amit erre a terhelésre terveztek.
A WordPress egy csodálatos eszköz – a maga helyén. De amikor a céged éves árbevétele és a partnereid elégedettsége múlik a rendszer stabilitásán, akkor nem a „kényelem” a fő szempont, hanem a megbízhatóság.
A váltás fájdalmasnak tűnhet. Új admin felületet kell tanulni, el kell engedni a megszokott gombokat. De ez a növekedés ára.
Ne építs felhőkarcolót homok alapra. Ha B2B nagykereskedést építesz SAP/ERP háttérrel, válassz olyan eszközt, amit erre terveztek. Hosszú távon nemcsak az idegrendszered, de a pénztárcád is megköszöni.
Tanácstalan vagy? Vedd fel a kapcsolatot velünk, segítünk a döntésben.




