Was ist PunchOut? Der vollständige Ratgeber für Lieferanten

So funktioniert PunchOut

PunchOut verbindet zwei Systeme, die nicht dafür gebaut wurden, miteinander zu sprechen: das Beschaffungssystem Ihres Kunden und Ihren Onlineshop. Große Organisationen kaufen über eProcurement-Systeme wie SAP Ariba, Coupa oder SAP S/4HANA ein, in denen jeder Einkauf Freigaberegeln folgt und dem richtigen Budget zugeordnet wird. Statt Ihre Produkte in dieses System zu kopieren, verlangen sie von Ihnen einen PunchOut-Katalog: einen Link, der Ihren Shop direkt aus ihrem Beschaffungssystem öffnet.

Eine PunchOut-Session hat vier Schritte:

1. Setup. Ein Bedarfsträger klickt in seinem Beschaffungssystem auf Ihren Katalog. Das System sendet an Ihre Seite eine Setup-Anfrage mit Zugangsdaten und einer Rücksprungadresse.
2. Einkauf. Ihr Shop öffnet sich in deren Browser, bereits mit der Rolle dieses Kunden angemeldet, mit seinem Katalog und seinen Vertragspreisen.
3. Warenkorb-Rückgabe. Der Bedarfsträger füllt den Warenkorb und klickt auf „Zurück“ (oder „Zur Kasse“). Statt Ihres Checkouts geht der Warenkorb als strukturierte Nachricht zurück in sein Beschaffungssystem.
4. Freigabe und Bestellung. Der Warenkorb durchläuft die interne Freigabe des Kunden. Nach der Freigabe wird die Bestellung an Sie gesendet, und Sie bearbeiten sie wie jede andere Bestellung.

Für den Kunden wird Ihr Shop Teil seines Einkaufsprozesses: Er sieht Ihre aktuellen Preise und Bestände, und jede Bestellung folgt seinen Regeln. Für Sie kommen Bestellungen mit der Bestellnummer des Kunden an, ohne Datenerfassung auf beiden Seiten.

PunchOut im Vergleich zum statischen Katalog

Manche Kunden verlangen von Lieferanten außerdem eine statische Katalogdatei (oft eine CIF- oder cXML-Indexdatei), die in ihr System hochgeladen wird. Die beiden Modelle ergänzen sich:

Ist Ihr Sortiment klein und stabil, kann eine Datei genügen. Verkaufen Sie Tausende Produkte, konfigurierbare Artikel oder kundenspezifische Preise, bevorzugen Kunden meist PunchOut.

Die beiden Protokolle: cXML und OCI

Jede PunchOut-Session spricht eines von zwei Protokollen, und das System Ihres Kunden entscheidet, welches. cXML (Commerce eXtensible Markup Language) tauscht XML-Dokumente über HTTPS aus und wird von SAP Ariba, Coupa, Jaggaer, Ivalua, Oracle, Workday und den meisten Source-to-Pay-Systemen verwendet. Es überträgt auch die Bestellung selbst, als OrderRequest. OCI (Open Catalog Interface) ist das Protokoll von SAP, verwendet von SAP S/4HANA, SRM und ECC: Ihr Shop wird mit einer HOOK_URL geöffnet, und der Warenkorb geht als HTML-Formularfelder namens NEW_ITEM-* zurück. Die Bestellung erreicht Sie dann über einen separaten Kanal.

Unser Ratgeber cXML vs. OCI vergleicht beide Nachricht für Nachricht, mit Beispielen.

Warum Kunden PunchOut verlangen

Aus Sicht des Kunden löst PunchOut drei Probleme auf einmal. Erstens Kontrolle: Jeder Einkauf beginnt in seinem Beschaffungssystem und folgt damit seinen Freigaberegeln, Budgets und bevorzugten Lieferanten. Zweitens Genauigkeit: Preise, Artikelnummern und Beschreibungen kommen aus Ihrem Shop, niemand tippt sie ab, und Rechnungen passen zu den Bestellungen. Drittens Komfort für die Menschen, die tatsächlich einkaufen: Sie nutzen einen echten Shop mit Suche, Filtern und Konfigurationen statt einer statischen Liste.

