Was ist OCI-Punchout?
Zuletzt aktualisiert: August 2026
OCI-Punchout bezeichnet im B2B-E-Procurement die Anbindung eines externen Lieferanten-Katalogs an das Beschaffungssystem des Kunden über das von SAP spezifizierte Open Catalog Interface (OCI). Einkäufer springen aus ihrem System per Klick in den Webshop des Lieferanten, stellen dort den Warenkorb zusammen und übergeben ihn automatisch zurück an das eigene System, wo die Bestellung freigegeben und abgewickelt wird.
Was ist ein Punchout?
Ein Punchout ist ein Katalog-Zugriffsverfahren im elektronischen Einkauf: Statt einen Katalog als Datei ins Beschaffungssystem zu laden, „durchschlägt“ (punch out) der Einkäufer aus seinem E-Procurement-System direkt in den Online-Shop des Lieferanten. Er bleibt dabei angemeldeter Nutzer seines eigenen Systems — Preise, Sortiment und Konditionen zeigt der Shop kundenindividuell an. Am Ende wandert nicht die Bestellung, sondern der Warenkorb zurück ins Beschaffungssystem: Dort laufen Genehmigung, Bestellung und Rechnungsprüfung wie gewohnt. Punchout ist damit ein Architekturprinzip; OCI und cXML sind die beiden verbreiteten Protokolle, die es technisch umsetzen.
Was ist ein OCI?
OCI steht für Open Catalog Interface — eine von SAP spezifizierte, offene Katalogschnittstelle. Sie verbindet externe Produktkataloge mit SAP-Beschaffungsanwendungen, sodass die Daten, die für Warenkorbpositionen benötigt werden, direkt aus dem externen Katalog übernommen werden (so definiert es die SAP-Spezifikation). Wenn im Einkauf von „einer OCI“ oder „der OCI-Schnittstelle“ die Rede ist, ist fast immer genau das gemeint: die Punchout-Anbindung eines Lieferanten-Shops nach diesem SAP-Standard. Weil die Spezifikation offen dokumentiert ist, haben sie über SAP hinaus viele E-Procurement-Plattformen und Shop-Systeme übernommen — OCI ist im deutschsprachigen B2B-Einkauf de facto die gemeinsame Sprache für Katalog-Anbindungen.
Wie funktioniert ein OCI-Punchout?
Technisch besteht ein OCI-Punchout aus zwei Schritten — einem Absprung und einer Rückgabe:
- Absprung (Call-up): Das Beschaffungssystem ruft die im System hinterlegte Katalog-URL des Lieferanten auf und übergibt dabei Parameter wie Login-Kennung, Sprache und die Rücksprungadresse (
HOOK_URL). Der Aufruf erfolgt per HTTP als GET oder POST. Der Einkäufer landet eingeloggt im Shop und sieht sein individuelles Sortiment mit seinen Preisen. - Rückgabe (Return): Ist der Warenkorb fertig, sendet der Shop die Positionsdaten über den Browser des Nutzers an die
HOOK_URLzurück — als Formular mit standardisierten Feldern (NEW_ITEM-DESCRIPTION,NEW_ITEM-QUANTITY,NEW_ITEM-PRICE,NEW_ITEM-MATGROUPusw.). Das Beschaffungssystem legt daraus die Warenkorbpositionen an.
Darüber hinaus definiert die OCI-Spezifikation Zusatzfunktionen, mit denen das Beschaffungssystem den Katalog auch ohne Nutzer-Session ansprechen kann: die Detailanzeige eines Produkts (DETAIL), die Validierung von Produktdaten (VALIDATE), die Produktsuche für das Sourcing (SOURCING) und die Hintergrundsuche (BACKGROUND_SEARCH).
Was ist ein Punchout-Katalog?
Ein Punchout-Katalog ist der Lieferanten-Webshop in seiner Rolle als angebundener Katalog: ein Online-Shop, der per OCI oder cXML aus dem E-Procurement-System des Kunden erreichbar ist und kundenindividuelle Sortimente, Preise und Konditionen ausspielt. Ein Beispiel: Ein Industrieunternehmen bindet den Shop seines Elektrogroßhändlers per OCI an sein SAP-Beschaffungssystem an. Der Instandhalter sucht den Leitungsschutzschalter im gewohnten Shop mit Live-Verfügbarkeit — bestellt wird aber über den geregelten Freigabeprozess seines Arbeitgebers. Der Lieferant pflegt sein Sortiment nur an einer Stelle, der Kunde behält Budget- und Genehmigungskontrolle.
Was ist der Unterschied zwischen Punchout-Katalog und statischem Katalog (BMEcat)?
Beim statischen Katalog liefert der Lieferant seine Produktdaten als Datei — im deutschsprachigen Raum meist als BMEcat — und der Kunde lädt sie in sein Beschaffungssystem. Beim Punchout bleiben die Daten im Shop des Lieferanten und werden live abgerufen. Beide Wege haben ihre Berechtigung, und viele Einkaufsorganisationen fordern beides:
| Punchout-Katalog (OCI/cXML) | Statischer Katalog (BMEcat-Upload) | |
|---|---|---|
| Datenhaltung | beim Lieferanten (Live-Shop) | beim Kunden (importierte Datei) |
| Preise/Verfügbarkeit | tagesaktuell aus dem Shop | Stand des letzten Katalog-Imports |
| Sortimentsgröße | auch sehr große, volatile Sortimente | praktikabel bei stabilen Kernsortimenten |
| Aufwand Lieferant | Shop mit Punchout-Fähigkeit betreiben | Katalogdatei je Kunde erzeugen und aktualisieren |
| Aufwand Kunde | einmalige Anbindung, kaum Datenpflege | Import, Prüfung und Freigabe je Katalogversion |
| Kontrolle Einkauf | Rahmenvertrag + Freigabeworkflow | zusätzlich inhaltliche Kontrolle über jede Katalogversion |
| Datenbasis beim Lieferanten | gepflegte Produktdaten im Shop — typischerweise aus dem PIM | Katalog-Export je Abnehmer — typischerweise aus dem PIM |
Die letzte Zeile zeigt den gemeinsamen Nenner: Ob Punchout-Shop oder BMEcat-Datei — beides sind Ausleitungen derselben Produktdatenbasis. Wie die Katalogübergabe per Datei funktioniert, erklärt unser Artikel zur Syndizierung von Produktdaten.
Was ist der Unterschied zwischen OCI- und cXML-Punchout?
OCI und cXML lösen dieselbe Aufgabe mit unterschiedlicher Herkunft und Technik. OCI ist die von SAP spezifizierte Schnittstelle: schlank, HTML-formularbasiert, im SAP-geprägten europäischen Einkauf weit verbreitet. cXML (commerce eXtensible Markup Language) ist ein XML-basiertes Protokoll aus dem Ariba-Umfeld, dokumentiert auf cxml.org und laufend weiterentwickelt; den Punchout bilden dort die Nachrichten PunchOutSetupRequest (Absprung) und PunchOutOrderMessage (Warenkorb-Rückgabe) ab. cXML dominiert in Ariba-Netzwerken und im nordamerikanischen Raum, kann aber über den Punchout hinaus auch Bestellungen, Bestelländerungen und Rechnungen als XML-Dokumente transportieren — OCI endet bewusst bei der Warenkorbübergabe. Für Lieferanten heißt das in der Praxis: Wer B2B-Kunden mit unterschiedlichen E-Procurement-Systemen bedient, braucht häufig beide Protokolle — idealerweise gespeist aus derselben Produktdatenquelle.
Welche OCI-Version ist aktuell?
Die aktuelle Version der Spezifikation ist OCI 5.0 (SAP, Spezifikationsdokument von 2013). Gegenüber OCI 4.0 ergänzt sie vier Fähigkeiten: die Replikation von Katalogdaten ins SAP-System (Mass Upload per JSON über HTTP(s) oder Datei, damit Nutzer katalogübergreifend suchen können), neue Felder zur Übergabe von Artikel-Hierarchien, Inbound-/Outbound-Handler sowie Secure OCI für die sichere Übertragung von Zugangsdaten. Wichtig: Ein OCI-5.0-konformer Katalog muss laut Spezifikation zugleich OCI-4.0-konform sein — die klassische Punchout-Mechanik per HTTP bleibt die Basis, und viele produktive Anbindungen laufen weiterhin auf dem 4.0-Funktionsumfang.
Welche E-Procurement-Systeme unterstützen OCI (SAP SRM, Ariba, Onventis)?
Spezifiziert wurde OCI für die SAP-Beschaffungswelt (SRM Server bzw. die Katalogschnittstelle der SAP-ERP-Anwendungen); auch aktuelle SAP-Lösungen binden externe Kataloge nach diesem Muster an. Weil die Spezifikation offen verfügbar ist, unterstützen darüber hinaus zahlreiche E-Procurement-Plattformen und Marktplätze im deutschsprachigen Raum OCI — etwa Onventis oder Unite/Mercateo. SAP Ariba arbeitet nativ mit cXML-Punchout; in Mischlandschaften begegnen Lieferanten deshalb regelmäßig beiden Standards. Auf der Gegenseite bringen viele B2B-Shop-Systeme eine OCI-Schnittstelle als Standard- oder Zusatzfunktion mit.
Welche Vorteile hat ein Punchout-Katalog im B2B-Vertrieb?
Für Lieferanten ist Punchout-Fähigkeit zunehmend Markteintrittsbedingung: Große Kunden und öffentliche Auftraggeber schreiben die Katalog-Anbindung per OCI oder cXML in Ausschreibungen schlicht als Pflichtanforderung fest. Wer sie erfüllt, wird direkt im Beschaffungssystem des Kunden sichtbar — an der Stelle, an der Bedarfsträger tatsächlich bestellen. Weitere Effekte: weniger Maverick Buying am Rahmenvertrag vorbei, weniger manuelle Bestellerfassung und Übertragungsfehler, tagesaktuelle Preise und Verfügbarkeiten statt veralteter Katalogstände — und eine engere Kundenbindung, denn eine einmal etablierte Anbindung wird selten wieder gekappt.
Welche Rolle spielt das PIM für den Punchout-Katalog (Datenqualität, Klassifikation)?
Ein Punchout-Katalog ist immer nur so gut wie die Produktdaten dahinter. Drei Anforderungen entscheiden, ob die Anbindung dem Kunden nützt: Vollständigkeit (jede Position braucht Beschreibung und Menge — mehr schreibt die OCI-Spezifikation formal nicht vor, in der Praxis verlangen Einkaufsorganisationen je Position aber auch Preis, Bestelleinheit und Warengruppe), Klassifikation (viele Einkaufsorganisationen verlangen je Position eine standardisierte Warengruppe, häufig nach ECLASS im E-Procurement, damit Spend-Analysen und Genehmigungsregeln greifen) und Aktualität über alle Kanäle hinweg. Genau das ist die Aufgabe eines PIM-Systems: Es hält Produktdaten, Klassifikationen wie ECLASS oder ETIM und kundenindividuelle Sortimente zentral — und speist daraus den Punchout-Shop genauso wie BMEcat-Exporte und Marktplatz-Feeds. Ohne diese Datenbasis wird jede Punchout-Anbindung zur Einzelpflege.
Einordnung: Wo sitzt OCI-Punchout im PIM/PXM/DAM-Gefüge?
OCI-Punchout ist ein Ausgabekanal — kein Datenhaltungssystem. Im Gefüge aus PIM-System (führende Quelle für Produktdaten und Klassifikationen), DAM (Mediendaten) und Kanalausleitung steht der Punchout-Katalog neben Shop, Marktplatz und Print als ein weiterer Abnehmer derselben medienneutralen Datenbasis. Das PIM sorgt dafür, dass der Shop, in den Deine Kunden „durchschlagen“, dieselben aktuellen und klassifizierten Daten zeigt wie jeder andere Kanal.
OCI-Punchout mit Produktdaten aus OMN
OMN, die PIM/DAM-Plattform von apollon, ist nicht selbst die Punchout-Schnittstelle — sie ist die Datenbasis dahinter. In OMN pflegst Du Produktdaten einmal zentral: Attribute, Medien, Preise-relevante Stammdaten und Klassifikationen wie ECLASS und ETIM, auf Wunsch je Kunde oder Sortiment differenziert. Über das Channel Management leitest Du diese Daten an Deinen B2B-Shop mit OCI-Schnittstelle, als BMEcat-Katalog oder an Marktplätze aus — ein Datenbestand, viele Abnahmekanäle, ohne Doppelpflege. apollon bringt dabei über 25 Jahre Erfahrung in Produktdaten- und Medienprozessen mit, gerade in Branchen, in denen OCI-Anbindungen zum Standard-Anforderungskatalog gehören. Details: OMN Product Information Management — oder sprich mit uns in einer unverbindlichen Demo darüber, wie Deine Katalogdaten punchout-fähig werden.
FAQ — Häufige Fragen zu OCI-Punchout
Wie richtet man einen OCI-Punchout ein?
Auf Kundenseite wird der Katalog im Beschaffungssystem als externer Webservice hinterlegt: Katalog-URL plus die vom Lieferanten dokumentierten Parameter (z. B. Zugangskennung, Sprache). Auf Lieferantenseite muss der Shop die OCI-Aufrufe entgegennehmen und den Warenkorb an die Rücksprungadresse übergeben. Der Abstimmungsaufwand liegt meist bei Zugangsdaten, Sortimentsfreischaltung und einem Testdurchlauf je Kunde.
Welche Daten überträgt die OCI-Schnittstelle?
Beim Absprung: Login- und Steuerparameter inklusive Rücksprungadresse. Bei der Rückgabe: je Warenkorbposition standardisierte Felder wie Beschreibung, Menge, Mengeneinheit, Preis, Währung, Artikelnummer und Warengruppe — plus optionale Felder etwa für Langtexte oder Klassifikationsreferenzen (OCI 5.0 ergänzt u. a. Felder für Artikel-Hierarchien).
Ist die OCI-Spezifikation kostenlos verfügbar?
Ja, die Spezifikation ist offen dokumentiert und frei zugänglich — das erklärt die breite Unterstützung über die SAP-Welt hinaus. Kosten entstehen nicht durch den Standard, sondern durch Implementierung und Betrieb der Anbindung auf Shop- und Systemseite.
Ist OCI-Punchout dasselbe wie eine EDI-Anbindung?
Nein. Punchout deckt die Katalog- und Warenkorbphase ab; EDI (bzw. cXML-Dokumente oder IDoc) übernimmt danach den Austausch von Bestellung, Auftragsbestätigung, Lieferschein und Rechnung. In vielen Kundenprojekten gehören beide zusammen: Punchout vorn, EDI hinten.