OCI-Schnittstelle im Fachgroßhandel: Was IT klären muss

Ein Industriekunde möchte künftig aus seinem Beschaffungssystem direkt in den Großhandelsshop wechseln. Dort soll sein freigegebenes Sortiment mit den vereinbarten Konditionen erscheinen. Nach der Auswahl müssen Artikel, Mengen und Preise zurück in seinen Warenkorb. Für die IT-Leitung klingt die Anfrage zunächst nach einer weiteren Shop-Schnittstelle. Tatsächlich verbindet sie Kundensystem, Webshop, Preislogik und Produktstamm in einem gemeinsamen Ablauf.

Kurzantwort: Eine OCI-Schnittstelle verbindet das Beschaffungs- oder ERP-System eines Kunden mit dem Katalog eines Lieferanten. Der Einkäufer startet im eigenen System, wählt Artikel im Großhandelsshop und übergibt den Warenkorb zurück. Die Bestellung wird dadurch noch nicht automatisch versendet. Vor einem Pilot müssen IT und Fachbereich insbesondere Anmeldung, Kundensortiment, Artikelreferenzen, Einheiten, Preise, Rückgabefelder, Freigaben und Fehlerbehandlung festlegen.

Was ist eine OCI-Schnittstelle im Fachgroßhandel?

OCI steht für Open Catalog Interface. Die Schnittstelle bindet einen externen Produktkatalog in eine Einkaufsanwendung ein. Der Nutzer verlässt seinen gewohnten Beschaffungsprozess nicht dauerhaft. Er öffnet aus diesem System den freigegebenen Shop, stellt dort einen Warenkorb zusammen und gibt die ausgewählten Positionen an das aufrufende System zurück. Dieser geführte Wechsel wird häufig als Punchout bezeichnet.

Die offizielle SAP-Dokumentation zu Katalogen im Einkauf beschreibt OCI als Weg, interne oder externe Produktkataloge in Einkaufsanwendungen einzubinden. Der Katalog muss dazu die vereinbarte OCI-Struktur unterstützen und die benötigten Daten im erwarteten Format bereitstellen.

Für den Fachgroßhandel ist die Perspektive entscheidend: Die OCI-Anbindung sitzt auf der Lieferantenseite am eigenen Katalog oder Webshop. Das führende Einkaufssystem liegt beim Kunden. Beide Seiten müssen deshalb gemeinsam festlegen, was beim Aufruf übergeben wird und welche Felder mit dem Warenkorb zurückkommen.

Wie läuft ein OCI-Punchout im Tagesgeschäft ab?

Ein belastbarer OCI-Ablauf besteht aus sechs Schritten:

1. Der Einkäufer startet im Beschaffungs- oder ERP-System seines Unternehmens.
2. Das System ruft den freigegebenen Großhandelsshop mit den vereinbarten Parametern auf.
3. Der Shop erkennt Kunde, Benutzerkontext und gegebenenfalls Sortiment oder Konditionsgruppe.
4. Der Einkäufer sucht technische Artikel, prüft Varianten und legt Positionen in den Warenkorb.
5. Der Shop gibt die ausgewählten Positionen über die vereinbarte Rückgabeadresse an das Kundensystem zurück.
6. Im Kundensystem folgen Kontierung, Budgetprüfung, Freigabe und erst danach die verbindliche Bestellung.

Die öffentlich zugängliche SAP-Spezifikation für OCI 5.0 beschreibt den Katalogaufruf und die Rückgabe ausgewählter Produktdaten an die Einkaufsanwendung. Die Spezifikation stammt vom 4. Oktober 2012. Welche Version und welche Funktionen heute tatsächlich unterstützt werden, muss deshalb für jedes beteiligte System ausdrücklich geprüft werden.

Die Trennung zwischen Warenkorb und Bestellung verhindert ein häufiges Missverständnis. OCI übergibt die Auswahl an den Einkauf des Kunden. Ob daraus ein genehmigter Bestellauftrag wird und über welchen Kanal er beim Fachgroßhandel eingeht, entscheidet der nachgelagerte Prozess. Die Bestellung kann später beispielsweise per EDI, API, E-Mail oder über eine Plattform eintreffen.

Welche Daten muss die OCI-Schnittstelle zurückgeben?

Ein Warenkorb ist nur dann nutzbar, wenn die Positionen im Kundensystem eindeutig weiterverarbeitet werden können. Die SAP-Spezifikation nennt unter anderem Felder für Beschreibung, Menge, Mengeneinheit, Preis, Währung, Lieferantenartikelnummer, Herstellerartikelnummer und eine eindeutige Produktkennung des Katalogs. Welche Felder verpflichtend sind, hängt teilweise von den verwendeten Angaben und der Partnervereinbarung ab.

Für einen Pilot im technischen Fachgroßhandel sollten mindestens diese Datenbereiche geklärt werden:

