B2B árképző motorok: ügyfélspecifikus árak, gyorsítótár és audit

Egy B2B árképző motor dönti el, milyen nettó árat lát egy bejelentkezett vevő egy cikkszámnál attól függően, ki ő, milyen szerződése van a cégének, hol vásárol, hány egységet rendel, milyen pénznemben és melyik napon. A számítás a könnyebbik fele. A nehezebb fele az üzemeltetés: ügyfelenként eltérő árakat úgy cache-elni, hogy ne lássa őket rossz ügyfél, egy árat három hónappal később egy vitában megmagyarázni, és az áfát ugyanúgy kerekíteni, ahogy a számla fogja.

Ez a cikk végigveszi, hogyan oldják fel a nagy platformok az ügyfélspecifikus árakat (Spryker, Pimcore, az SAP kondíciótechnika, commercetools, Adobe Commerce és Shopify B2B), majd a gyorsítótárazással, az audittal, a teszteléssel és az áfával foglalkozik. Hogy egy konfigurátor hogyan áraz opciókat, azt a headless termékkonfigurátorok B2B-ben című cikk írja le; hogy bejelentkezés mögött hogyan jelennek meg az árak strukturált adatként, azt a schema.org strukturált adatok B2B webshopokhoz című.

Hogyan dől el egy B2B ár?

Egy B2B árat általában hét dimenzió határoz meg: az ügyfél, az ügyfélcsoport vagy cég, a szerződés, a régió vagy értékesítési csatorna, a mennyiségi sáv, a pénznem és az érvényességi dátum. Az árképző motor azt a legspecifikusabb szabályt keresi, amely mindegyikre illik, és lépésenként egy általános alapárra esik vissza, ha nincs specifikusabb.

• Ügyfél: egyetlen vevői fiókra szóló egyedi ár, gyakran néhány kulcsfontosságú cikkszámra.
• Ügyfélcsoport vagy cég: egy szegmens közös árlistája, például viszonteladóké, kivitelezőké vagy egy cég összes leányvállalatáé.
• Szerződés: tárgyalt megállapodás érvényességi idővel, néha saját mennyiségi vállalásokkal.
• Régió vagy csatorna: ország, áruház vagy értékesítési csatorna, amely az adózási kezelést is eldönti.
• Mennyiségi sáv: az a skálafok, amelyet a rendelt mennyiség elér.
• Pénznem: az árakat pénznemenként tartják karban, nem menet közben váltják át.
• Érvényességi dátum: kezdő és záró dátum, hogy a következő negyedév árai előre betölthetők legyenek.

A dimenziók összeszorzódnak. A Spryker ERP-ben kezelt árakról szóló útmutatója példát hoz: 1000 ügyfél szorozva 25 000 termékkel, absztrakt és konkrét termékekre számolva, 50 millió elméleti árrekord. 20 százalékos szerződéses lefedettségnél ez még mindig nagyjából 20 millió, az a pont, ahol az útmutató szerint a szabványos szinkronfolyamat „komolyan romlani kezd” (Spryker). Ezért fontosabb az a kérdés, hol élnek az árak és hogyan cache-eljük őket, mint maga a képlet.

Hol élnek az árak, és milyen sorrendben oldódnak fel

Az áraknak általában három lehetséges otthona van: az ERP, amely a tárgyalt kondíciókat tartja, és többnyire a hiteles rendszer; a PIM, amely termékattribútumként listaárakat tárolhat; és a kereskedelmi platform, amely gyors olvasáshoz árlistákat vagy árdimenziókat tart. A lényeges döntés az, melyik a hiteles, és mennyire lehet elavult egy másolat egy másik rendszerben. A termékadatok szinkronjánál ugyanez a kérdés, lásd a Pimcore ERP delta szinkront.

