Ajánlatkezelés B2B-ben: munkafolyamat, verziózás és átalakítás rendeléssé

Az árajánlat-kérés B2B-ben egy dokumentumon futó állapotgép. A vevő árat kér egy kosárra, az eladó egy számmal válaszol, a vevő ellenajánlatot tesz, és valamikor valaki elfogad. A csapatok általában űrlapot építenek. Hónapokkal később derül ki, hogy az ajánlat e-mailekben él, az árnak nincs érvényességi dátuma, egy eladó átírt egy tételt, miután a vevő elfogadta, és senki sem tudja megmondani, melyik verzióra épült a rendelés.

Ez a cikk a dokumentumot verziózott, jogosultsághoz kötött objektumként kezeli, lejárati dátummal, audit nyomvonallal és a rendelésbe való átalakítási lépéssel. Tárgyalja az életciklust, a verziózási szabályokat, azt, hogy ki engedményezhet és ki hagyhat jóvá, mit kellene jelentenie a lejáratnak, valamint egy adatmodellt építési ellenőrzőlistával. Az árazási szabályok és a konfiguráció külön téma, ezt a headless termékkonfigurátorok B2B-hez cikk tárgyalja, a beszélgetéskezelést pedig az AI ügyfélszolgálat B2B webshopokhoz cikk. Az ajánlatkezelés LLM-oldala a LLM-alapú RFQ-automatizálás cikkben van. Itt a platform és a munkafolyamat áll a középpontban.

Űrlap vagy állapotgép egy árajánlat-kérés?

Az árajánlat-kérés egy dokumentumon futó állapotgép, nem olyan űrlap, amely e-mailt küld. Öt termékdöntés határozza meg: milyen állapotokban lehet egy ajánlat, minden módosítás létrehoz-e verziót, ki és mennyit módosíthat árat, mikor szűnik meg az érvényessége, és hogyan lesz az elfogadott ajánlatból rendelés. Hozza meg ezt az öt döntést először, utána jönnek a képernyők. Ha nyitva hagyja őket, a funkciót e-mailben, táblázatokban és csevegésben építik újra, ugyanazokkal a problémákkal.

Milyen az életciklus a kosártól a rendelésig?

Az életciklus a kosártól a vázlatként mentett ajánlaton át, a tárgyaláson és a jóváhagyáson keresztül a rendelésig tart. A nevek eltérnek, de a forma a platformok között hasonló. A Spryker lehetővé teszi, hogy a vevő a kosárból árajánlat-kérést hozzon létre, megjegyzést fűzzön hozzá, megadja a szállítási címet és a szállítási módot, és látja a tárgyalási előzményeket. Beküldés után az RFQ Draft állapotba kerül, egy ügynök pedig átdolgozhatja és visszaküldheti. A vevők az RFQ-t vissza is alakíthatják kosárrá. A Spryker RFQ-dokumentációja ezeket a lépéseket írja le, de a legutóbbi frissítési dátuma régi, ezért a mezőlistát kiindulópontként kezelje, és ellenőrizze az Ön által futtatott kiadást.

Az Adobe Commerce B2B más szókincset használ, hasonló formával. Egy kérés New állapotban jelenik meg, és a vevő addig módosíthatja, amíg az eladó meg nem nyitja. Az eladó vázlatot ment vagy elküldi, ekkor Submitted állapotba kerül, és az eladó addig nem módosíthatja, amíg a vevő vissza nem küldi. A vevő Pending állapotot lát, amíg a tárgyalás tart. Az Adobe ajánlatokkal foglalkozó dokumentációja, amelyet 2026 októberében frissítettek, a legegyértelműbb abban, ki nyúlhat az ajánlathoz az egyes állapotokban, ez pedig a jogosultsági mátrixhoz szükséges részlet.

