Punchout katalógusok: cXML, SAP OCI és az út a vevő ERP-jéig és vissza

A punchout katalógus egy beszállító webshopja, amelyet a vevő a saját beszerzési rendszeréből nyit meg. A beszerző a beszállító keresőjét, konfigurátorát és szerződéses árait használja, majd a kosarat visszaküldi a saját rendszerébe, ahol beszerzési igény lesz belőle, átmegy a jóváhagyáson, és megrendelésként tér vissza a beszállítóhoz. A vásárlás a webshopban történik; az irányítás, a keretek és a jóváhagyások a vevőnél maradnak.

Ez a cikk elmagyarázza azt a két protokollt, amely ezt a körutat hordozza, a cXML PunchOutot és az SAP Open Catalog Interface-t a Secure OCI-val együtt, hogy mit kell egy beszállítói webshopnak megvalósítania és védenie, ki kér punchoutot, mennyibe kerül egy átjáró a saját fejlesztéshez képest, mikor rossz eszköz a punchout, és ad egy élesítési ellenőrzőlistát.

Milyen problémát old meg a punchout?

Lehetővé teszi, hogy a nagy vevők megtartsák a beszerzési szabályaikat, miközben a beszállító webshopját használják. A beszerzési osztályok azt akarják, hogy minden vásárlás a saját rendszerükön menjen át a keretek, költséghelyek és jóváhagyások miatt, de a beszállító katalógusát, konfigurátorát és szerződéses árait nem akarják maguk karbantartani. A punchout megosztja a feladatot: a beszállító működteti a vásárlási élményt, a vevő rendszere dönt.

Ezért jelenik meg a punchout gyakran szerződési feltételként a nagyvállalati és közszféra-ügyletekben. A beszállító számára megváltozik, mit jelent a „kész”: a webshop már nem a vásárlás vége, hanem egy állomás valaki más folyamatának közepén, és a visszaküldött kosár minden sorának olyannak kell lennie, amit a vevő ERP-je le tud könyvelni.

Hogyan működik a cXML PunchOut körút?

Három cXML-üzenet hordozza: egy PunchOutSetupRequest és a válasza szerver-szerver kapcsolatban nyitja meg a munkamenetet, egy PunchOutOrderMessage pedig a vásárló böngészőjén keresztül hozza vissza a kosarat. A cXML-t a cxml.org gondozza, a jelenlegi változat 2026 augusztusa óta az 1.2.071, és a katalógusokat, rendeléseket, visszaigazolásokat, szállítási értesítőket és számlákat is lefedi (cXML.org).

<cXML payloadID="1760600000.4711@buyer.example" timestamp="2026-10-08T09:12:00+02:00">
  <Header>
    <From><Credential domain="NetworkID"><Identity>BUYER-123</Identity></Credential></From>
    <To><Credential domain="DUNS"><Identity>SUPPLIER-456</Identity></Credential></To>
    <Sender>
      <Credential domain="NetworkID">
        <Identity>BUYER-123</Identity>
        <SharedSecret>…</SharedSecret>
      </Credential>
      <UserAgent>Procurement 2026</UserAgent>
    </Sender>
  </Header>
  <Request>
    <PunchOutSetupRequest operation="create">
      <BuyerCookie>8f3c1a…</BuyerCookie>
      <Extrinsic name="UserEmail">p.huber@buyer.example</Extrinsic>
      <BrowserFormPost><URL>https://procurement.buyer.example/punchout/return</URL></BrowserFormPost>
    </PunchOutSetupRequest>
  </Request>
</cXML>

