Wie funktioniert eigentlich OCI Punchout?

1. Der OCI Standard

Von vielen unserer Kunden kommt immer wieder die Frage nach OCI. Was ist eigentlich OCI und wie funktioniert dieser Standard in der Praxis? An dieser Stelle versuchen wir einmal eine einfache Erklärung zu geben.

Zur Einordnung ist zunächst wichtig zu verstehen, wo OCI (Open Catalog Interface) herkommt. OCI ist ein Standard zum Austausch von Katalogdatensätze zwischen ERP Systemen und beliebigen anderen Katalogen. Er wird eigentlich ausschließlich im B2B eCommerce und Procurement Umfeld genutzt.

Dieser Standard wurde ursprünglich von SAP entwickelt, um z.B. Bestellungen von Produkten, die über externe Webkatalogen recherchiert wurden, leicht in die ERP System Einkaufsprozesse integrieren zu können. Das Ziel ist, Webkataloge für die Verkaufspräsentation und Recherche, sowie SAP für die Kaufabwicklung zu nutzen. Die Kaufabwicklung findet nämlich nicht in der B2B Produktkataloglösung oder in der B2B e-Commerce Lösung statt, sondern die ausgewählten Produktdaten gelangen automatisch zur Bestellung in das SAP/ERP-System. Im SAP ist dann die SAP-konforme Bestellung und Verbuchung gewährleistet. Der Vorteil liegt somit darin flexible Produktpräsentationen mit standardisierten Einkaufsprozessen schnell und einfach zu verknüpfen. Der Vorgang des Zugriffs von SAP auf den externen Produktkatalog wird dabei auch mit dem Fachbegriff “Punchout” bezeichnet.

OCI - Typischer Prozessablauf

OCI – Typischer Prozessablauf

Im Ergebnis sind Webshopsysteme zu Recherche- und Produktauswahlprozessen direkt in SAP integriert, ohne dass SAP alle Produktdaten im Detail kennen muss oder gar Recherche und Vergleichsmöglichkeiten für Produkte im SAP Umfeld zu schaffen sind. Die Bestellungen selber verbleiben allerdings im ERP.

Mittlerweile haben viele ERP-System Hersteller die Vorteile dieses Standards erkannt und bietet ebenfalls OCI Unterstützung in Ihren ERP Systemen an.

2. Betriebsarten

Grundsätzlich sind zwei Betriebsart für OCI möglich:

  • Verkaufsorientierter Betrieb
    Beim Verkaufsorientierten Betrieb nutzt der Betreiber OCI um seinen Kunden Zugriff auf seine Produkte zu geben, wobei die Bestellungen über das ERP der Kunden kommt.
  • Einkaufsorientierte Betrieb
    Beim einkaufsorientierten Betrieb nutzen die internen Mitarbeiter die B2b e-Commerce Lösung, um auf Lieferantenkataloge zuzugreifen.

3. Bestellablauf

Um ein B2B eCommerce System an ein ERP System anzuschließen, sind eine Reihe an Schritte notwendig:

  • Zunächst muss das B2B e-Commerce System OCI unterstützen und die Möglichkeit bieten den Warenkorb standardkonform über eine hinterlegte Rücksprungadresse an das ERP System zu übertragen.
  • Anschließend ist das B2B e-Commerce System im ERP System bekannt zu machen. Hierfür muss z.B. die URL des Webshops, die Logindaten für den Webshop und die Rücksprung URL für die Übermittlung des OCI fähigen Warenkorbs in das ERP System hinterlegt werden.
  • Der ERP User greift über sein ERP System direkt per Link auf den Webkatalog zu und ist i.d.R. dort bereits direkt authentifiziert.
  • Nachdem der ERP User die gewünschten Produkte ausgewählt hat und in den Warenkorb springt, bekommt er dort i.d.R. einen Button angezeigt, der die Übernahme des Warenkorbs an das ERP System ermöglicht.
  • Durch Klick auf den Button wird der Warenkorb an die Rücksprungadresse kompatibel übertragen. Er steht ab dann im ERP System zur weiteren Bearbeitung zur Verfügung.
  • Dazu transformiert die B2B e-Commerce Lösung den Warenkorb in einen OCI-konformen Datenübertragungsstandard. Die Artikelnummer eines Produkt steht in diesem Standard z.B. im Feld NEW_ITEM_MATNR. Die Übertragung an das ERP System erfolgt per POST.

