Ihr Großkunde will PunchOut. Ein übertragener Warenkorb ist noch keine Bestellung.

Ein deutscher Industriekunde möchte Ihren Katalog direkt aus seinem Einkaufssystem öffnen. Das klingt nach einem zusätzlichen Login und einer Schaltfläche zum Zurücksenden des Warenkorbs. Tatsächlich verschiebt sich damit ein Teil des Kaufprozesses: Ihr Shop unterstützt die Auswahl, während Genehmigung und Bestellung im System des Kunden stattfinden können.

Für technische Händler und Hersteller ist eine PunchOut-Anbindung deshalb ein konkretes Vertriebsprojekt. Sie kann den Einkauf für bestehende Kunden erleichtern. Dafür muss sie Konditionen, Artikel und Zuständigkeiten korrekt übertragen. Eine technisch erfolgreiche Rückleitung ist noch kein Beweis dafür, dass am Ende die richtige Bestellung im eigenen ERP ankommt.

Zeichnen Sie den vollständigen Einkaufsweg

Beginnen Sie beim tatsächlichen Kundensystem. Wer startet die Sitzung, für welche Organisation und mit welchen Berechtigungen? Was geschieht nach der Rückgabe des Warenkorbs? Wer genehmigt, und über welchen Weg trifft der verbindlich zu verarbeitende Auftrag bei Ihnen ein?

Die cXML-FAQ zum PunchOut-Ablauf unterscheidet die Sitzung mit Warenkorbübertragung von weiteren Geschäftsdokumenten wie Bestellungen. Die SAP-Dokumentation zum Open Catalog Interface beschreibt die Übernahme von Materialien oder Leistungen aus externen Katalogen. Beide Quellen erklären Schnittstellenfunktionen; den konkreten Freigabeprozess Ihres Kunden müssen Sie zusätzlich erheben.

Halten Sie das Ergebnis in einer kurzen Prozessbeschreibung fest. Ein Warenkorb darf nicht versehentlich Lagerbestand abbuchen oder einen Versand auslösen. Falls Sie während der Auswahl Reservierungen anbieten, brauchen diese einen ausdrücklich vereinbarten Zweck, eine Gültigkeit und einen Umgang mit abgebrochenen Sitzungen.

Übertragen Sie die richtige Preisbedeutung

Ein Preis ist ohne Einheit unvollständig. Ein Kunde kann zehn Stück auswählen, während der Vertrag einen Preis pro hundert Stück enthält. Die Oberfläche sieht korrekt aus, doch eine falsch zugeordnete Preiseinheit verändert den Einkaufswert. Solche Fehler entstehen auch dann, wenn alle technischen Pflichtfelder ausgefüllt sind.

Definieren Sie Artikelnummer, Bestelleinheit, Preiseinheit, Währung und Mengenstaffel gemeinsam mit dem Kunden. Ergänzen Sie die tatsächlich benötigten Klassifikationen und Vertragsreferenzen. Prüfen Sie, welche Werte aus dem ERP kommen und welche das Beschaffungssystem nach der Übertragung neu berechnet oder überschreibt.

Nutzen Sie dieselbe freigegebene Preisquelle wie in Ihren anderen B2B-Kanälen. Eine zweite Konditionstabelle nur für PunchOut verursacht später Abweichungen. Wenn der Preis während der internen Freigabe beim Kunden abläuft, muss der nachfolgende Auftrag eine klare Prüfregel auslösen. Ein gespeicherter Warenkorb ist kein unbegrenztes Preisversprechen.

Eine Sitzung gehört zu einer Organisation

Der Aufruf aus einem Einkaufssystem muss zum richtigen Kundenkonto führen. Eine vom Browser übermittelte Kundennummer allein sollte keine fremden Konditionen freischalten. Vereinbaren Sie die Authentisierung, zulässige Rücksprungziele und die Laufzeit einer Sitzung passend zur konkreten Plattform.

Denken Sie an parallel geöffnete Fenster. Ein Einkäufer kann mehrere Anforderungen vorbereiten oder verschiedene Organisationseinheiten vertreten. Der zurückgegebene Warenkorb muss zur richtigen Ausgangssitzung gehören. Er darf nicht versehentlich Positionen aus dem normalen Shopkonto oder einer anderen Beschaffungsanfrage enthalten.

Auch die Protokollierung braucht Grenzen. Für die Fehlersuche sind nachvollziehbare Vorgangskennungen hilfreich; Zugangsdaten und vollständige vertrauliche Konditionslisten gehören nicht in frei zugängliche Diagnoseprotokolle. Legen Sie fest, welche Mitarbeiter einen Vorgang sehen und wie sensible Daten bei einem Supportfall geteilt werden.

Prüfen Sie Bearbeiten und Abbrechen

