OCI 5.0 Punchout: Wie Dein Katalog ins Einkaufssystem Deiner Kunden kommt

"Wir stellen unsere Beschaffung auf ein E-Procurement-System um. Bitte stellen Sie uns Ihren Katalog als OCI-Punchout bereit." Mit so einer Mail vom Einkauf eines Großkunden fängt das Thema meistens an. Man liest den Satz zweimal, sucht danach und landet vor allem in SAP-Dokumentation, die für eine ganz andere Systemwelt geschrieben ist. Dabei steckt hinter der Anforderung ein überschaubarer Mechanismus, und sie lässt sich auch dann erfüllen, wenn im Haus keine SAP-Landschaft läuft, sondern eine Sage 100. Wir haben solche Anbindungen umgesetzt und beschreiben hier, wie das Verfahren funktioniert und wo in den Projekten die Zeit tatsächlich draufgeht.

Was hinter OCI steckt

OCI steht für Open Catalog Interface. Entwickelt hat den Standard SAP für die eigenen Beschaffungssysteme, inzwischen sprechen ihn praktisch alle verbreiteten E-Procurement-Plattformen, etwa Onventis, Jaggaer oder Unite. Die aktuelle Version 5.0 stammt aus dem Jahr 2013. Das klingt erst mal alt, heißt in der Praxis aber vor allem: Der Standard ist stabil, da ändert sich nichts mehr unter der Hand.

Die Grundidee: Statt dass der Lieferant seinen Katalog als Datei ins Einkaufssystem des Kunden hochlädt und bei jeder Preisänderung eine neue Datei schickt, bleibt der Katalog beim Lieferanten. Der Einkäufer springt aus seinem System in den Webshop des Lieferanten, sucht dort aus und nimmt den Warenkorb mit zurück. Dieses Rausspringen und Zurückkommen hat dem Verfahren seinen Namen gegeben: Punchout.

So läuft ein Punchout ab

Der Ablauf besteht aus vier Schritten, und wenn man ihn einmal gesehen hat, ist die Magie raus.

1. Der Absprung ins Katalogsystem

Der Einkäufer klickt in seinem Einkaufssystem auf den hinterlegten Katalog. Das System ruft die vereinbarte URL des Lieferanten-Shops auf und übergibt per HTTP-POST eine Handvoll Parameter: Zugangsdaten, die erwartete OCI-Version und vor allem die HOOK_URL, also die Rücksprungadresse, an die der Warenkorb später zurückgeschickt wird. Der Shop prüft die Zugangsdaten und startet eine Session. Der Einkäufer bekommt davon nichts mit, er landet ohne separates Login direkt im Katalog.

2. Einkaufen wie im Webshop

Jetzt passiert das, was jeder aus dem Onlinehandel kennt: Suchen, vergleichen, in den Warenkorb legen. Der Unterschied liegt unter der Haube. Weil der Shop weiß, welcher Kunde da eingesprungen ist, zeigt er dessen Konditionen, also verhandelte Preise, freigegebenes Sortiment und kundenspezifische Artikelnummern.

3. Der Rücksprung mit dem Warenkorb

Statt auf "Kaufen" klickt der Einkäufer auf "Warenkorb übertragen". Der Shop baut daraus ein HTML-Formular mit standardisierten Feldern und schickt es per POST an die HOOK_URL. Jede Position wird in nummerierte Felder zerlegt, unter anderem:

• NEW_ITEM-DESCRIPTION[n]: Die Artikelbezeichnung
• NEW_ITEM-VENDORMAT[n]: Die Artikelnummer des Lieferanten
• NEW_ITEM-QUANTITY[n] und NEW_ITEM-UNIT[n]: Menge und Mengeneinheit
• NEW_ITEM-PRICE[n], NEW_ITEM-PRICEUNIT[n] und NEW_ITEM-CURRENCY[n]: Preis, Preiseinheit und Währung
• NEW_ITEM-LEADTIME[n]: Die Lieferzeit in Tagen
• NEW_ITEM-CUST_FIELD1 bis CUST_FIELD5: Freie Felder für alles, was der Standard nicht abdeckt

4. Weiterverarbeitung im Einkaufssystem

Aus dem übernommenen Warenkorb macht das Einkaufssystem eine Bedarfsanforderung oder Bestellung, die den normalen internen Weg geht: Freigabe, Budgetprüfung, Genehmigungsworkflow. An dieser Stelle sitzt ein Missverständnis, das uns immer wieder begegnet: OCI überträgt keine Bestellung. Es überträgt einen Warenkorb ins Einkaufssystem des Kunden, mehr nicht. Die Bestellung selbst kommt erst nach der internen Freigabe beim Lieferanten an, per E-Mail, als PDF oder über EDI. Diesen zweiten Kanal muss man von Anfang an mitplanen, sonst wartet die eigene Auftragserfassung auf Aufträge, die auf dem OCI-Weg nie kommen werden.

Was in Version 5.0 dazugekommen ist

Am Kernablauf hat sich seit den frühen Versionen wenig geändert. Version 5.0 ergänzt Funktionen, mit denen das Einkaufssystem den Katalog auch maschinell abfragen kann, ohne dass ein Mensch durch den Shop klickt. Gesteuert wird das über den Parameter FUNCTION im Aufruf:

• DETAIL: Ruft zu einem bekannten Artikel die aktuelle Detailseite im Katalog auf, etwa aus einer alten Bestellung heraus.
• VALIDATE: Prüft im Hintergrund, ob ein Artikel noch bestellbar ist und was er aktuell kostet.
• SOURCING: Sucht zu einem Bedarf passende Bezugsquellen im Katalog.
• BACKGROUND_SEARCH: Erlaubt dem Einkaufssystem eine katalogübergreifende Suche, ohne dass der Anwender jeden Katalog einzeln öffnet.
• Massendaten als JSON: Katalogdaten lassen sich strukturiert herunterladen, damit das Einkaufssystem sie für die eigene Suche indizieren kann.