Az SAP S/4HANA-ban a kondíciótechnika dönt. A rendszer az értékesítési terület, az értékesítési bizonylatfajta és a megrendelő alapján választ árképzési eljárást. Az eljárás minden kondíciófajtájához tartozik egy hozzáférési sorrend, amely sorban keresi a kondíciótáblákat a legspecifikusabb kulcstól a legáltalánosabbig, amíg érvényes kondíciórekordot nem talál. Ezután a mennyiségi skálák választják ki a skálafokot, a fejszintű kondíciókat pedig nettó érték szerint osztja szét a tételekre, ha nincs másként beállítva (SAP Learning).

A commercetools nyolclépcsős visszaesésként dokumentálja az árválasztást, az ügyfélcsoport, csatorna és ország kombinációjától le az alapárig. Minden lépcsőn belül az érvényességi idővel rendelkező árak megelőzik az anélkülieket, és ha ezután is több ár illik, a legolcsóbb nyer. A sávos árakat figyelmen kívül hagyja, ha már termékkedvezmény érvényes (commercetools).

A Spryker az árakat a legkisebb pénzegységben, egész számként tárolja, mindegyiket ártípussal, valamint árképzési módonként bruttó és nettó értékkel. Olvasáskor először a konkrét terméket nézi, majd az absztraktra esik vissza. A mennyiségi árak ugyanezt az öröklést követik: egy konkrét termék saját mennyiségi árai felülírják az absztraktéit, és csak az alapértelmezett ártípust támogatják (Spryker árak, Spryker mennyiségi árak). Az ügyfélspecifikus árak árdimenziókkal készülnek: a dokumentált út csoportazonosítóval bővíti az ügyfél- és ártáblákat, és csoportonként exportálja az árakat a kulcs-érték tárba.

A Pimcore E-Commerce Framework minden termékhez árrendszert rendel, amely PriceInfo objektumokat ad vissza. A beépített AttributePriceSystem egy termékattribútumból olvassa az árat, minden ERP-vezérelt megoldás pedig saját, a konfigurációban regisztrált árrendszer lesz (Pimcore). Erre az árra aztán az árszabályok feltétel–művelet párokként alkalmaznak kedvezményeket.

Platformok összehasonlítva

A platformok egyetértenek abban, hogy a legspecifikusabb szabály nyer, és abban különböznek, hol dől el a döntetlen, és mit adnak az audithoz. A táblázat összefoglalja, mit dokumentál mindegyik 2026 októberében.

Két dokumentált szabály sokakat meglep. Az Adobe Commerce-ben egy megosztott katalógus fix egyedi ára soha nem emeli az árat: az alapár és a fix érték közül a kisebbet használja (Adobe). A Shopify B2B-ben a mennyiségi ár érvénybe lépése után az ár rögzül, így egy katalógusszintű százalékos módosítás már nem csökkenti, a mennyiségi szabályok pedig változatonként érvényesek, így a vevő nem kombinálhat változatokat egy minimum eléréséhez (Shopify).

Személyre szabott árak cache-elése szivárgás nélkül

Egy személyre szabott ár addig cache-elhető, amíg minden, az árat megváltoztató dimenzió része a cache-kulcsnak. Ha a kulcs csak az URL, akkor az első vevő, aki betölt egy termékoldalt, határozza meg az árat minden későbbi vevő számára. Ez egyszerre rossz ár és adatszivárgás: az egyik ügyfél szerződéses árát egy másik ügyfél látja.

• Árdimenziókra kulcsoljon, ne felhasználóra. Árlistánként vagy ügyfélcsoportonként cache-eljen, ne felhasználói azonosítónként, különben összeomlik a találati arány. A Cloudflare egyedi cache-kulcsokban engedi a fejléceket, sütiket és felhasználói jellemzőket, de ezek csak Enterprise csomagban érhetők el, és a dokumentáció figyelmeztet, hogy az egyedi kulcsok szétforgácsolhatják a cache-t (Cloudflare).
• Címkézze a válaszokat az érvénytelenítéshez. A Varnish xkey modulja lehetővé teszi, hogy a backend minden választ helyettesítő kulcsokkal, például cikkszámmal és árlistával címkézzen. Egyetlen purge hívás üríti az összes objektumot, amely a kulcsot viseli, a softpurge megtartja őket a grace módhoz, a README pedig azt tanácsolja, hogy ACL-lel védje a purge végpontot (xkey).
• Az üzleti eseménykor ürítsen. Egy szerződésváltozás, egy új árimport vagy egy ERP-delta elküldi az érintett cikkszám- és árlista-címkéket. Egy TTL önmagában a lejáratig élesen hagyja a régi szerződéses árat.
• A cache soha ne legyen az egyetlen tár. A Spryker útmutatója figyelmeztet: ha az árakat csak cache-be írják, a cache elvesztése adatvesztést okozhat (Spryker).

