Punchout und OCI-Kataloge für die B2B-Beschaffung im Shop

Punchout bezeichnet ein Integrationsmuster, bei dem ein Besteller aus seinem Einkaufssystem heraus per Klick in den Online-Shop eines Lieferanten "durchstößt" (englisch: to punch out), dort einen Warenkorb zusammenstellt und diesen Warenkorb anschließend automatisch zurück in sein eigenes System übergibt. Der entscheidende Unterschied zum normalen Webshop-Besuch: Der Besteller verlässt seine gewohnte Einkaufsumgebung nie wirklich. Die Bestellung durchläuft danach den internen Genehmigungs-Workflow des Kunden, und erst die freigegebene Bestellung wird als verbindlicher Auftrag an den Lieferanten übermittelt.

Für den Einkäufer hat das einen klaren Vorteil: Er sieht jederzeit aktuelle Produktdaten, kundenindividuelle Preise und die echte Verfügbarkeit, statt mit einem veralteten statischen Katalog zu arbeiten. Für den Lieferanten bedeutet eine Punchout-Anbindung, dass er Teil der digitalen Lieferantenliste großer Einkaufsorganisationen wird -- und damit überhaupt erst für automatisierte Bestellungen in Frage kommt. In vielen Ausschreibungen ist eine funktionierende Schnittstellen-Anbindung inzwischen ein Muss-Kriterium und kein Nice-to-have mehr.

Abzugrenzen ist Punchout vom klassischen statischen Katalog. Bei einem statischen Katalog liefert der Lieferant seine Artikeldaten einmalig oder periodisch als Datei (etwa im BMEcat-Format) an das Einkaufssystem, wo sie lokal gespeichert und durchsucht werden. Das funktioniert für ein überschaubares, selten wechselndes Sortiment. Sobald jedoch Preise differenziert, Sortimente groß und Verfügbarkeiten dynamisch sind, stößt der statische Katalog an seine Grenzen -- und Punchout wird zur sinnvolleren Variante.

Das Open Catalog Interface (OCI) wurde von SAP entwickelt und ist im deutschsprachigen Raum der mit Abstand verbreitetste Punchout-Standard, weil viele Industrie- und Handelsunternehmen sowie öffentliche Verwaltungen SAP-basierte Beschaffungslösungen einsetzen (SAP). OCI ist bewusst schlank gehalten: Die Datenübergabe erfolgt nicht über komplexe XML-Nachrichten, sondern über simple HTML-Formularfelder, die per HTTP-POST zwischen den Systemen ausgetauscht werden (SAP OCI-Spezifikation). Genau diese Einfachheit hat OCI zu seiner großen Verbreitung verholfen. Der Bundesverband Materialwirtschaft, Einkauf und Logistik weist Punchout und elektronische Kataloge als etablierte Bausteine moderner E-Procurement-Prozesse aus (BME).

Der Ablauf beginnt mit dem sogenannten Hook-URL-Aufruf. Das Einkaufssystem ruft eine vereinbarte URL des Lieferanten-Shops auf und übergibt dabei Anmeldedaten sowie eine Rücksprung-Adresse (die HOOK_URL). Der Shop authentifiziert den Besteller, ordnet ihn dem richtigen Kundenkonto mit den passenden Preisen zu und zeigt seinen Katalog an. Stellt der Besteller seinen Warenkorb zusammen und klickt auf "Warenkorb übernehmen", schickt der Shop die Positionen über vordefinierte Feldnamen wie NEW_ITEM-DESCRIPTION, NEW_ITEM-PRICE oder NEW_ITEM-QUANTITY zurück an die HOOK_URL. Das Einkaufssystem liest diese Felder aus und befüllt seine Bestellanforderung.