Alle weiteren Prozesse laufen nun ERP-konform im ERP System ab. Weitere Informationen können Sie bei Wikipedia finden.

4. Der OCI-fähige Warenkorb

4.1 OCI Feldübersicht

Wie oben bereits erwähnt, ist ein OCI-standardkonformer Warenkorb Voraussetzung für die Produktdatenübernahme vom Produktkatalog in das ERP.

Was das genau heißt und welche Informationen so übertragen werden können, wird nachfolgend vorgestellt.

Die Übersicht orientiert sich an den im OCI Standard 5.0 vorgesehenen Informationen, deren Feldlängen und Bedeutungen:

Field-name LengthDescription
NEW_ITEM-DESCRIPTION[n] 40Description of the item
NEW_ITEM-MATNR[n] 40SRM product number of the item
NEW_ITEM-QUANTITY[n] 15Item quantity (1.)
NEW_ITEM-UNIT[n] 3Quantity unit for item quantity (3.)
NEW_ITEM-PRICE[n] 15Price of an item per price unit (1.)
NEW_ITEM-CURRENCY[n] 5Item currency (3.)
NEW_ITEM-PRICEUNIT[n] 5Price unit of the item (if empty 1 is used)(2.)
NEW_ITEM-LEADTIME[n] 5Delivery time of the item in days (2.)
NEW_ITEM-LONGTEXT_n:132[] Long text for the item (4.)
NEW_ITEM-VENDOR[n] 10SRM vendor number (business partner) for the item
NEW_ITEM-VENDORMAT[n] 40Vendor product number for the item
NEW_ITEM-MANUFACTCODE[n] 10SRM manufacturer number of the item
NEW_ITEM-MANUFACTMAT[n] 40Item’s manufacturer part number
NEW_ITEM-MATGROUP[n] 10SRM material group for the item
NEW_ITEM-SERVICE[n] 1Flag: the item is a service.
NEW_ITEM-CONTRACT[n] 10SRM contract to which the item refers
NEW_ITEM-CONTRACT_ITEM[n] 5Item within the SRM contract
NEW_ITEM-EXT_QUOTE_ID[n] 35Number of an external bid for this item (as reference for a subsequent purchase order)
NEW_ITEM-EXT_QUOTE_ITEM[n] 10Item of external bid
NEW_ITEM-EXT_PRODUCT_ID[n] 40Unique database key for this item in the catalog
NEW_ITEM-ATTACHMENT[n] 255 URLof the attachment (the attachment must be accessible for downloading under this URL)
NEW_ITEMATTACHMENT_TITLE[n] 255Title of the attachment (if this is empty thefile name from the URL above is used)
NEW_ITEMATTACHMENT_PURPOSE[n]1Purpose of the attachment. C corresponds here to configuration.
NEW_ITEMEXT_SCHEMA_TYPE[n]10Name of a schema via which it was imported in the SRM Server
NEW_ITEMEXT_CATEGORY_ID[n]60Unique key for an external category from the schema above independent of the version of the schema
NEW_ITEM-EXT_CATEGORY[n] 40Unique key for an external category from the schema above dependent on the version of the schema
NEW_ITEM-SLD_SYS_NAME[n] 60Name of a system in the System Landscape Directory (SLD)

Die Anmerkungen in der obigen Tabelle bedeuten:

  1. 11 Ziffern vor und 3 Ziffern nach dem Dezimalpunkt. Bitte verwenden Sie KEINE Kommas als Trennzeichen für tausender Werte.
  2. In ganzen Zahlen.
  3. Müssen als ISO Code im ERP/SRM System hinterlegt sein.
  4. Das Feld NEW_ITEM-LONGTEXT_n:132[] ist eine Ausnahme bzgl. der Syntax. Da der Feldinhalt unbeschränkt gross ist, ist die Positionszuordnung über die “_n” Codierung auszudrücken.

Neben den Standardfeldern stehen auch die im folgenden aufgeführten, sogenannte kundenspezifische Felder für die freie Belegung zur Verfügung:

Field-name LengthDescription
NEW_ITEM-CUST_FIELD1[n] 10User-defined field
NEW_ITEM-CUST_FIELD2[n] 10User-defined field
NEW_ITEM-CUST_FIELD3[n] 10User-defined field
NEW_ITEM-CUST_FIELD4[n] 20User-defined field
NEW_ITEM-CUST_FIELD5[n] 50User-defined field

Sollten diese Felder nicht reichen, können weitere Felder mit der Benamung NEW_ITEM-<Eigenen Name> ergänzt werden. Für die Interpretation auf  der Zielsystemseite, sprich dem ERP, muß dann natürlich jeweils gesorgt werden.

Für die Rückgabe eines solchen Warenkorbs ist es ausreichend die oben aufgeführten Daten als unsichtbare HTML-Formularfelder in ein HTML-Formular auszugeben und als Aktion für das Formular den Aufruf der Rücksprungadresse (HOOK_URL) des ERP-Systems, sowie die Übertragung aller versteckten Datenfelder per POST vorzusehen. Natürlich können neben den versteckten Feldern auch für den Benutzer sichtbare Felder vorgesehen werden. Diese werden üblicherweise zwar auch an das ERP System übergeben, von diesem i.d.R aber ignoriert.

4.2 Die OCI HTML Kodierung

In HTML sieht ein solches Formular z.B. so aus:

<form action="@ViewBag.hook_url" method="post" target="_top"> 
<input type="hidden" name="~caller" value="CTLG" /> 

<-- Item 1 --> 
<input type="hidden" name="NEW_ITEM-DESCRIPTION[1]" value="Artikel 1"> 
<input type="hidden" name="NEW_ITEM-QUANTITY[1]" value="1"> 
<input type="hidden" name="NEW_ITEM-UNIT[1]" value="Stk."> 
<input type="hidden" name="NEW_ITEM-PRICE[1]" value="250"> 
<input type="hidden" name="NEW_ITEM-PRICEUNIT[1]" value="1"> 
<input type="hidden" name="NEW_ITEM-CURRENCY[1]" value="EUR"> 
<input type="hidden" name="NEW_ITEM-LEADTIME[1]" value="10"> 
<input type="hidden" name="NEW_ITEM-VENDORMAT[1]" value="4711"> 
<input type="hidden" name="NEW_ITEM-MANUFACTCODE[1]" value="UM1"> 
<input type="hidden" name="NEW_ITEM-EXT_QUOTE_ID[1]" value=""> 
<input type="hidden" name="NEW_ITEM-EXT_PRODUCT_ID[1]" value=""> 
<input type="hidden" name="NEW_ITEM-EXT_SCHEMA_TYPE[1]" value="UNSPSC"> 
<input type="hidden" name="NEW_ITEM-SERVICE[1]" value="X" /> 
<input type="hidden" name="NEW_ITEM-EXT_CATEGORY_ID[1]" value="43100100"> 
<input type="hidden" name="NEW_ITEM-MATGROUP[1]" value="43100103"> 
<input type="hidden" name="NEW_ITEM-PARENT_ID[1]" value=""> 
<input type="hidden" name="NEW_ITEM-ITEM_TYPE[1]" value=""> 

<-- Item 2 --> 
<input type="hidden" name="NEW_ITEM-DESCRIPTION[2]" value="Artikel 2"> 
<input type="hidden" name="NEW_ITEM-QUANTITY[2]" value="1"> 
<input type="hidden" name="NEW_ITEM-UNIT[2]" value="Stk."> 
<input type="hidden" name="NEW_ITEM-PRICE[2]" value="250"> 
<input type="hidden" name="NEW_ITEM-PRICEUNIT[2]" value="1"> 
<input type="hidden" name="NEW_ITEM-CURRENCY[2]" value="EUR"> 
<input type="hidden" name="NEW_ITEM-LEADTIME[2]" value="10">
<input type="hidden" name="NEW_ITEM-VENDORMAT[2]" value="4712"> 
<input type="hidden" name="NEW_ITEM-MANUFACTCODE[2]" value="UM2"> 
<input type="hidden" name="NEW_ITEM-EXT_QUOTE_ID[2]" value=""> 
<input type="hidden" name="NEW_ITEM-EXT_PRODUCT_ID[2]" value=""> 
<input type="hidden" name="NEW_ITEM-EXT_SCHEMA_TYPE[2]" value="UNSPSC"> 
<input type="hidden" name="NEW_ITEM-EXT_CATEGORY_ID[2]" value="43100100"> 
<input type="hidden" name="NEW_ITEM-SERVICE[2]" value="X" /> 
<input type="hidden" name="NEW_ITEM-MATGROUP[2]" value="43100103"> 
<input type="hidden" name="NEW_ITEM-PARENT_ID[2]" value=""> 
<input type="hidden" name="NEW_ITEM-ITEM_TYPE[2]" value=""> 