| Datenbereich | Praktische Prüffrage | Typischer Klärfall | |---|---|---| | Artikelidentität | Welche Nummer erkennt das Kundensystem eindeutig? | Eigene Artikelnummer, Herstellerartikelnummer und Kundennummer werden verwechselt | | Beschreibung | Reicht der Text für Auswahl und Freigabe? | Dimension, Ausführung oder Norm fehlt im übergebenen Kurztext | | Menge und Einheit | Stimmen Bestellmenge, Preisbezugsmenge und Einheit zusammen? | Stück, Pack, Meter und Gebinde werden unterschiedlich interpretiert | | Preis und Währung | Welcher Kundenpreis gilt zu welchem Zeitpunkt? | Shoppreis, Rahmenvertragskondition und kundenseitiger Katalogpreis weichen ab | | Klassifikation und Warengruppe | Welche Zuordnung braucht der Einkauf des Kunden? | Lieferantenkategorie passt nicht zur kundenseitigen Warengruppe | | Lieferzeit oder Verfügbarkeit | Welche Aussage ist belastbar und wie lange gilt sie? | Anzeige im Shop wird nach der Warenkorbrückgabe nicht erneut geprüft | | Zusatzfelder | Welche Kontierung oder Projektreferenz muss mitgegeben werden? | Ein kundenspezifisches Pflichtfeld fehlt in der Standardbelegung |

Bei breiten Sortimenten genügt es nicht, nur einen problemlosen Standardartikel zu testen. Kabelzuschnitte, konfigurierbare Baugruppen, Ersatzartikel, kundenspezifische Preise und unterschiedliche Verpackungseinheiten gehören als bewusste Prüffälle in die Abnahme.

Was unterscheidet OCI von EDI, cXML und BMEcat?

Die Begriffe stehen im Tagesgeschäft häufig nebeneinander, lösen aber nicht dieselbe Aufgabe.

OCI beschreibt den Aufruf eines Katalogs und die Rückgabe eines Warenkorbs. Der Nutzer wählt im Shop des Fachgroßhändlers aus, die Freigabe bleibt im Kundensystem.

EDI überträgt strukturierte Geschäftsnachrichten zwischen Partnern. Eine Bestellung, Bestellantwort, ein Lieferavis oder eine Rechnung folgt jeweils einem definierten Nachrichtentyp. Die EDI- und E-Procurement-Seite ordnet diese Wege und ihre jeweiligen Prüfungen ein.

cXML kann ebenfalls Punchout- und weitere Beschaffungsprozesse abbilden. Ob OCI oder cXML passt, richtet sich nicht nach persönlicher Vorliebe, sondern nach dem Einkaufssystem des Kunden, der unterstützten Version und dem vereinbarten Prozess.

BMEcat überträgt Katalog- und Produktdaten als Datei oder Datenpaket. Ein Punchout greift dagegen auf den laufenden Lieferantenkatalog zu. Der Beitrag zu BMEcat, ETIM, DATANORM und ECLASS erklärt die Abgrenzung zwischen Austauschformat und Klassifikation.

Ein Fachgroßhändler kann mehrere dieser Wege parallel benötigen. OCI ersetzt weder die Produktdatenpflege noch die verbindliche Bestellnachricht. Es ergänzt die Systemlandschaft um einen kontrollierten Katalogzugriff.

Welche Voraussetzungen müssen Shop, ERP und Stammdaten erfüllen?

Der Webshop ist die sichtbare Oberfläche. Die eigentliche Arbeit liegt jedoch in den dahinterliegenden Zuordnungen. Vor der technischen Umsetzung sollte die IT fünf Voraussetzungen prüfen.

1. Kundensortiment und Konditionen sind eindeutig

Der aufgerufene Benutzer darf nur die vorgesehenen Artikel, Preise und Funktionen sehen. Wenn mehrere Kundennummern, Gesellschaften oder Lieferorte existieren, braucht der Aufruf eine eindeutige Zuordnung. Eine pauschale Anmeldung für alle Nutzer erschwert Rechte, Support und Protokollierung.

2. Artikelreferenzen bleiben über den Prozess stabil

Die Produktkennung aus dem Shop muss später wieder zur Bestellung passen. Ein Mapping darf deshalb Lieferanten-, Hersteller- und Kundenartikelnummern nicht vermischen. Änderungen am Artikelstamm brauchen eine Regel für Ersatzartikel, ausgelaufene Positionen und bereits gespeicherte Warenkörbe.

3. Einheiten und Preisbezüge sind abgestimmt

Im technischen Fachgroßhandel unterscheiden sich Verkaufseinheit, Verpackungseinheit und Preisbezugsmenge häufig. Eine fehlerfreie Übertragung von „10“ reicht nicht, wenn die eine Seite zehn Stück und die andere zehn Pack versteht. Dasselbe gilt für Preise je Stück, je hundert Stück oder je Meter.

4. Rückgabe und Folgeprozess sind getrennt

Die Rückgabeadresse nimmt den Warenkorb entgegen. Sie darf nicht mit einem produktiven Bestelleingang verwechselt werden. Im Kundensystem müssen Genehmigung und Versand klar erkennbar nachgelagert bleiben. Auf Seiten des Fachgroßhändlers braucht es anschließend eine eindeutige Zuordnung, wenn die verbindliche Bestellung eintrifft.