Az SAP Commerce Cloud Commerce Quotes modulja ugyanerre a pontra más oldalról mutat rá. Az ajánlatot mindkét fél tárgyalja, amíg megállapodás nem születik, majd a vevő a pénztárba viszi az ajánlatot, és leadja a rendelést. A 2205-ös dokumentációban az állapot a szereptől függ: a vevő Submitted állapotot lát, miközben az értékesítő ugyanarra az ajánlatra Requested állapotot.

A modellezendő állapotok ezeknek a szókincseknek az egyesítése: a kosárból származó kérés, a vázlat, amelyet csak az eladó lát, a beküldött állapot, amelyet a vevő birtokol, a verziót kapott átdolgozott állapot, az elfogadott állapot zárolt árakkal és szállítással, a rendelésre mutató konvertált állapot, valamint a lejárt vagy törölt végállapot. A belső neveket tartsa stabilan, és a felületen szerepkörönként feleltesse meg őket. A vevő és az értékesítő ugyanarra az ajánlatra másként nevezheti ugyanazt a tényt, ahogy az SAP teszi, de a tény egyetlen rekord legyen.

Mit kell tartalmaznia egy ajánlatverziónak?

Az ajánlatverzió egy tárgyalási lépésben rögzített, nem módosítható pillanatkép az árakról, mennyiségekről, szállításról és megjegyzésekről. A verziózás választja el egymástól az ajánlatot és a beszélgetést. Nélküle az eladó helyben írja át az árat, a vevő olyan számot fogad el, amely már nem létezik, és egy audit-kérdésre nem lehet válaszolni. A biztonságos szabály: egy egyeztetett mező módosítása új verziót hoz létre, a régi verziók pedig olvashatók maradnak.

Az SAP ezt kifejezetten rögzíti: ahogy az ajánlat áthalad a tárgyaláson, a munkafolyamat következő lépéséhez másolat készül róla. A Spryker az ajánlatverziókat adatként kezeli; importspecifikációja olyan fájlt ír le, amely hivatkozás, vállalati felhasználó és állapot szerint konfigurálja a verziókat. Az Adobe a kérésen egy vevői és eladói állapotpárt tart, és mindkét félnek engedi, hogy elfogadás előtt módosítsa a mennyiségeket, eltávolítson tételeket, tételszintű megjegyzéseket fűzzön hozzá és engedményeket állítson.

Minden verziónak legalább ezekre van szüksége: tételenkénti mennyiségek és egységárak; tételenkénti engedmények vagy felülírások a szerzőjükkel; szállítási mód és költség; tételszintű megjegyzések; mellékletek, például specifikációk; valamint a változtató személye és időbélyege. A Shopware entitásmodellje hasznos referencia ehhez a felosztáshoz. Külön kezeli az ajánlatot, a szállítási rekordot a szállítási móddal és dátumokkal, a tételeket, a tranzakciós rekordot a fizetett összeggel és külső hivatkozással, a megjegyzéseket, a munkatárs-hozzárendeléseket és a dokumentumokat. A dokumentáció szerint jelenleg csak a termék tételtípus támogatott, ezért a szolgáltatási vagy fuvarozási tételhez saját modell kell.

A lejárat utáni újraajánlatnak nem szabad elveszítenie az előzményeket. Az új ajánlat egy új verzió, amely az előzőhöz kapcsolódik, így az audit nyomvonal továbbra is mutatja az eredeti árat, a lejáratot és az új ajánlat okát.

Ki engedményezhet, és ki hagyhat jóvá?

A jogosultságok döntik el, ki engedményezhet és ki hagyhat jóvá, és ezeket vállalati szerepkörönkénti, kifejezett konfigurációban kell tartani, nem a kódban. A platformokon két irányítási dimenzió jelenik meg. Az első az érték: mennyit lehet engedményezni, és mikor kell vezetőnek jóváhagynia. A második a keret: melyik költséghelyet és melyik keretet terheli az ajánlat.