<center> 
<input type="submit" value="Per OCI übertragen" id="submit1" name="submit1"> <br> 
</center> 
</form>

5. Die OCI Produktkatalogeinbindung am Beispiel SAP SRM Server

Wie bereits oben erwähnt, wird OCI mittlerweile von sehr vielen ERP Herstellern unterstützt. Um ein besseres Verständnis über die Abläufe vermitteln zu können, zeigen wir im Folgenden auch die Konfigurationsseite beim ERP. Wir haben uns hier für das SAP SRM Portal (SRM = Supplier Relationship Management) entscheiden. Vergleichsweise wird die Konfiguration des externen Produktkatalogs aber auch in allen anderen ERP Systemen ablaufen.

5.1 Aufruf Produktkatalog

Als erster Schritt muss dem ERP System mitgeteilt werden, das ein OCI-fähiger Produktkatalog existiert und wie das ERP System darauf zugreifen kann. Hierfür sind folgende Informationen notwendig:

  • URL des Produktkatalogs
  • Sonstige Aufrufparameter, wie z.B.:
    • Login
    • Passwort
    • Sprache
    • Codierung
  • Rücksprungadresse (HOOK_URL)

Die Aufrufparameter können dabei ziemlich flexibel angepasst werden. So ist es z.B. nicht unüblich, über die Aufrufparameter festzulegen, mit welchen Informationen die freien OCI Feldern belegt werden sollen.

Grundsätzlich können als Parameter sowohl fixe Werte, als auch SAP Systemvariablen verwendet werden.

Die folgenden Standardparameter stehen in OCI ebenfalls zur Verfügung:

  • OCI_VERSION – Die erwartet OCI Version, z.B. 4.0
  • secureMode (true/false) – Legt fest, ob die Übertragung via https erfolgen soll, oder nicht
  • BYPASS_OUTB_HANDLER – Setzt den SRM Server ab Version 7 voraus. Hierüber kann die Verwendung des Outbound Handler gesteuert werden. Dieser platziert den Produktkatalog als iFrame in eine Seite, die z.B. immer eine Rücksprungadresse zum SRM vorsieht
  • BYPASS_INB_HANDLER – Ähnlich wie der Outbound Handler, sorgt der Inbound Handler dafür, dass z.B. Codierungen der Rückgabewerte aus dem externen Produktkatalog korrekt übernommen werden.
Ariba OCI Systemkonfiguration

Ariba OCI Systemkonfiguration

Eine beispielhafte Konfiguration für ein Aruba System als externer Produktkatalog ist im obigen Screenshot dokumentiert.

5.2 OCI Mapping

Nachdem der Aufruf des Produktkataloges definiert ist, muss die OCI Rückgabe noch gemapped werden, damit SAP auch versteht, was im einzelnen die Daten bedeuten.

OCI Mapping

OCI Mapping

Wie im obigen Screenshot erkennbar ist, wird dazu im SRM Portal hinterlegt, welches OCI Feld welchen Inhalt enthält. Nach diesem Konfigurationsschritt ist die Einbindung des OCI Produktkataloges im Prinzip abgeschlossen und kann getestet/verwendet werden.

6. Sonstige OCI Funktionen

6.1 Produktdetailinformationen abrufen

Über den Funktionsaufrufparameter DETAIL, der als weiteren Parameter die PRODUCTID benötigt, können jederzeit auch gezielt Produktdetailinformationen aus dem externen Produktkatalog abgefragt werden. Der Returnwert erfolgt im OCI Format. Damit ist es im SRM Portal möglich auch mehr Informationen für den Benutzer anzuzeigen, als über den OCI Standard ursprünglich übertragen wurden.