Für einen Lieferanten kommt die Anfrage meist mit einer Frist: ein neuer Vertrag, eine Rahmenvereinbarung oder eine Ausschreibung, die PunchOut unter den Anforderungen nennt. Lieferanten, die schnell reagieren, behalten den Kunden; die anderen werden oft durch einen Wettbewerber ersetzt, der es kann.

Wer beteiligt ist

Ein PunchOut-Projekt betrifft mehrere Personen auf beiden Seiten. Wer sie früh kennt, spart Wochen:

PunchOut Level 1 und Level 2

Sie werden vielleicht von zwei PunchOut-Levels lesen. Level 1 öffnet Ihren Shop auf der Startseite: Der Kunde sucht und stöbert dort. Level 2 lässt den Kunden in seinem eigenen Beschaffungssystem suchen, in das ein kurzer Index Ihrer Produkte geladen ist, und öffnet Ihren Shop dann direkt beim gewählten Produkt oder der Kategorie. Level 2 braucht zusätzlich zum Live-Shop eine statische Indexdatei; fragen Sie Ihren Kunden also, was er erwartet. Die meisten beginnen mit Level 1.

Welche Beschaffungssysteme PunchOut nutzen

Praktisch alle. SAP Ariba ist die Anfrage, die wir von Lieferanten am häufigsten sehen, gefolgt von SAP über OCI und Coupa. Auch Jaggaer, Ivalua, GEP SMART, Oracle, Workday und Dutzende Procure-to-Pay-Lösungen für den Mittelstand unterstützen PunchOut. Siehe die vollständige Liste der unterstützten Systeme.

Was Ihr Kunde von Ihnen verlangen wird

Die Einkaufsabteilung Ihres Kunden schickt meist eine Lieferantendokumentation oder eine Onboarding-E-Mail. Lesen Sie sie zuerst: Darin steht genau, was erwartet wird. In der Regel werden Sie nach Folgendem gefragt oder erhalten es:

• Zugangsdaten: bei cXML Identitäten (bei SAP Ariba die Ariba Network ID oder ANID beider Unternehmen) und ein Shared Secret; bei OCI Login-Parameter für Ihren Katalog.
• URLs: die Setup-URL auf Ihrer Seite und die Rücksprung-URL (cXML) oder HOOK_URL (OCI) auf seiner Seite.
• Katalogregeln: welche Produkte und Preise dieser Kunde sehen soll, Mengeneinheiten und ein Klassifizierungsstandard (UNSPSC oder ECLASS) auf einer bestimmten Ebene.
• Einen Testplan: eine Testumgebung und Termine für seinen Abnahmetest (UAT).
• Unterlagen, bei Ausschreibungen und großen Kunden: Informationen zu Sicherheit und Hosting, ein Auftragsverarbeitungsvertrag, Referenzen.

Die Antworten unterscheiden sich je nach System; unsere Seiten zu SAP Ariba, SAP OCI und Coupa listen sie im Detail auf.

Was sich in Ihrem Shop ändert

PunchOut verlangt von einem Shop Dinge, die normale Online-Käufer nie verlangen. Das sind die üblichen Hürden:

• Öffnen innerhalb einer anderen Website. Viele Beschaffungssysteme zeigen Ihren Shop in einem Frame oder einem von ihnen gesteuerten Fenster. Sicherheits-Header wie X-Frame-Options und Cookies ohne SameSite=None; Secure unterbrechen die Session. Siehe den Ratgeber zum iFrame-Fehler.
• Das richtige Kundenkonto anmelden, damit der Kunde sein eigenes Sortiment und seine Vertragspreise sieht, ohne Passwort.
• Den Warenkorb zurückgeben, statt Ihren Checkout auszuführen, in dem Format, das das System des Kunden erwartet.
• Produktdaten: Mengeneinheiten, die den Codes des Kunden zugeordnet sind, und ein Klassifizierungscode für jedes Produkt. Siehe PunchOut-Kategorien.
• Die Bestellung empfangen: die freigegebene Bestellung in Ihren Shop importieren.