A Spryker Approval Process a pénztár előtt vezetői jóváhagyást kér. Vállalati szerepkörönként konfigurálható, és akkor indul, ha a kosár végösszege meghaladja a Buy up to grand total jogosultságban megadott összeget. A Purchasing Control funkció keretet és költséghelyeket ad hozzá. A vevők a pénztárnál vagy az árajánlat-kérésnél rendelik hozzájuk a kosarat, az ügynökök pedig a vevő nevében ugyanezt megtehetik. Ez két külön ellenőrzés, és egy ajánlatnak mindkettő kellhet.

Az Adobe másként kezeli az engedményeket. A tárgyalás alatt az eladó tételszintű vagy ajánlatszintű engedményt alkalmazhat, a dokumentáció pedig rögzíti, hogy egy tárgyalt ajánlat elfogadása és pénztárba lépése után nem adható hozzá további engedmény. Ezt a szabályt érdemes átvenni: elfogadás után az ár szerződéses feltétel, nem szerkeszthető mező.

Egy küszöbökkel dolgozó ár-felülírási szabályt kell építeni. Az értékesítő egy sávon belül felülírhat egy tételt; e fölött egy második szerepkörnek kell jóváhagynia; a padló alatt a rendszer megtagadja. A szabályt adatként tárolja vállalatonként vagy szerepkörönként, és a jóváhagyót a tételen rögzíti. A kódba írt százalékok az ajánlatszolgáltatásban az a módja, ahogy egy engedményszabályból támogatási jegy lesz.

Mi történjen, ha egy ajánlat lejár?

A lejárat a verzión tárolt dátum, egy feladat érvényesíti, és látható állapotban kell végződnie, nem csendben. Az árajánlat egy időszakra szóló ígéret, és a platformok ezt az időszakot eltérően kezelik. Az Adobe Commerce-ben van alapértelmezett lejárati időszak, amely napokban, hetekben vagy hónapokban adható meg. A Spryker ügynökei az ajánlat érvényességét percre pontosan beállíthatják. Az Odoo ajánlati dokumentációjában van lejárati dátum mező, az ajánlatsablonok pedig lejárati határidőt hordozhatnak.

Az általam olvasott platformdokumentáció nem rendezi, mi történik a lejáratkor; az Adobe-oldalak nem mondják meg, hogy az ajánlat automatikusan lezárul-e, vagy csak figyelmeztet. Döntse el maga. Három választás gyakori: zárolja az ajánlatot, hogy a vevő már ne fogadhassa el; új verzióként, friss árral adja ki újra, amit az eladónak jóvá kell hagynia; vagy figyelmeztesse mindkét felet a lejárat előtt. Ésszerű alapértelmezés: figyelmeztetés a lejárat előtt, zárolás a lejáratkor, és egykattintásos újraajánlat, amely a régiből új verziót hoz létre, az audit nyomvonalon pedig látható marad a régi ár.

Az érvényességet a verzión tárolja, soha nem a felületen. Ha a böngésző dönti el, hogy egy ajánlat még érvényes-e, a vevő egy régi lapról elfogadhat elavult árat, a háttérfeladat pedig nem tudja megmondani az igazat. Az elfogadáskor a tárolt időbélyeget kell olvasni, és ugyanezt az ellenőrzést az átalakításkor újra le kell futtatni, mert a múlt heti elfogadás nem a mai átalakítás.

Hogyan lesz az elfogadott ajánlatból rendelés?

Az átalakítás az a lépés, ahol a tárgyalt dokumentumból kereskedelmi rendelés lesz, és pontosan egyszer kell megtörténnie. Webshop-elsőre épülő felállásban az elfogadott ajánlat a szokásos pénztáron megy keresztül, az árak átvitelével. Az Adobe a pénztárnál alkalmazza a tárgyalt árat, és zárolja a szállítást és az engedményeket. A Spryker egy RFQ-t vissza tud alakítani kosárrá, amely aztán a szokásos pénztáron megy át, beleértve az esetleges jóváhagyást.

ERP-elsőre épülő felállásban az elfogadott ajánlat a ERP-ben vevői rendeléssé válik, a webshop pedig csak megjeleníti. Az SAP dokumentációja leírja, hogy a vevő az ajánlatot a pénztárba viszi és rendelést ad le. Hogy az elfogadott ajánlatból hogyan keletkeznek szerződések és ismétlődő rendelések, az ERP-től függ; ezt a lépést ez a cikk nem vizsgálja.