Aktuell sind vor allem die Versionen OCI 4.0 und OCI 5.0 relevant (SAP OCI-Spezifikation). OCI 5.0 ergänzt unter anderem eine sauberere Trennung von Validierungs- und Detailaufrufen sowie zusätzliche Felder für Vertragsbezüge. In der Praxis verlangen viele Kundensysteme weiterhin OCI 4.0, sodass eine Anbindung idealerweise beide Versionen bedienen sollte (Projekterfahrung). Welche Felder Pflicht und welche optional sind, hängt vom konkreten Zielsystem ab -- ein verbindliches Feld-Mapping mit dem Einkauf des Kunden ist daher der wichtigste erste Schritt jeder OCI-Integration.

Unabhängig vom konkreten Standard folgt jede Punchout-Session demselben Grundmuster. Es lohnt sich, den Ablauf einmal vollständig nachzuvollziehen, weil sich daraus alle technischen und organisatorischen Anforderungen ableiten lassen. Die folgenden Schritte beschreiben eine typische Session am Beispiel von cXML, das von SAP Ariba und Coupa genutzt wird, der OCI-Ablauf verläuft analog.

Wichtig ist die Unterscheidung zwischen der Warenkorb-Übergabe und der eigentlichen Bestellung. Beim Punchout wird zunächst nur ein Warenkorb-Vorschlag zurückgegeben -- noch kein Auftrag. Die verbindliche Bestellung entsteht erst nach der internen Freigabe beim Kunden und läuft häufig über einen separaten Bestellkanal. Diese Trennung ist gewollt, weil große Organisationen Bestellungen oberhalb bestimmter Wertgrenzen mehrstufig genehmigen müssen. Ein durchdachtes B2B-Portal berücksichtigt diese Prozesse von Anfang an.

Der größte Mehrwert von Punchout gegenüber dem statischen Katalog liegt in der Personalisierung. Sobald der Besteller über die Punchout-Session im Shop ankommt, weiß der Shop, zu welchem Kunden er gehört -- und kann genau das Sortiment, die Konditionen und die Preise anzeigen, die für diesen Kunden vereinbart wurden. Im B2B sind das oft komplexe Strukturen: Rahmenvertragspreise, Staffelpreise nach Abnahmemenge, kundenspezifische Artikelnummern und freigegebene Teilsortimente.

In der Praxis bedeutet das, dass die Punchout-Anbindung eng mit der Preis- und Kundenlogik des Shops verzahnt sein muss. Kundenindividuelle Preise und Staffelungen sind ein eigenes, anspruchsvolles Thema -- wie sie sich in Shopware abbilden lassen, beschreiben wir ausführlich im Beitrag zu B2B-Preislisten und Staffelpreisen in Shopware. Für die Punchout-Session ist entscheidend, dass die übergebenen Preise exakt den vertraglich vereinbarten entsprechen, denn sie fließen ungeprüft in die Bestellanforderung des Kunden ein.

Auch das Sortiment lässt sich pro Kunde steuern. Manche Einkaufsorganisationen erlauben ihren Bestellern nur einen freigegebenen Ausschnitt des Lieferanten-Sortiments -- etwa um Wildwuchs zu vermeiden oder Compliance-Vorgaben einzuhalten. Ein gut umgesetztes Kundenportal erlaubt es, solche kundenspezifischen Kataloge zentral zu pflegen, statt für jeden Kunden eine eigene Shop-Instanz zu betreiben. Die kundenspezifischen Artikelnummern (Customer Part Numbers) sollten in beiden Richtungen übersetzt werden, damit der Kunde "seine" Nummer sieht und das Lieferanten-ERP dennoch die eigene führende Artikelnummer erhält.

Weil über die Punchout-Session sensible Konditionsdaten und letztlich verbindliche Bestellungen fließen, ist die Absicherung der Verbindung ein zentraler Aspekt. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt im IT-Grundschutz durchgängig verschlüsselte Übertragung und eine eindeutige Authentifizierung kommunizierender Systeme (BSI). Für Punchout heißt das konkret: Die gesamte Kommunikation läuft über HTTPS mit aktuellem TLS, und beide Seiten authentifizieren sich über ein gemeinsames Geheimnis (Shared Secret) oder Zertifikate.

