OCI-Punchout: Beschaffungsportale an den Shop koppeln

Punchout beschreibt einen einfachen, aber wirkungsvollen Mechanismus: Statt Artikel und Preise als statische Katalogdatei ins Beschaffungssystem des Kunden zu laden, verbindet sich dieses System zur Laufzeit direkt mit Ihrem Shop. Der Einkäufer arbeitet in seiner gewohnten Beschaffungsumgebung, klickt Ihren Lieferantenkatalog an und wird per Session-Handoff in Ihren Shop weitergeleitet. Dort browst er ein aktuelles Sortiment mit seinen Konditionen und schickt den fertigen Warenkorb strukturiert zurück in seinen Genehmigungs- und Bestellprozess. Der Begriff Punchout meint genau dieses Durchreichen aus dem einen System in das andere und wieder zurück.

Für diesen Handoff haben sich zwei Standards etabliert. Das Open Catalog Interface, kurz OCI, wurde von SAP entwickelt und übergibt Warenkorbdaten über HTTP mit URL-Parametern und HTML-Formularfeldern (SAP Open Catalog Interface). Es ist schlank und in SAP-geprägten Einkaufssystemen weit verbreitet. cXML, die Commerce eXtensible Markup Language, wurde 1999 von Ariba veröffentlicht und tauscht die Punchout-Nachrichten als validierbare XML-Dokumente aus (cXML Reference Guide). Beide erreichen dasselbe Ziel, unterscheiden sich aber im Datenformat und im Funktionsumfang. Welcher Standard gefragt ist, gibt das Beschaffungssystem Ihres Kunden vor, weshalb eine belastbare SAP-Anbindung idealerweise beide Wege beherrscht.

Der wirtschaftliche Hintergrund macht deutlich, warum sich der Aufwand lohnt. Der deutsche B2B-Internethandel über Shops und Marktplätze erreichte zuletzt rund 476 Milliarden Euro und wuchs mit 11,7 Prozent deutlich schneller als der Endkundenhandel (Statista). Wer als Großhändler oder Hersteller in diesem Segment mit großen Einkaufsorganisationen wachsen will, kommt an Punchout kaum vorbei, denn die Einkaufsabteilungen dieser Kunden bestellen nun einmal aus ihrem eigenen System heraus und nicht über einen separaten Shop-Login.

In vielen Großhandelsbeziehungen läuft die Bestellung noch immer über Fax, PDF-Anhang oder eine formlose E-Mail. Jede dieser Bestellungen muss auf der Empfängerseite von Hand erfasst werden: Artikelnummern abtippen, Mengen prüfen, Preise abgleichen, Auftrag anlegen. Das ist langsam, bindet Personal und ist fehleranfällig. Der BME beziffert, dass rund 60 Prozent der Unternehmen fehlende Personal- und Zeitressourcen als größtes Hindernis der Digitalisierung nennen (BME) - genau diese Ressourcen bindet die manuelle Auftragserfassung. Digitalisierte Beschaffung setzt an dieser Stelle an, weil Bestellung, Freigabe und Auftragsanlage ohne Medienbruch ineinandergreifen.

Der Effekt ist messbar in der Studienlage. Fast alle Unternehmen können durch Digitalisierung den Bestellvorgang vereinfachen (95 Prozent), und 92 Prozent berichten von einer einfacheren Kommunikation mit ihren Geschäftspartnern (Bitkom). Zugleich räumen 53 Prozent ein, mit der Umsetzung der Digitalisierung noch Schwierigkeiten zu haben (Bitkom) - der Bedarf ist also erkannt, die technische Brücke fehlt oft. Punchout ist eine dieser Brücken: Es macht Ihren Shop zum digitalen Bestellkanal für genau die Kunden, die heute noch faxen. Für Themen wie Bonität und Kreditlimit im Bestellprozess lohnt der Blick in unseren Beitrag zum Kreditlimit-Check im B2B-Checkout.

Technisch ist Punchout ein Roundtrip in mehreren Schritten, der komplett über HTTP läuft. Am Anfang steht der Setup: Das Beschaffungssystem sendet eine Anfrage an Ihren Shop, authentifiziert sich und übergibt eine sogenannte HOOK_URL, an die der Warenkorb später zurückgeschickt wird. Ihr Shop legt daraufhin eine Session an und antwortet mit der Start-Adresse des Katalogs. Von dort browst der Einkäufer, stellt seinen Warenkorb zusammen und löst den Abschluss aus. Beim Abschluss wird der Warenkorb strukturiert an die HOOK_URL zurückgegeben, landet als Bestellanforderung im Genehmigungs-Workflow des Kunden und wird nach Freigabe zur eigentlichen Bestellung. Diese saubere Trennung von Katalog-Session und tatsächlicher Bestellung ist ein wiederkehrendes Muster in der API-Entwicklung für den Handel.