6.2 Massendatenfunktionen

Der OCI Standard ab Version 5.0 sieht, neben der Übertragung von Warenkörben, auch Funktionen für die Stammdatensynchronisation und die Suche nach Produkten vor. Das Rückgabeformat ist in diesen Fällen aus Effektivitätsgründen immer das JSON Format. Im Folgenden ein kurzer Überblick über die im OCI Standard unterstützten Massendatenfunktionen:

  • VALIDATE – Aktualisiert Produktinformationen, wie z.B. den Preis
  • SOURCING – Sucht passende Produkte auf der Basis eines Suchbegriffs
  • BACKGROUND_SEARCH – Durchsucht alle im SRM Portal hinterlegten OCI Produktkataloge nach einem Suchbegriff
  • DOWNLOADJSON – Stellt eine definierte und paginierte Produktdatenmenge im JSON Format zur Verfügung

Somit könnte man über den OCI Standard auch auf den Punchout Vorgang verzichten und stattdessen den externen Produktkatalog nur als Datenlieferant einbinden. In der Praxis wird dieses Verfahren bei unseren Kunden aber eher seltener verwendet.

7. Fazit

Da der Ablauf gut standardisiert ist, ergibt sich in der Praxis bei der Einrichtung der Warenkorbübergabe wenig Anpassungsbedarf.

OCI wird zurzeit häufig bei der Integration von Konzernkunden oder von Konzernen eingesetzt. Bei mittelständischen Kunden ist diese Technik zurzeit aber noch weniger verbreitet.

Die Vorteile, die sich durch die Trennung von Produktrecherche und -präsentation sowie dem Bestellprozess ergeben, liegen aber auf der Hand.

Nähere Details über OCI sind auf den SAP Hilfeseiten verfügbar.

Unit M hilft Ihnen gerne eine OCI-fähige Lösung aufzubauen. Sprechen Sie uns bei Interesse doch einfach unverbindlich an.

 

ACHTUNG!
Seit 2019 stellen wir unser OpenSource OCI Modul für OXID eShop 4.x – 6.x kostenlos für Interessenten auf Anfrage zur Verfügung. Wenn Sie Interesse an den OCI Modul haben, nehmen Sie bitte Kontakt mit uns auf.

Module für OroCommerce und Shopware sind in Arbeit.

Interessiert an einem eintägigen Workshop?

Sie möchten OCI implementieren und benötigen Orientierungshilfe? Dann buchen Sie doch einfach unseren eintägigen OCI-Workshop.

Wir erklären Ihnen praxisorientiert, was man bei der OCI Umsetzung beachten muss und zeigen Ihnen genau, wie der OCI Standard funktioniert. Profitieren Sie von unserem langjährigen Knowhow in diesem Bereich.

Unser Agendavorschlag für den Workshop wäre:

1. OCI Prozess-ablauf und -Integration
Ziele:

  • Gründe für die Entwicklung von OCI erklären
  • Die Grenzen von OCI aufzeigen
  • Verständnis für den Punchout Vorgang vermitteln
  • Überblick über den technischen Prozessablauf einer OCI Bestellung vermitteln

2. Herausforderungen bei Ihrer OCI Umsetzung
Ziele:

  • Sensibilisierung für die strategischen Fragestellungen in Ihrer OCI Implementierung leisten

3. OCI Detailbetrachtung des technischen Ablaufs
Ziele dieses Punktes:

  • Vermitteln was er OCI Standard vorgibt und regelt
  • Erklärung, welche Informationen wie übertragen werden sollten
  • Beispiele für OCI Umsetzungen namhafter Unternehmen erläutern
  • Variabilität von OCI an Hand von Best Practice Beispielen vermitteln

4. Tools und Entwicklungshilfen

Ziele:

  • Tools für die Implementierung und das Testen Ihrer OCI Umsetzung vorstellen

5. Erarbeitung der Eckpunkte für die Umsetzung von OCI in Ihrem Projekt
Ziele:

  • Erarbeitung von konkreten Lösungsansätzen für die OCI Umsetzung in Ihrem Projekt

Interessiert? Wir freuen uns auf Ihre Anfrage.