In der Praxis relativiert sich das. Viele Einkaufssysteme und Kataloge nutzen bis heute nur den Punchout selbst plus DETAIL, und etliche Anbindungen laufen weiter nach OCI 4.0. Wer eine Schnittstelle neu baut, sollte die 5.0-Funktionen anbieten können, darf aber nicht überrascht sein, wenn die Gegenseite davon nichts konfiguriert. Im Ariba-Umfeld gibt es mit cXML-Punchout übrigens einen zweiten Standard nach demselben Prinzip, XML-Nachrichten statt Formularfelder. Eine sauber gebaute OCI-Anbindung ist dafür die halbe Miete.

Was hat das mit Sage 100 zu tun?

Sage 100 bringt von Haus aus keinen OCI-Punchout mit. Trotzdem ist die Warenwirtschaft die richtige Grundlage dafür, denn alles, was der Katalog braucht, liegt dort schon gepflegt vor: Artikel, Varianten, kundenindividuelle Preise, Rabatte, Bestände. Genau da setzen wir an. Wichtig ist nur, die beiden Richtungen auseinanderzuhalten, denn "OCI mit Sage 100" kann zwei sehr verschiedene Projekte bedeuten.

Als Lieferant: Dein Sortiment im Einkaufssystem Deiner Kunden

Das ist der Fall aus der Mail vom Anfang. Dein Kunde, oft ein Konzern oder ein öffentlicher Auftraggeber, beschafft über ein E-Procurement-System und erwartet Deinen Katalog als Punchout. Wir stellen dafür einen Webkatalog bereit, der seine Daten direkt aus Deiner Sage 100 bezieht. Artikelstamm, kundenindividuelle Preislisten und Verfügbarkeiten kommen live aus der Warenwirtschaft, ohne doppelte Datenpflege. Der Warenkorb geht OCI-konform zurück, und die später eintreffende Bestellung landet als Auftrag wieder in Deiner Sage 100. Unterm Strich ist das ein zusätzlicher Vertriebskanal, und zwar der, den Großkunden zunehmend zur Bedingung machen.

Als Einkäufer: Lieferantenkataloge in Deinem Einkauf

Die Gegenrichtung gibt es auch. Wenn Dein Team regelmäßig C-Teile, Bürobedarf oder Werkzeug bei Lieferanten mit OCI-fähigen Shops beschafft, kann es aus dem Einkaufsprozess heraus in deren Kataloge springen. Der zurückgegebene Warenkorb wird zur Bestellung in der Sage 100, mit sauber zugeordneten Artikeln, Mengeneinheiten und Preisen statt Copy-and-paste aus dem Browser.

Woran Punchout-Projekte in der Praxis hängen

Die OCI-Felder zu befüllen ist der einfache Teil. Die Erfahrung aus unseren Projekten: Die Zeit steckt in den Details dazwischen.

• Mengeneinheiten. Einkaufssysteme erwarten in NEW_ITEM-UNIT meist ISO-Codes, also etwa PCE für Stück. In der Sage 100 heißt die Einheit aber "Stk" oder "Stück". Ohne sauberes Mapping in beide Richtungen scheitert die Übernahme, oder schlimmer, es entstehen stillschweigend falsche Bestellmengen. Die gängigen Codes haben wir in einem kleinen Nachschlagetool für ISO-Mengeneinheiten gesammelt.
• Preise und Preiseinheiten. Übertragen werden Nettopreise. Wer Preise je 100 Stück führt, muss die Preiseinheit korrekt mitgeben, ein übersehenes PRICEUNIT verschiebt den Preis mal eben um den Faktor 100.
• Feldlängen und Encoding. DESCRIPTION fasst 40 Zeichen, längere Texte gehören in den Langtext. Und kaputte Umlaute fallen grundsätzlich erst beim Test mit dem echten Einkaufssystem auf, nie vorher.
• Testen ohne Gegenseite. Das Einkaufssystem des Kunden steht meist erst spät zur Verfügung, und jeder Testlauf braucht dort einen Ansprechpartner. Für die ersten Runden haben wir deshalb einen kostenlosen OCI-Punchout-Tester gebaut: Er simuliert das Einkaufssystem, nimmt den Warenkorb an einer Test-HOOK_URL entgegen und prüft die Felder auf genau die Punkte aus dieser Liste.
• Jeder Kunde konfiguriert anders. Der Standard lässt Spielraum, und jedes Einkaufssystem nutzt ihn. Welche Felder Pflicht sind, wie die CUST_FIELD-Felder belegt werden sollen, welche OCI-Version erwartet wird: Verbindlich klärt sich das erst im gemeinsamen Test mit dem Einkauf des Kunden. Diesen Termin sollte man früh einplanen, er entscheidet über den Zeitplan.

Fazit

OCI-Punchout ist ein alter, unaufgeregter Standard, und genau das macht ihn angenehm: Absprung in den Katalog, Einkaufen zu den eigenen Konditionen, Warenkorb zurück. Der Aufwand in Projekten steckt selten in der Schnittstelle selbst, sondern in Mengeneinheiten, Preislogik und der Abstimmung mit dem Einkaufssystem der Gegenseite.

Wenn bei Dir gerade so eine Anfrage auf dem Tisch liegt oder Du Lieferantenkataloge in Deinen Einkauf holen willst: Wir haben diese Projekte mit der Sage 100 umgesetzt und wissen, wo die Zeit draufgeht. Meld Dich einfach.