ERP-ben kezelt árakhoz ugyanez az útmutató alapértelmezésként hibrid megoldást ajánl: egy helyi olvasási modell szolgálja ki a böngészést és a kosarat, a pénztár pedig újra ellenőriz az ERP-ben, így a végleges ár a rendelés leadásakor megerősítést kap. Ha a cache-elt ERP-árak öregszenek, az oldal frissességjelzőt mutat, például „Ár 14:23-kor”, ahelyett hogy élőnek tüntetné fel a számot. Az útmutató célja 100 ms alatti árlekérés storefront-kérésenként.

Egy ár auditálása és magyarázata

Előbb-utóbb valaki megkérdezi, miért látta X ügyfél az Y árat egy adott napon. Ha a válaszhoz a mai szabályokat kell lefuttatni a mai adatokon, nem tud válaszolni, mert azóta változott a szerződés, a sávtáblázat és az alapár is. A választ abban a pillanatban kell eltárolni, amikor az árat felhasználják.

Minden rendelési tételen tároljon rendeléskori árpillanatképet: a feloldott nettó árat, a nyertes szabályt és az alulmaradt jelölteket, az árlista- és szerződésazonosítókat verzióval, a mennyiségi sávot, a pénznemet, az adókulcsot és a kerekítési módot. A pillanatkép tételenként néhány száz bájt, és egy vitát egyszerű kereséssé tesz. Az alábbi példa szemléltető, az összegek centben.

{
  "orderLine": "SO-2026-104233/3",
  "sku": "VLV-200-DN50",
  "quantity": 24,
  "resolvedAt": "2026-10-07T09:14:03Z",
  "currency": "EUR",
  "unitNet": 18350,
  "winningRule": { "type": "contract", "id": "CT-7781", "version": 4, "tier": "20+" },
  "candidates": [
    { "type": "customerGroup", "id": "PL-INSTALLERS", "unitNet": 19100 },
    { "type": "base", "id": "PL-BASE-EUR", "unitNet": 22400 }
  ],
  "taxRate": "19.00",
  "rounding": "HALF_UP per line",
  "priceSource": "erp-read-model",
  "priceAgeSeconds": 412
}

A platformok adnak némi nyersanyagot. A commercetools üzeneteket (Messages) küld az erőforrások változásairól, köztük külön Pricing és Discount üzeneteket az önálló árakhoz, de ezeket alapból nem tárolja, be kell kapcsolni (commercetools Messages). A Pimcore ki tudja listázni az egy PriceInfo-ra alkalmazott árszabályokat, az SAP-ban pedig minden bizonylattétel hordozza a hozzáférési sorrendjei által talált kondíciórekordokat. Egyik sem helyettesít egy saját kezelésű pillanatképet, mert ezek a források a saját ütemük szerint változnak vagy járnak le.

Az ár-anomáliák jó terepet adnak az olyan automatizálásnak, amely ismeri a határait. Ha egy ellenőrzés jelzi azokat a tételeket, ahol a felszámolt ár egy tűréshatárnál jobban eltér a feloldottól, az esetet emberhez kell irányítania, nem automatikusan javítania. A jev-decide skillem ugyanezt a mintát követi: az alacsony bizonyosságú döntés emberhez kerül, ahelyett hogy végrehajtódna.

Az árlogika tesztelése arany pillanatképekkel