5. Betrieb und Support sind festgelegt

Die ERP-Integration sollte Aufruf, Warenkorbrückgabe und spätere Bestellung nachvollziehbar verbinden, ohne einen zweiten führenden Artikel- oder Preisbestand aufzubauen. Für Störungen braucht es Monitoring, verantwortliche Ansprechpartner, einen Rückfallweg und eine dokumentierte Abgrenzung zwischen Shopfehler, Mappingfehler und Kundensystem.

Welche Rechte und Sicherheitsfragen gehören in den Pilot?

Katalogaufrufe können Anmeldeinformationen, Kundenzuordnungen und Preise berühren. Die OCI-5.0-Spezifikation beschreibt deshalb ein Verfahren namens Secure OCI. Dabei sollen vertrauliche Informationen nicht über den Browser übertragen werden. Für die konkrete Implementierung ist zu prüfen, ob und wie die beteiligten Systeme diese Funktion oder ein anderes abgesichertes Verfahren unterstützen.

Unabhängig von der Variante sollte die IT vor dem Produktivbetrieb festhalten:

• welche Parameter vom Kundensystem an den Shop gesendet werden;
• wie Benutzer, Gesellschaft, Kundennummer und Sortiment zugeordnet werden;
• wie lange Sitzungen gelten und wie Abbruch oder erneuter Aufruf behandelt werden;
• welche Daten im Browser, im Backend und in Protokollen erscheinen;
• wer Konfigurationen und kundenspezifische Felder ändern darf;
• wie Test- und Produktivzugänge getrennt werden;
• wie fehlerhafte oder manipulierte Warenkorbdaten zurückgewiesen werden.

Die IT-Leitung sollte außerdem festlegen, welche Informationen für Support und Nachweis benötigt werden. Ein Protokoll braucht genug Kontext, um einen Fehler zu klären. Zugangsdaten und unnötige personenbezogene Angaben gehören nicht unkontrolliert in Logdateien. Die IT-Perspektive im Fachgroßhandel bündelt weitere Fragen zu Berechtigungen, Hosting, Wartung und Rückfallwegen.

Wie sieht ein belastbarer OCI-Pilot aus?

Ein guter Pilot beginnt mit einem Kunden, einem Beschaffungssystem und einem klar abgegrenzten Sortiment. IT, Vertrieb und der Ansprechpartner des Kunden legen vorab fest, welche Version, Felder und Geschäftsfälle geprüft werden. Reale Konditionen dürfen nur in einer dafür freigegebenen Testumgebung verwendet werden.

Die Testfälle sollten nicht nur den Idealweg abdecken:

1. Der berechtigte Nutzer öffnet den richtigen Katalog mit dem vorgesehenen Sortiment.
2. Standardartikel kommen mit korrekter Nummer, Menge, Einheit, Preis und Währung zurück.
3. Kundenspezifische Preise und Preisbezugsmenge bleiben nachvollziehbar.
4. Sonderzeichen, lange Beschreibungen und mehrere Positionen werden vollständig übertragen.
5. Ein abgelaufener oder abgebrochener Aufruf erzeugt keine Bestellung.
6. Ein unbekannter Artikel oder ein unzulässiges Feld wird sichtbar abgewiesen.
7. Die spätere Bestellung lässt sich dem richtigen Kunden und Vorgang zuordnen.
8. Störung, Wiederanlauf und Supportweg werden praktisch getestet.

Messgrößen für die Pilotentscheidung sind die Zahl vollständig übertragener Warenkörbe, fachliche Mappingfehler, technische Abbrüche, manuelle Korrekturen, Klärzeit je Fehler und der Supportaufwand pro angebundenem Kunden. Erst die eigenen Ausgangswerte zeigen, ob die OCI-Schnittstelle das Tagesgeschäft wirklich entlastet.

Wann lohnt sich die OCI-Schnittstelle für den Fachgroßhandel?

OCI ist besonders prüfenswert, wenn ein wichtiger B2B-Kunde aus seinem eigenen Einkaufssystem bestellen muss, häufig auf aktuelle Sortimente und Konditionen zugreift und die manuelle Übernahme von Warenkörben einen wiederkehrenden Engpass erzeugt. Weniger geeignet ist ein sofortiger breiter Rollout, solange Artikelreferenzen, Einheiten oder kundenspezifische Preise nicht belastbar zugeordnet sind.

Der nächste Schritt ist deshalb kein pauschaler Technologieentscheid. Nehmen Sie eine echte Kundenanforderung, einen typischen Warenkorb und die beteiligten Systeme. Prüfen Sie gemeinsam, welche Daten beim Aufruf und bei der Rückgabe tatsächlich fließen müssen. Wenn Sie diesen Ablauf mit Ihrer IT und dem Kunden abgrenzen möchten, kann ein sachliches Gespräch über OCI, Mapping und Pilotbetrieb den notwendigen Umfang klären.

Fynn Governatori

Geschäftsführer und Berater für den technischen Fachgroßhandel