• Beállítási kérés: tartalmazza az operation="create", inspect vagy edit értéket, egy BuyerCookie-t, amellyel a vevő a visszaérkező kosarat a felhasználóhoz rendeli, és a BrowserFormPost URL-t, ahová a kosarat küldeni kell; a felhasználói adatok Extrinsic elemként vagy Contactként érkeznek, és beszerzési rendszerenként eltérnek (PunchOutCommerce).
• Beállítási válasz: 200-as Status és egy StartPage URL, amely bejelentkezteti a vásárlót. Bevált minta, hogy a kérést véletlenszerű munkamenet-azonosítóval tároljuk, a vásárló érkezésekor ellenőrizzük, és a fel nem használt azonosítókat nagyjából öt perc után lejárttá tesszük.
• Kosár visszaküldése: a böngésző által a BrowserFormPost URL-re küldött HTML-űrlap, amelyben a cXML egy cXML-urlencoded nevű rejtett mezőben utazik. A PunchOutOrderMessage-nek vissza kell adnia a BuyerCookie-t, és minden ItemIn tartalmazza a mennyiséget, a SupplierPartID-t, az egységárat, a leírást és a mennyiségi egységet (PunchOutCommerce).

Két részlet okozza a legtöbb éles hibát. A visszaküldött kosár árajánlat, nem rendelés; a valódi rendelés később cXML OrderRequestként érkezik, és a minden sorra tett SupplierPartAuxiliaryID-nek változatlanul vissza kell jönnie ezen a rendelésen, mert gyakran ez az egyetlen kapcsolat egy konfigurált termékhez vagy szerződéses árhoz. A BuyerCookie pedig nem hitelesítés: a beszállítón keresztül utazik, így a vevő ne bízzon kizárólag benne a visszatéréskor, a beszállító pedig soha ne tegyen bele titkot.

Hogyan működik az SAP OCI, egyszerűen és biztonságosan?

Az OCI HTML-űrlapokra épülő protokoll: az SAP paraméterekkel indítja a katalógus URL-jét, a katalógus pedig rejtett űrlapmezőkként egy visszatérési címre küldi vissza a kosarat. Az indítás jellemzően USERNAME és PASSWORD paramétert tartalmaz, a kötelező HOOK_URL-t, ahová a kosárnak mennie kell, valamint keretes munkamenetekhez a ~TARGET űrlapcélt; a hozzáférési adatok POST-törzsbe valók, mert a GET felfedi őket az URL-ekben és a naplókban (PunchOutCommerce).

<form method="post" action="{HOOK_URL from the launch request}" target="{~TARGET}">
  <input type="hidden" name="NEW_ITEM-DESCRIPTION[1]" value="Cable gland M20x1.5 IP68">
  <input type="hidden" name="NEW_ITEM-QUANTITY[1]"    value="50">
  <input type="hidden" name="NEW_ITEM-UNIT[1]"        value="PCE">
  <input type="hidden" name="NEW_ITEM-PRICE[1]"       value="1.84">
  <input type="hidden" name="NEW_ITEM-CURRENCY[1]"    value="EUR">
  <input type="hidden" name="NEW_ITEM-VENDORMAT[1]"   value="70.112.04">
  <button type="submit">Transfer cart</button>
</form>

A mezők neve NEW_ITEM-*, például DESCRIPTION, QUANTITY, UNIT, PRICE, CURRENCY, VENDORMAT és MANUFACTMAT, a Unite műszaki dokumentációja szerint egyenként legfeljebb 255 karakter, az egyedi mezők legfeljebb 1000 karakter (Mercateo/Unite). A hatókör fontos: az OCI körút csak a katalógust és a vásárlást fedi le. Az elektronikus rendelések, visszaigazolások, szállítási értesítők és számlák nem részei a specifikációnak, és más csatornákon, például IDocként vagy EDI-n utaznak.

A Secure OCI kiveszi a hozzáférési adatokat a böngészőből. Az SAP OCI 5.0 specifikációjában a beszerzési rendszer először szerver-szerver hívással fordul a katalógus backendjéhez, például SECURE_AUTH_URL paraméterrel és az INITIALIZE függvénnyel, amely SessionId-t és SessionTransmissionId-t ad vissza; a böngésző indítása ezután csak a munkamenet-azonosítót viszi (SAP OCI 5.0). Két megkötés: az OCI 5.0 egy 2012-es SRM-dokumentum és a legfrissebb talált SAP OCI specifikáció, a jelenlegi S/4HANA dokumentáció pedig a karbantartási katalógus-forgatókönyvnél továbbra is csak az OCI 3.0-t és a korábbiakat nevezi támogatottnak (SAP Help). Kérdezze meg minden vevőtől, melyik verziót hívja a rendszere.