Az árlogika egy mátrix: ügyfél, szerződés, régió, mennyiség, pénznem és dátum. Válasszon dimenziónként néhány reprezentatív értéket, számolja ki a feloldott árat minden kombinációra, és az eredményt arany fájlként tárolja a repóban. A Playwright az első futáskor arany pillanatképet ír, minden későbbi futást ehhez hasonlít, és csak --update-snapshots hatására frissíti; a toMatchSnapshot() bármilyen szövegen működik, nem csak képernyőképen (Playwright).

import { test, expect } from '@playwright/test'
import { resolvePrice } from '../src/pricing'
import { customers, skus, quantities, dates } from './price-matrix'

// One row per combination; the golden file is reviewed like code
test('price matrix matches the golden file', () => {
  const rows: string[] = []
  for (const c of customers) for (const sku of skus) for (const qty of quantities) for (const date of dates) {
    const p = resolvePrice({ customer: c, sku, quantity: qty, date, currency: 'EUR' })
    rows.push([c.id, sku, qty, date, p.unitNet, p.winningRule.id].join(';'))
  }
  expect(rows.join('\n')).toMatchSnapshot('price-matrix.txt')
})

Az arany fájlok konkrét esetekben fogják el a regressziókat; a tulajdonságalapú tesztek az általános szabályok megsértését. A fast-checkkel invariánsokat fogalmaz meg, a könyvtár pedig több száz bemenetet generál, és minden hibát minimális esetre zsugorít (fast-check). Hasznos invariánsok: a rendelés végösszege a kerekített tételösszegek összege, egy magasabb sáv soha nem ad magasabb egységárat, pozitív adókulcsnál a bruttó soha nem kisebb a nettónál, és az ügyfélspecifikus ár soha nem haladja meg az alapárat, ahol az üzleti szabály ezt tiltja.

Futtassa a mátrixot minden árimport és minden ERP-delta után, ne csak kódváltozáskor, mert a legtöbb árhiba az adatokból jön, nem a kódból. A storefront oldalon Playwright MCP-vel különböző bejelentkezett szerepkörökkel járom be a valódi webshopot, és szerződésváltozás után összevetem a megjelenített árat a feloldottal.

Áfa, kerekítés és árképzési módok buktatói

A B2B árakat általában nettóban tartják karban és mutatják, a fogyasztói árakat bruttóban, és a platformnak tudnia kell, melyiket tárolja. A Spryker a quote-on tartja az árképzési módot, bruttót vagy nettót, és egy quote nem használhatja egyszerre mindkettőt. A dokumentáció a következményt is bemutatja: bruttó módban egy 100 € nettó, az áruház régiójában 20%-os adójú termék 10%-os adójú régióba eladva is 120 € bruttó marad, így a nettó összeg 109,09 € lesz (Spryker).

Ugyanez az indítvány megjegyzi, hogy az uniós héairányelvek egyetlen rendelkezése sem szabályozza kifejezetten a kerekítést, így a részletek az uniós elveken belül a nemzeti jogra tartoznak, és hogy vállalkozások közötti nettó számlázásnál a torzulások vagy nem jelentkeznek, vagy erősen mérséklődnek. A brit HMRC szabálya konkrét példa: a 0,5 penny alatti adót lefelé, a 0,5 pennyt vagy többet felfelé kerekítik, és más módszerek is megengedettek, ha tisztességes és észszerű eredményt adnak (HMRC). Fogyasztóknál az árfeltüntetési irányelv az áfát is tartalmazó eladási árat írja elő, ez az egyik oka annak, hogy a B2C webshopok bruttóban, a B2B webshopok nettóban gondolkodnak (98/6/EK irányelv).

Tegye a kerekítést explicitté a kódban. A commercetools konfigurációként kínálja a kerekítést HalfUp, HalfDown és HalfEven módokkal, valamint külön kosárbeállításokkal az ár kerekítésére, az adó kerekítésére és az adószámításra, és megjegyzi, hogy a B2B árak gyakran centnél finomabb pontosságot igényelnek. PHP-ban a moneyphp szövegként tárolja az összegeket, az allocate() pedig determinisztikusan bontja a 10,00 €-t 334, 333 és 333 centre (moneyphp). Az árakat a legkisebb egységben egész számként vagy pénzkönyvtárral tárolja, soha ne lebegőpontos számként.