Der Ausschnitt zeigt das Grundprinzip von OCI: Der Setup-Aufruf reicht Benutzerkontext und HOOK_URL durch, und die Rückgabe erfolgt als HTML-Formular mit NEW_ITEM-Feldern, das der Browser an die HOOK_URL sendet. cXML löst denselben Ablauf über XML-Dokumente: ein PunchOutSetupRequest zum Start, eine PunchOutSetupResponse mit der Start-Adresse und eine PunchOutOrderMessage für den Warenkorb. Weil der Handoff über HTTP und die Sitzung des Einkäufers läuft, sind Authentifizierung und Absicherung der Endpunkte zentral. Wie man solche Schnittstellen gegen Angriffe härtet, behandelt der Beitrag zur NIS2-konformen Absicherung von ERP-Schnittstellen. Ob der Roundtrip robust läuft, entscheidet in der Praxis die dazwischenliegende Middleware, die Session, Mapping und Fehlerbehandlung übernimmt.

OCI und cXML verfolgen dasselbe Ziel, wurden aber aus unterschiedlichen Blickwinkeln entworfen. OCI ist bewusst schlank: HTML-Formularfelder und URL-Parameter genügen, um einen Warenkorb zurückzugeben. Das macht die Anbindung unkompliziert, stößt aber bei sehr komplexen oder konfigurierbaren Produkten an Grenzen, weil das Datenmodell weniger Felder vorsieht (SAP Open Catalog Interface). cXML ist dokumentenbasiert und reichhaltiger: Es kennt formale XML-Schemata, unterstützt Server-zu-Server-Nachrichten und kann neben dem Katalog-Roundtrip auch die eigentliche Bestellung als OrderRequest transportieren (cXML Reference Guide).

In der Praxis ist die Frage OCI oder cXML selten eine Entweder-oder-Entscheidung, sondern hängt am jeweiligen Kunden. Ein Großkunde mit SAP-Einkauf erwartet oft OCI, eine große Einkaufsorganisation auf einer e-Procurement-Plattform meist cXML. Eine tragfähige Anbindung bildet daher beide Protokolle auf ein gemeinsames internes Datenmodell ab, sodass jeder neue Kunde zur Konfiguration statt zur Neuentwicklung wird. Dieses Prinzip der protokollunabhängigen Mitte kennen Sie auch aus der EDI-Anbindung per EDIFACT, die im B2B-Handel oft parallel zu Punchout läuft. Für den strukturierten Bestell- und Belegfluss danach greift dieselbe SAP-Integration wie für klassische Aufträge.

Der eigentliche Wert von Punchout entsteht erst durch kundenindividuelle Inhalte. Wenn der Einkäufer per Handoff in Ihren Shop springt, soll er nicht den allgemeinen Webshop sehen, sondern genau das Sortiment und die Preise, die sein Rahmenvertrag vorsieht. Diese Individualisierung entscheidet darüber, ob Punchout als seriose Beschaffungslösung akzeptiert wird. Der BME nennt Echtzeit-Zusammenarbeit mit Lieferanten für mehr als 80 Prozent der Einkaufsverantwortlichen als entscheidenden Faktor (BME), und genau diese Nähe stellt ein individueller Punchout-Katalog her.

Die Preisfindung ist dabei der anspruchsvollste Teil. Kundenindividuelle Preise, Staffeln und zeitlich begrenzte Konditionen leben im ERP und müssen performant in den Katalog gelangen. Wie man das mit Synchronisation und Caching löst, vertieft unser Beitrag zur kundenindividuellen Preissynchronisation im B2B. Damit die übergebenen Artikelnummern auf beiden Seiten zusammenpassen, braucht es außerdem ein sauberes Mapping zwischen Kundenschlüssel und internem Katalog - ein Thema, das der Beitrag zum Daten-Mapping zwischen ERP und Shop im Detail behandelt.

Eine Punchout-Anbindung ist kein einmaliges Projekt, sondern eine Schnittstelle, die dauerhaft gepflegt werden will. Jeder Großkunde bringt eigene Anforderungen mit: ein anderes Protokoll, abweichende Feldbelegungen, eigene Artikelnummern, spezifische Kostenstellen-Logik. Deshalb legt eine belastbare Lösung die gesamte Punchout-Logik in eine Middleware zwischen Beschaffungssystem und Shop und nicht in den Shop selbst. Diese Schicht nimmt Setup-Requests entgegen, verwaltet Sessions, übersetzt zwischen OCI oder cXML und dem internen Modell und gibt den Warenkorb korrekt zurück. Der Shop bleibt so schlank und die kundenindividuelle Komplexität an einer Stelle beherrschbar - ein Ansatz, den wir in unseren Integrationsleistungen konsequent verfolgen.

Zur Wartung gehört mehr als der einmalige Aufbau. Kataloge veralten, Preise ändern sich, Verträge laufen aus, und Beschaffungssysteme aktualisieren ihre Punchout-Profile. Eine gepflegte Schnittstelle überwacht die Sessions, protokolliert fehlgeschlagene Rückgaben und fängt Formatabweichungen ab, bevor sie beim Kunden auffallen. In über 50 Integrationsprojekten hat sich gezeigt, dass die laufende Pflege - Katalogaktualisierung, Preisabgleich, Monitoring der Handoffs - über Erfolg oder Frust einer Punchout-Anbindung entscheidet (Projekterfahrung). Genau diese fortlaufende Betreuung ist der Kern einer Großhandels-Integration, die Kunden dauerhaft im Einkaufssystem hält. Welche Projektansätze dahinterstehen, zeigen unsere Referenzen.