Ein guter Test endet nicht beim ersten erfolgreichen Rücksprung. Manche Kunden wollen einen bereits übertragenen Warenkorb wieder öffnen, prüfen oder verändern. Welche dieser Funktionen unterstützt wird, hängt von der Plattform und der vereinbarten Integration ab. Lassen Sie sich keine pauschale Kompatibilität ohne einen passenden Test zusagen.

Ein fiktiver Einkaufsvorgang enthält eine inzwischen ausgelaufene Artikelnummer. Beim erneuten Öffnen sollte der Shop die Abweichung erklären und eine freigegebene Alternative oder Rückfrage anbieten. Einfach die alte Position zu entfernen, kann dem Einkäufer eine unvollständige Anforderung hinterlassen, ohne dass er die Ursache erkennt.

Beschreiben Sie ebenso, was beim Abbruch geschieht. Ein leerer oder nicht zurückgesendeter Warenkorb sollte keinen Geisterauftrag erzeugen. Nach einem Verbindungsfehler muss verständlich sein, ob der Kunde die Auswahl erneut übertragen kann und welches System den letzten bestätigten Stand hält.

Bestelleingang braucht eine eigene Prüfung

Wenn die tatsächliche Bestellung eintrifft, prüfen Sie sie gegen die vereinbarten Geschäftsregeln. Stimmen Kunde, Lieferadresse, Positionen und Konditionen? Existiert die Bestellnummer bereits? Muss eine Preis- oder Mengenabweichung in eine fachliche Klärung statt direkt in die Auftragsanlage führen?

Diese Prüfung ist auch bei einer fertigen Erweiterung wichtig. Ein Plugin kann das Protokoll beherrschen, ohne Ihre internen Ausnahmefälle zu kennen. Entscheiden Sie deshalb bewusst, welche Aufgaben eine Standardlösung übernimmt und wo eine ergänzende Schnittstelle erforderlich ist. Ein vollständiger Eigenbau ist keine Voraussetzung für eine gute Integration.

Diese Abnahme gehört in die Ausschreibung

Bitten Sie Anbieter um eine gemeinsame Vorführung mit der Testumgebung Ihres Kunden. Der Umfang sollte mindestens diese Fälle umfassen:

• Ein kundenspezifischer Preis bleibt mit seiner Mengen- und Preiseinheit nachvollziehbar.
• Zwei parallele Sitzungen übertragen ihre jeweiligen Warenkörbe getrennt.
• Ein nicht zulässiges Rücksprungziel wird abgewiesen.
• Eine unterbrochene Sitzung erzeugt weder Bestellung noch Versand.
• Eine später eingehende Bestellung durchläuft die vereinbarte Prüfung.
• Eine wiederholte Bestellnachricht legt keinen zweiten Auftrag an.

Dokumentieren Sie außerdem Betrieb und Verantwortlichkeiten. Wer bemerkt einen fehlgeschlagenen Transfer? Welche Informationen erhält der Kundensupport? Wie wird eine geänderte Feldanforderung getestet, bevor sie alle Einkäufer betrifft? Diese Fragen entscheiden darüber, ob die Anbindung nach dem Projektabschluss verlässlich nutzbar bleibt.

Mit einem Kunden anfangen, sauber erweitern

Ein sinnvoller Pilot verbindet einen konkreten Kunden, ein Protokoll und ein abgegrenztes Sortiment. Bewerten Sie nicht nur technische Fehlerraten, sondern auch manuelle Nacharbeiten und ungeklärte Aufträge. So wird sichtbar, wo die Integration den Vertrieb tatsächlich entlastet und wo Stammdaten verbessert werden müssen.

Unser Beitrag zu verständlich gestalteten APIs ergänzt die technische Zusammenarbeit; Angebote anhand von Änderungsfällen vergleichen hilft bei der Beschaffung. Über unsere Software- und Integrationsleistungen lassen sich bestehende Shop- und ERP-Systeme gezielt verbinden. Nennen Sie uns das Beschaffungssystem Ihres ersten PunchOut-Kunden, um den tatsächlichen Integrationsumfang zu klären.

Häufige Fragen

Ist ein PunchOut-Warenkorb bereits ein Auftrag?

Nicht automatisch. Der Warenkorb wird typischerweise in das Beschaffungssystem zurückgegeben und dort weiterbearbeitet. Der tatsächliche Bestelleingang muss separat nach dem vereinbarten Kundenprozess verarbeitet werden.

Sind OCI und cXML austauschbar?

Nein. Sie unterstützen verwandte Beschaffungsabläufe, haben aber unterschiedliche Nachrichten und Integrationsanforderungen. Die konkrete Plattform, Version und Feldbelegung des Kunden bestimmen die Umsetzung.

Wann reicht eine vorhandene PunchOut-Erweiterung?

Wenn sie das Kundensystem, die benötigten Artikel- und Preisfelder sowie die Sicherheits- und Bestellabläufe korrekt unterstützt. Prüfen Sie diese Punkte mit einem vollständigen Test zwischen beiden Systemen.