Bei cXML wird die Authentifizierung über Sender-, From- und To-Credentials im Dokumentkopf realisiert, ergänzt um ein Shared Secret (cXML-Standard). Bei OCI erfolgt die Anmeldung typischerweise über Benutzername und Passwort, die im Hook-URL-Aufruf mitgegeben werden -- weshalb hier HTTPS absolut unverzichtbar ist, damit diese Daten nicht im Klartext über das Netz wandern (BSI). In beiden Fällen sollten Session-Token zeitlich begrenzt gültig sein und nach Abschluss oder Ablauf der Session ungültig werden.

Ergänzend haben sich weitere Schutzmaßnahmen bewährt: IP-Whitelisting beschränkt die zulässigen Absender auf die bekannten Adressbereiche der Einkaufssysteme, eine Signaturprüfung der zurückgegebenen Warenkörbe verhindert Manipulationen, und ein dediziertes Logging aller Punchout-Vorgänge erleichtert die Fehlersuche und erfüllt Nachweispflichten. Da personenbezogene Daten der Besteller verarbeitet werden, gehört die Punchout-Anbindung außerdem in das Verzeichnis der Verarbeitungstätigkeiten nach DSGVO -- ein Punkt, der in der technischen Begeisterung gern übersehen wird.

Shopware in der Open-Source-Variante bringt die Bausteine mit, die für eine Punchout-Anbindung nötig sind: ein flexibles Plugin-System, eine REST- und Store-API sowie ein erweiterbares Konzept für Kundengruppen und Preise. Die Punchout-Logik selbst wird üblicherweise als eigenes Plugin umgesetzt, das die eingehenden Setup-Requests verarbeitet, die Session verwaltet und die Warenkorb-Übergabe im jeweiligen Format (OCI-Felder oder cXML) erzeugt.

Ein typischer Einstiegspunkt ist ein Controller, der die Hook-URL des Einkaufssystems entgegennimmt. Das folgende Beispiel skizziert vereinfacht, wie ein solcher Punchout-Login-Controller in einem Shopware-Plugin aufgebaut sein kann -- die eigentliche Geschäftslogik (Kundenermittlung, Preisfindung, Session-Handling) ist hier bewusst ausgespart.

Die Rückgabe des Warenkorbs erfolgt anschließend über ein zur HOOK_URL abgeschicktes Formular (OCI) beziehungsweise eine an die Browser-Form-POST-URL gesendete PunchOutOrderMessage (cXML). Wichtig ist, dass jede Position vollständig beschrieben wird: Artikelnummer, Beschreibung, Menge, Einzelpreis, Währung, Mengeneinheit und gegebenenfalls die Kunden-Artikelnummer. Fehlende oder falsch formatierte Felder sind die häufigste Ursache dafür, dass ein Warenkorb im Einkaufssystem nicht korrekt ankommt. Für die Schnittstellen-Integration empfiehlt sich daher ein ausführliches Logging jeder übergebenen Position.

Die nachgelagerte Verarbeitung der eigentlichen Bestellung -- also der Eingang des freigegebenen Auftrags -- erfolgt häufig über EDI oder eine cXML-OrderRequest-Schnittstelle und mündet im ERP. Damit schließt sich der Kreis von der Katalogansicht bis zur Auftragsabwicklung. Welche Architekturmuster sich für solche durchgängigen Integrationen eignen, vertiefen wir in unseren Leistungen rund um ERP-Anbindung und in den begleitenden Fachartikeln im Blog.