Mit kell a beszállítói webshopnak megvalósítania?

Egy beállítási végpontot, egy a beállítási kéréshez kötött munkamenetet, mindkét formátumú kosár-visszaküldést, ha mindkét fajta vevőt kiszolgálja, egy rendelési végpontot a cXML-hez, és a köréjük épülő fegyelmet: validálást, hibakódokat, naplózást és adatminőséget. A munka nagy része olyan részletekben van, amelyeket a vevők csak akkor vesznek észre, amikor elromlanak.

• Állapotkódok: 400 hiányzó vagy feldolgozhatatlan törzsnél, 401 érvénytelen küldőnél vagy megosztott titoknál, 500 kezeletlen hibánál, cXML Status elemként.
• Munkamenet-kötés: egy beállítási kérés, egy munkamenet, rövid lejárat, és a BuyerCookie szerveroldalon tárolva, hogy a kosár a megfelelő igényhez térjen vissza.
• Azonosítók: egyedi payloadID minden üzeneten, és olyan SupplierPartAuxiliaryID vagy VENDORMAT értékek, amelyeket a rendelésimport később fel tud oldani.
• Termékadat-minőség: olyan mennyiségi egységek, osztályozási kódok és szerződéses cikkek, amelyeket a vevő ERP-je elfogad. Az a sor, amelyet az ERP nem tud lekönyvelni, ügyfélszolgálati hívássá válik.
• Naplózás: munkamenetenként őrizzen meg minden bejövő és kimenő dokumentumot, hogy egy elbukott igény újrajátszható és megmagyarázható legyen.

Több mint tízévnyi, Spryker és Pimcore alapú B2B kereskedelmi és PIM-munka során azt tapasztaltam, hogy a punchout a katalógusadatok minőségét, a mértékegységeket, cikkszámokat, szerződéses cikkeket és osztályozási kódokat olyan hibává alakítja, amelyet az ügyfél a saját ERP-jében lát. Legalább annyira PIM-kérdés, mint protokollkérdés; az adatoldalt a Pimcore ERP delta szinkron tárgyalja. A konfigurált termékek is gyakori punchout-esetek, a konfigurátor szabályai pedig külön problémát jelentenek, lásd headless termékkonfigurátorok B2B-ben.

Ki kér punchoutot?

SAP Aribát, Coupát, Jaggaert vagy Oracle beszerzést használó nagyvállalati vevők, SRM- vagy S/4HANA-katalógust használó SAP-ügyfelek, és piactereken keresztül vásárló közszféra-szereplők. Az Amazon Business jól jelzi, mennyire általános ez: több mint 200 e-beszerzési rendszerrel integrálódik, a punchoutot jellemzően az első integrációnak nevezi, és cXML- és OCI-végpontot is üzemeltet (Amazon Business).

A beszállítókra vonatkozó szabályai jó mintát adnak a sajátjaihoz: a beállítási kérésben kötelező a felhasználó e-mail-címe, a visszaadott Supplier Part Auxiliary ID-nek vissza kell jönnie a megrendelésen, a payload-azonosítóknak egyedinek kell lenniük, csak új rendelések támogatottak, és a rendelések élesítés előtt tesztmódban futnak (Amazon Business integrációs útmutató). A „Level 2” punchout, amelyben a vevő rendszere kereshető indexet tart a cikkeiről, és a beállítási kérés közvetlenül egy termékoldalra viszi a vásárlót, az Ariba és a piacterek szóhasználata, nem az OCI specifikáció része.

Saját punchout vagy megvásárolt átjáró?

Vásároljon, ha sok vevőt kell sok beszerzési rendszeren gyorsan bekötni; építsen, ha kevés nagy vevő van ismert rendszereken, és van csapat, amely a protokollért felel. Egy átjáró előre elkészített kapcsolatokat és a vevőnkénti sajátosságok kezelését adja el. A TradeCentric, korábban PunchOut2Go, a középvállalati szintre évi 15 000–50 000 dollártól induló beszállítói árat tesz közzé háromévi minimális szerződéssel, a nagyvállalati szint egyedi ajánlat alapján megy, és 2026 októberében több mint 220 ERP- és e-beszerzési integrációt említ (TradeCentric).