Bármelyik utat választja is, az átalakításhoz idempotencia-kulcs kell, például az ajánlat azonosítója az elfogadott verziószámmal együtt. Két kattintás vagy egy időtúllépés utáni újrapróbálás is egy rendelést hozzon létre. Ugyanennek a hivatkozásnak át kell kerülnie az ERP vevői rendelésbe, hogy az újrapróbálás a meglévő bizonylatot találja meg, és ne hozzon létre másodikat.

Mit szállítanak valójában a platformok?

A nagy platformok szállítanak tárgyalási funkciókat, de eltérnek a tételes engedményekben, a jóváhagyásban és a lejáratban, ezért a táblázatot nézze meg a választás előtt. Az időpontok számítanak, mert ezek a funkciók változnak. A Spryker RFQ-oldala régi, a Purchasing Control és az Approval Process oldalai újabbak. Az itt említett SAP-állapotok a 2205-ös dokumentációból származnak, az újabb kiadások pedig átalakíthatják a modult.

A Shopware ajánlatkezelése a B2B-komponensek között van, amelyek a Commercial bővítményhez tartoznak, és az Evolve csomagtól érhetők el, nem a Community Edition-ben. A kereskedő megjegyzéseket és engedményeket fűzhet az egyes ajánlattételekhez, beveheti a szállítási költséget, és az ajánlat, az üzenetek és a dokumentumok előzményein keresztül követheti a változásokat.

A Pimcore nyílt forráskódú E-Commerce Framework csomagja GPL-verzióban elérte élettartama végét, a keretrendszer pedig az Enterprise Editionbe került. Egy ajánlatokat igénylő Pimcore-webshop ezért valószínűleg Data Objectekre épít, a Pimcore saját verziókezelésével, vagy licencelni fogja az Enterprise csomagot. Nyilvános árat nem találtam az összehasonlításhoz. A termék-törzsadatok és az ERP-szinkronjuk külön téma, ezt a Pimcore ERP delta szinkron cikk tárgyalja.

Hogyan néz ki az adatmodell?

Az adatmodellben van egy stabil ajánlat, minden tárgyalási lépéshez egy verzió, a verzióhoz tartozó tételek, valamint üzenet- és audit-táblák, amelyek az ajánlatra vagy a verzióra mutatnak. Egy lapos ajánlattábla egyetlen ármezővel nem tud előzményt ábrázolni. A modell az ajánlatot tartja stabil azonosítónak, a változó részeket pedig egy verzióba teszi.

A felülírások a verzió tételén élnek. Az eredeti listaárat tartsa az ajánlott ár mellett, az engedmény típusával és értékével, a szerzővel és a jóváhagyási hivatkozással, hogy az áttekintő a fedezetet újraszámolás nélkül lássa. Az ajánlat fejléce csak az állapotot és a jelenlegi, illetve az elfogadott verzióra mutató hivatkozásokat tartalmazza. A külső hivatkozások a kereskedelmi oldalon a webshop-rendelésre, a back office oldalon pedig az ERP-rendelésre mutatnak.

Hol illik be az LLM-es segítség, és hol nem?

Az LLM-es segítség az ajánlatdokumentum köré tartozik, nem az árazási logikájába. Hasznos feladatok: az ajánlat kísérőszövegének megfogalmazása a strukturált ajánlatból, egy hosszú üzenetváltás összefoglalása a következő kollégának, aki átveszi az ajánlatot, egy tételmegjegyzés lefordítása, valamint olyan tételek jelölése, ahol hiányzik az adat, például a mértékegység, a szállítási határidő, vagy a mennyiség eltér a kéréstől. Minden kimenet javaslat, amelyet ember ellenőriz, mielőtt a vevő látná.