Mikor ne építsen saját árképző motort

A legtöbb B2B webshopnak nem árképző motort, hanem áradaptert kell építenie. Ha az ERP már helyesen oldja fel a kondíciókat, ennek a logikának a megkettőzése a webshopban két, egymástól elsodródó motort hoz létre. A hibrid minta az ERP-t hagyja hitelesnek: a feloldott árakat olvasási modellbe replikálja a böngészéshez, a pénztárnál újra ellenőriz, és megmutatja az elavultságot ahelyett, hogy elrejtené.

Akkor építse a feloldást a webshopba, ha az ERP az Ön katalógusméreténél nem válaszol elég gyorsan a böngészéshez, ha a webshop olyasmit is árul, amit az ERP nem áraz, például konfigurált opciókat vagy piactéri ajánlatokat, vagy ha az ERP szabályai olyan egyszerűek, hogy egy árlista-import lefedi őket. Ekkor is egy gazdája legyen minden árszabálynak, a másik rendszer pedig ismert maximális korú másolat legyen.

Az „ár kérésre” saját folyamattal rendelkező üzleti állapot legyen, ne hiba. Ha egyetlen szabály sem illik, egy ajánlatkérés jobb, mint egy alapár, amelyre az ügyfél nem jogosult, és jobb, mint egy hiányzó ár, amely hibának látszik. Ezután az ajánlatkezelés veszi át, ahogy az ajánlatkérés-automatizálás LLM-ekkel című cikk leírja.

Ellenőrzőlista, mielőtt az árakhoz nyúl

A Spryker- és Pimcore-munkáimban az első tisztázandó kérdés az, hol élnek az árak. Ezt a listát érdemes végigvenni, mielőtt árakat érintő indexekhez, cache-ekhez vagy importálókhoz nyúl.

1. Írja le a dimenziókat és a feloldási sorrendet, a lépcsőn belüli döntetlen kezelésével együtt.
2. Nevezzen meg minden árszabálynak egy gazdát, és minden másolatnak egy maximális kort.
3. Minden árat módosító dimenzió kerüljön a cache-kulcsba, semmi felhasználónkénti.
4. Címkézze a cache-elt árakat cikkszám és árlista szerint, és szerződésváltozáskor ürítsen, ne csak TTL alapján.
5. A pénztárnál ellenőrizzen újra, és mutassa az ár korát, ha nem élő.
6. Tároljon rendeléskori árpillanatképet szabályazonosítókkal, verziókkal, adókulccsal és kerekítési móddal.
7. Tartson fenn arany ármátrixot és tulajdonságteszteket, és futtassa őket minden import után.
8. Dokumentáljon egy kerekítési szabályt a webshopra, az ERP-re és a számlára, és használjon egész számokat vagy pénzkönyvtárat.
9. Kezelje az „ár kérésre” helyzetet saját folyamattal rendelkező állapotként.

Ha ügyfélspecifikus árakat bogoz ki egy webshop és egy ERP között, nézze meg a B2B e-kereskedelmi munkámat. Azok az értékesítők, akiknek egy árat kell megmagyarázniuk az ügyfélnek, ugyanezekből a pillanatképadatokból profitálnak, lásd MI-segéd B2B értékesítőknek.

Források

1. Spryker docs: prices feature overview (Sep 2026)
2. Spryker docs: price explosion and ERP-owned pricing in B2B (Sep 2026)
3. Spryker docs: volume prices overview
4. commercetools docs: pricing and discounts overview
5. SAP Learning: introducing the condition technique
6. Pimcore docs: price systems and getting prices (2026.3)
7. Adobe Experience League: shared catalog pricing structure (Oct 2026)
8. Shopify Help Center: B2B quantity rules and volume pricing
9. Varnish libvmod-xkey README
10. Opinion of the Advocate General in Case C-484/06 (Koninklijke Ahold)
11. HMRC internal manual VATREC12030: rounding of VAT
12. Playwright docs: snapshot testing