Wenn Punchout Neuland für Sie ist, beginnen Sie mit unserem Leitfaden Wie Punchout funktioniert. Diese Seite richtet sich an Händler, die den prinzipiellen Ablauf kennen und klären müssen, welches Protokoll für ihr konkretes Projekt erforderlich ist. Kurz gesagt: Ihre Kunden entscheiden. SAP Ariba, Coupa, Jaggaer, Oracle und Workday erfordern cXML. SAP SRM, S/4HANA und der Großteil des deutschsprachigen Raums (DACH) setzen auf OCI. Was diese Wahl technisch bedeutet, erfahren Sie hier.
Welches Protokoll benötigen Sie?
- Nordamerikanische und globale Konzerne (Ariba, Coupa, Oracle): Sie benötigen cXML. Ein vollständiger Zwei-Wege-Ablauf mit elektronischer Bestellrückübertragung ist hier Standard.
- DACH- und europäische SAP-Einkäufer (SRM, ECC, S/4HANA): Sie benötigen OCI. HTML-Formularübertragung des Warenkorbs; der Bestellrückkanal muss frühzeitig individuell abgestimmt werden.
- Internationale Lieferanten: Über kurz oder lang benötigen Sie beide Protokolle. Beide aus einem zentralen Shopify-Katalog zu bedienen, verhindert Dateninkonsistenzen und doppelte Infrastruktur.
Zwei Ausprägungen derselben Grundidee
cXML ist dokumentenbasiert. Jede Interaktion erfolgt über ein valides, streng typisiertes XML-Dokument: PunchOutSetupRequest zur Sitzungseröffnung, PunchOutOrderMessage zur Warenkorbrückgabe und cXML OrderRequest für die finale Bestellung. Der klare Vorteil liegt in der Struktur: Der Warenkorb enthält saubere Metadaten wie UNSPSC-Klassifizierungen, ISO-Mengeneinheiten (UOM), Steuerdaten und Kostenstellen, die auf beiden Seiten validiert werden können.
OCI (Open Catalog Interface) basiert auf einem HTTP-Formular-Post. Das ERP-System des Einkäufers ruft Ihre Shop-URL mit einer HOOK_URL-Rücksprungadresse auf. Beim Abschluss überträgt Ihr Shop die Positionen als unsichtbares HTML-Formular mit nummeriertenNEW_ITEM-*-Feldern an das ERP zurück. Es gibt keine XML-Schemata und keine systemseitige Validierung. OCI ist schnell implementiert, stößt aber an Grenzen, sobald zusätzliche Datenfelder oder komplexe Attribute benötigt werden.
| Kriterium | cXML (Commerce XML) | OCI (Open Catalog Interface) |
|---|---|---|
| Architektur | Dokumentenbasiertes XML via HTTP POST | Browserbasierter HTML-Form-Post (HOOK_URL) |
| Warenkorb-Transfer | PunchOutOrderMessage (cxml-urlencoded oder cxml-base64) | Automatisch absendendes Formular mit indexierten NEW_ITEM-*-Feldern |
| Bestellrücklauf (PO) | Nativer cXML OrderRequest direkt an den Endpunkt | Nur Warenkorb. Bestellung erfolgt separat (EDI, E-Mail, cXML oder manuell) |
| Schema-Validierung | Strikte DTD/XSD-Validierung auf beiden Seiten | Keine. Beliebige Feldnamen und herstellerspezifische Längen |
| Warengruppen & Einheiten | Verpflichtende Elemente für UnitOfMeasure und UNSPSC | Optionale Felder NEW_ITEM-MATGROUP und NEW_ITEM-UNIT |
| Verbreitung | SAP Ariba, Coupa, Jaggaer, Oracle, Workday | SAP SRM, SAP ERP (ECC, S/4HANA), DACH-Industrieunternehmen |
| Typische Fehlerquellen | Fehlendes UOM-Mapping (Stück vs. PCE/EA), Bereinigung der Hilfs-ID | Verlust im iFrame (erfordert returntarget), Zugangsdaten in GET-URLs |
Der Rückkanal: Der entscheidende Unterschied
cXML-Bestellungen werden dauerhaft gespeichert, mit dem übertragenen Warenkorb abgeglichen und im Posteingang „Purchase orders“ der PunchRelay-App abgelegt. In Shopify entsteht nichts, bis jemand aus Ihrem Team die Bestellung prüft und auf „Create Shopify order“ klickt. Dann wird die Order unbezahlt angelegt, mit ausstehender Zahlung, bereit für den Versand. OCI standardisiert hingegen ausschließlich die Warenkorbrückgabe. Der Bestellrückkanal muss für jeden Einkäufer gesondert vereinbart und getestet werden.
Die OCI-Bestellrücklauf-Lücke
Da OCI keinen Standard für die Rückübermittlung von Bestellungen definiert, stoppen viele traditionelle Punchout-Tools nach dem Warenkorb-Transfer. Der Händler muss Aufträge anschließend mühsam aus E-Mails oder PDF-Ausdrucken abtippen. In PunchRelay ist der cXML OrderRequest nativ integriert. OCI-Kunden, die cXML-Bestellungen senden können, nutzen denselben Weg: Die Bestellung landet in Ihrem Posteingang, und Ihr Team legt die Shopify-Order an.
Praxis-Tücken, die in keiner Spezifikation stehen
Der formale Spezifikationsvergleich spart die Punkte aus, mit denen Integrationsteams die meiste Zeit verbringen: herstellerspezifische Dialekte.
- Der cXML-Warenkorbtransfer erfolgt bei einem Kunden als
cxml-urlencoded, beim nächsten alscxml-base64. Dies muss pro Verbindung konfigurierbar sein. - cXML verlangt Mengeneinheiten (ISO UOM) und UNSPSC-Codes – Daten, die in einem normalen Online-Shop selten gepflegt sind. Lieferanten benötigen vor dem ersten Testlauf ein Mapping (z. B. PCE, KGM, LTR).
- cXML besitzt kein Standardfeld, um eine Bestellung direkt der auslösenden Sitzung zuzuordnen. Die Verknüpfung erfolgt meist über
SupplierPartAuxiliaryID; schneidet das Einkäufersystem dieses Feld ab, ist eine gesonderte Zuordnung erforderlich. - OCI bietet überhaupt kein Standard-Korrelationsfeld. OCI 4.0 stellt
NEW_ITEM-CUST_FIELD1bis 5 bereit; ob das SAP-System diese Felder speichert, muss individuell geprüft werden. - SAP bindet den Punchout-Katalog häufig in einem iFrame ein. Das Rückgabeformular muss den Parameter
returntargetzwingend berücksichtigen, sonst bleibt der Warenkorb im iFrame gefangen. - OCI-Aufrufe erfolgen mitunter als HTTP GET, wodurch Zugangsdaten in der URL stehen. Logs müssen maskiert und Kunden möglichst auf HTTP POST umgestellt werden. Da es bei OCI keine Empfangsbestätigung des ERP gibt, sind vollständige Sitzungsprotokolle unverzichtbar.
Erst nach Zielmarkt wählen, dann beides unterstützen
Im nordamerikanischen Markt dominiert cXML (Ariba, Coupa, Oracle). In Europa und speziell im DACH-Raum ist OCI überall dort gesetzt, wo SAP den Einkauf steuert. Lieferanten mit internationalen Kunden benötigen früher oder später beide Schnittstellen.
PunchRelay vereint beide Protokolle nahtlos auf Basis Ihres Shopify B2B-Katalogs. Wählen Sie den passenden Einstieg für Ihr Kundenprojekt: SAP Ariba, Coupa oder OCI für SAP.