Ein PunchOut-Plugin mit Gateway löst all das standardisiert, sodass Shop, Theme und Checkout, die Sie schon haben, für Ihre anderen Kunden weiter funktionieren.

Ein realistischer 30-Tage-Plan

Die technische Einrichtung einer PunchOut-Verbindung auf einer unterstützten Plattform dauert Stunden, nicht Wochen. Zeit kostet die Abstimmung mit dem Kunden. Ein typischer Plan:

Den Endtermin bestimmt die Testplanung Ihres Kunden: Manche Einkaufsabteilungen planen den UAT Wochen im Voraus. Fragen Sie früh nach den Terminen, und wenn die Frist knapp ist, lassen Sie die Einrichtung von Spezialisten übernehmen, zum Beispiel mit unserem Service Go-Live Assist.

Was PunchOut kostet

Es gibt drei übliche Wege, eine PunchOut-Anfrage zu erfüllen, mit sehr unterschiedlichen Kosten:

• Ein individuelles Integrationsprojekt, das ein Entwickler oder eine Agentur für Ihren Shop baut. Sie zahlen Entwicklung und Tests für jedes Protokoll und jeden Kunden sowie die Wartung, sobald sich Ihre Plattform oder das System des Kunden ändert.
• Ein Dienst, der pro Kunde abrechnet, meist mit einer Monatsgebühr für jeden angebundenen Kunden plus Einrichtungsgebühren. Günstig für einen Kunden, teuer mit jedem weiteren.
• Ein Plugin mit verwaltetem Gateway wie PunchOut Rocket: ein fester Jahrespreis pro Shop. PunchOut Rocket kostet 1.950 € pro Jahr für WooCommerce und 2.950 € für Magento, PrestaShop, nopCommerce oder die REST API, mit bis zu 10 Kunden inklusive.

Die vollständige Preisliste und einen Vergleichsrechner finden Sie unter Preise.

Checkliste vor dem Test des Kunden

• Zugangsdaten und URLs für die Testumgebung sind konfiguriert, und eine Test-Session funktioniert von Anfang bis Ende.
• Der Kunde sieht nur die vertraglich vereinbarten Produkte und Preise.
• Jedes Produkt im Sortiment des Kunden hat den Klassifizierungscode und die Mengeneinheit, die er verlangt.
• Ein zurückgegebener Warenkorb enthält Ihre Artikelnummern, Preise, Mengen und die Währung so, wie der Kunde sie erwartet.
• Sie wissen, wie die Bestellung zu Ihnen kommt (cXML OrderRequest oder ein anderer mit dem Kunden vereinbarter Kanal) und wer sie bearbeitet.
• Sie haben für den Testtag einen Ansprechpartner im Team des Kunden, und er hat Ihren.

Häufige Stolperfallen

• Mit dem Shop anfangen, bevor man die Lieferantendokumentation des Kunden gelesen hat: Sie enthält oft Feldregeln, die Ihre Einrichtung ändern.
• Nur im Produktivsystem des Kunden testen: Fragen Sie immer zuerst nach der Testumgebung.
• Mengeneinheiten und Klassifizierung vergessen: Warenkörbe werden abgelehnt, wenn die Codes nicht zu denen des Kunden passen.
• Den Kalender des Kunden unterschätzen: UAT-Termine können Wochen entfernt sein. Buchen Sie sie, sobald Sie die Zugangsdaten haben.
• Auftragsbestätigungen, Lieferavise oder Rechnungen per cXML versprechen, ohne die passende Option zu haben: Bestätigungen und Lieferavise brauchen die Option OC & ASN, Rechnungen gibt es auf Anfrage.