A határ egyértelmű. Az asszisztens soha nem állapít meg árat, nem alkalmaz engedményt, és nem fogad el ajánlatot. Az árazási jogkör a jogosultságok szakaszának szabályánál marad, az audit nyomvonal pedig rögzíti, hogy egy ember jóváhagyta-e az asszisztens vázlatát. A Spryker AI Commerce dokumentációja felsorol egy Back Office Assistant nevű funkciót, egy MI-csevegőablakot a back office-ban, ami azt mutatja, hogy az asszisztensek az ajánlatkezelés mellett a back office munkafolyamataiba is belépnek. Maga a tárgyalás továbbra is kormányzott dokumentum. A kérések kinyerésének és a válaszok megfogalmazásának modelloldali terve a LLM-alapú RFQ-automatizálás cikkben van.

Építési ellenőrzőlista: táblák, állapotok és tesztek

Az állapotokat, a táblákat és a teszteket a képernyők előtt építse meg. Az alábbi ellenőrzőlista az a minimum, amiben a csapatnak a fejlesztés előtt meg kell egyeznie. Minden pont a cikk korábbi döntéseinek egyikére válaszol.

1. Határozza meg az állapotokat és a megengedett átmeneteket, és utasítson el minden listán nem szereplő átmenetet.
2. Hozza létre a quote, quote_version, quote_line, quote_message, quote_attachment és quote_event táblákat; az elfogadás után egy verziósort soha ne frissítsen.
3. Írja meg az ár-felülírási szabályt szerepkörönkénti adatként, küszöbökkel, és rögzítse a jóváhagyót minden tételen.
4. A érvényességet a verzión tárolja, és futtasson olyan lejárati feladatot, amely zárolja az ajánlatokat és eseményt küld.
5. Tegye az átalakítást idempotenssé az ajánlat azonosítója és az elfogadott verziószám alapján.
6. Teszteljen teljes utat: a vevő beküld, az eladó ellenajánlatot tesz, a vevő elfogad, egy rendelés jön létre, és a második elfogadás ugyanazt a rendelést adja vissza.
7. Teszteljen negatív eseteket: a lejárt elfogadást el kell utasítani, a küszöb feletti felülírást jóváhagyás nélkül el kell utasítani, a megismételt átalakítás pedig nem hozhat létre semmit.

// Sketch: allowed transitions are data, and anything else is rejected
const allowed: Record<QuoteState, QuoteState[]> = {
  draft: ['submitted', 'cancelled'],
  submitted: ['revised', 'accepted', 'expired', 'cancelled'],
  revised: ['submitted', 'accepted', 'expired', 'cancelled'],
  accepted: ['converted'],
  expired: ['revised'],            // re-quoting creates a new version, never edits the old one
  converted: [],
  cancelled: [],
}

function transition(quote: Quote, to: QuoteState, actor: Actor) {
  if (!allowed[quote.state].includes(to)) throw new Error(`illegal ${quote.state} -> ${to}`)
  if (to === 'accepted' && quote.validUntil < new Date()) throw new Error('quote expired')
  return { ...quote, state: to, events: [...quote.events, { to, actor, at: new Date() }] }
}

Egy Playwright végponttól végpontig tartó teszt végigviheti a teljes utat egy webshop-homokozóban, a negatív eseteket pedig az állapotgép egységtesztjeibe érdemes tenni. Ha B2B ajánlati folyamatot épít vagy vizsgál, nézze meg a B2B e-kereskedelmi munkámat.

Források

1. Spryker: request for quote feature
2. Spryker: quote request import file details
3. Spryker: Approval Process feature overview
4. Spryker: Purchasing Control feature overview
5. Adobe Commerce B2B: negotiable quotes
6. Adobe Commerce B2B: configure quotes
7. SAP Commerce: Commerce Quotes (2205 documentation)
8. SAP Commerce: quote statuses (2205 documentation)
9. Shopware: B2B Components
10. Shopware: quotes management entities and schema
11. Odoo 20 documentation: quotation deadline
12. Pimcore: E-Commerce Framework bundle (GPL version end of life)