Egy saját megoldáshoz őszintén szólva kell protokollonként egy beállítási végpont, munkamenet-kezelés, kosár-szerializálás két formátumban, rendelésimport, védett XML-feldolgozás, vevőnkénti tesztfiókok, és valaki, aki válaszol, amikor egy vevő beszerzési csapata megváltoztat egy mezőleképezést. Ezt a folyamatos felelősséget a három év múlva várható, nem az idei vevőszámra vetített átjáróárral vesse össze.

Bárhogy dönt, a protokollréteget tartsa külön a webshop magjától. A webshop adjon tiszta belső API-t a „munkamenet indítása ennek a vevői felhasználónak”, „ennek a kosárnak a szerializálása” és „ennek a rendelésnek az importja” műveletekhez, a cXML- vagy OCI-adapterek, illetve az átjáró pedig ezen kívül legyenek. Így egy vevő beszerzési rendszerének változása nem éri el a pénztár kódját, és a saját fejlesztés és a vásárlás közötti későbbi váltás körülhatárolt projekt lesz, nem újraírás.

Mikor rossz eszköz a punchout?

Ha a vevőnek csak a cikkeire és áraira van szüksége a saját rendszerében, egy hosztolt katalógusfájl is elég lehet; ha már ismert partnerrel cserél rendeléseket, egy API- vagy EDI-kapcsolat egyszerűbb. A punchout munkamenet- és felhasználói élmény protokoll, nem adatmodell, így nem javítja meg a termékadatokat, és egy böngészős lépést ad hozzá, amelynek működnie kell a vevő környezetében, beleértve a keretes munkameneteket és azok sütikezelését a mai böngészőkben.

A másik határt az ágensprotokollok jelentik. A UCP, az ACP és az AP2 olyan szoftverágenst feltételez, amely valaki nevében vásárol, más adattartalommal és irányítással; a punchout egy embert feltételez a vevő ERP-jében. A kettő megfér egymás mellett, az összevetés a UCP, ACP és AP2 útmutatóban és az agentic commerce felkészültség B2B webshopokban című cikkben található, amely a punchoutot tekinti ma a támogatott nagyvállalati útvonalnak.

Punchout élesítési ellenőrzőlista

1. Szerezzen tesztfiókot a vevő beszerzési rendszerében és vevőnkénti hozzáférési adatokat.
2. Gyűjtsön mintapayloadot a create, edit és inspect műveletekhez, és minden vevőspecifikus Extrinsic elemhez.
3. Tesztelje a kosár visszaküldését végponttól végpontig egy valódi böngészőben; én ezt a körutat Playwright MCP-vel szkriptelem, mert a böngészős űrlapküldés az a rész, amelyet az egységtesztek nem fednek le.
4. Ellenőrizze, hogy a SupplierPartAuxiliaryID vagy a VENDORMAT eljut-e a megrendelésig és a rendelésimportig.
5. Futtasson hibagyakorlatokat: rossz megosztott titok, lejárt munkamenet, hibás XML, DOCTYPE a payloadban.
6. Figyelje a beállítási késleltetést, a sikertelen kosár-visszaküldéseket és az ismeretlen cikkekre hivatkozó rendeléseket.
7. Zárja egy vevői átvételi teszttel, amely egy valódi igényt végigvisz a jóváhagyáson.

Ha punchoutot ad egy B2B webshophoz, vagy átjáró és saját réteg között dönt, nézze meg a B2B e-kereskedelmi munkámat.

Források

1. cXML.org (cXML 1.2.071)
2. PunchOutCommerce: cXML PunchOutSetupRequest
3. PunchOutCommerce: cXML PunchOutOrderMessage
4. PunchOutCommerce: OCI RoundTrip
5. SAP: Open Catalog Interface 5.0
6. SAP Help: OCI catalogs in S/4HANA Plant Maintenance
7. Mercateo/Unite: technical information on the OCI interface
8. Amazon Business: punchout integration instructions
9. Amazon Business: punchout
10. TradeCentric: pricing
11. OWASP: XML External Entity Prevention Cheat Sheet