Punchout-Projekte scheitern selten an der grundsätzlichen Technik, sondern an Details im Zusammenspiel der Systeme. Ein wiederkehrendes Problem ist das Feld-Mapping: Wenn das Einkaufssystem ein Pflichtfeld erwartet, das der Shop nicht oder anders befüllt, landet der Warenkorb unvollständig in der Bestellanforderung. Nach unserer Erfahrung ist dies die häufigste Ursache für fehlgeschlagene Erstanbindungen (Projekterfahrung). Ein verbindlich abgestimmtes Mapping-Dokument zwischen Lieferant und Einkauf des Kunden verhindert genau das.

Ein zweiter Klassiker betrifft die Preisformate und Mengeneinheiten. Unterschiedliche Nachkommastellen, abweichende Währungsangaben oder verwechselte Mengeneinheiten (Stück versus Verpackungseinheit) führen zu Differenzen zwischen Warenkorb und späterer Bestellung. Hier hilft eine klare Normalisierung der Daten vor der Übergabe. Auch das Session-Timing ist heikel: Läuft eine Session ab, während der Besteller noch im Katalog stöbert, schlägt die Warenkorb-Übergabe fehl. Großzügig bemessene, aber dennoch begrenzte Session-Laufzeiten sind ein sinnvoller Kompromiss zwischen Komfort und Sicherheit.

Schließlich wird der Testaufwand häufig unterschätzt. Jedes Zielsystem -- ob SAP Ariba, Coupa oder ein hauseigenes SRM -- verhält sich in Nuancen anders. Eine Punchout-Anbindung sollte daher immer in einer Testumgebung des Kunden geprüft werden, bevor sie produktiv geht. Da die Einkaufssysteme der Kunden meist nicht frei zugänglich sind, ist die enge Abstimmung mit der IT des Kunden in der Testphase erfolgskritisch. In unserer E-Commerce-Beratung planen wir diese Abstimmungsschleifen von Anfang an ein.

Eine Punchout-Anbindung ist mit Aufwand verbunden -- sie lohnt sich, sobald ein oder mehrere Großkunden ihre Bestellungen über ein zentrales Einkaufssystem abwickeln. Typische Szenarien aus solchen Projekten zeigen wir in unseren Referenzen. Der wirtschaftliche Nutzen entsteht auf beiden Seiten: Der Kunde spart manuelle Erfassungsschritte und reduziert Maverick-Buying, der Lieferant senkt seine Auftragsbearbeitungskosten und bindet den Kunden enger an sein Sortiment. Studien zur Beschaffung beziffern den Aufwand für eine manuell bearbeitete Bestellung regelmäßig auf einen deutlich zweistelligen Eurobetrag pro Bestellvorgang (Hackett Group) -- Automatisierung über Punchout reduziert diesen Anteil erheblich.

Auch strategisch ist Punchout relevant: Laut Gartner verlagern Geschäftskunden zunehmend Budget in digitale Selbstbedienungskanäle, weil ein wachsender Teil der jüngeren Einkäufer-Generation digitale Bestellwege bevorzugt (Gartner). Wer als Lieferant in den digitalen Beschaffungsprozessen seiner Kunden nicht präsent ist, riskiert, bei der nächsten Lieferantenkonsolidierung übersehen zu werden. Der Branchenverband Bitkom verweist seit Jahren darauf, dass die Digitalisierung von Geschäftsprozessen ein wesentlicher Wettbewerbsfaktor für den deutschen Mittelstand ist (Bitkom).

Die Kosten einer Punchout-Anbindung hängen stark von der Zahl der anzubindenden Zielsysteme und der Komplexität der Preis- und Sortimentslogik ab. Eine erste OCI-Anbindung an ein einzelnes Einkaufssystem ist überschaubar; mit jedem weiteren System und jeder kundenspezifischen Besonderheit steigt der Aufwand. In der Regel amortisiert sich die Investition über das eingesparte manuelle Handling und das zusätzliche Bestellvolumen der angebundenen Kunden. Eine belastbare Wirtschaftlichkeitsrechnung lässt sich am besten gemeinsam im Erstgespräch auf Basis Ihrer konkreten Kundenstruktur erstellen.