cXML-Schnittstelle im Elektrogroßhandel richtig anbinden

Ein Industriekunde möchte künftig aus seinem Beschaffungssystem in Ihren Elektrogroßhandelsshop wechseln, Installationsmaterial auswählen und den Warenkorb zur Freigabe zurückgeben. Nach der Genehmigung soll die Bestellung automatisch im ERP ankommen. Beim ersten Test erscheint der Warenkorb korrekt, doch Projektbezug, Verpackungseinheit und Lieferanschrift fehlen. Ein erneuter Versand nach einem Zeitablauf erzeugt zudem zwei Aufträge.

Eine cXML-Schnittstelle verbindet Beschaffungssystem, Shop und Bestelleingang nur dann belastbar, wenn PunchOut-Sitzung, Warenkorbrückgabe und Bestellung als getrennte Vorgänge geführt werden. IT und Fachbereich müssen Partnerkennungen, Artikelreferenzen, Einheiten, Preise, Lieferorte, Zugangsdaten, Dublettenprüfung und Fehlerpfade gemeinsam festlegen. Der Warenkorb ist noch keine Bestellung. Verbindlich wird der Vorgang erst nach der kundenseitigen Freigabe und dem anschließenden Bestelleingang.

Wie funktioniert eine cXML-Schnittstelle im Elektrogroßhandel?

cXML steht für Commerce XML. Das Protokoll dient dem strukturierten Austausch von Geschäftsdokumenten zwischen Beschaffungsanwendungen, Handelsplattformen und Lieferanten. Die offizielle cXML-Seite, abgerufen am 25. Oktober 2026, nennt neben Katalogen und PunchOut auch Bestellungen, Bestelländerungen, Bestellbestätigungen, Lieferavise und Rechnungen. Die aktuelle Fassung ist cXML 1.2.071 vom 14. August 2026.

Für einen Elektrogroßhändler besteht der typische Ablauf aus fünf getrennten Schritten:

1. Der Einkäufer startet im Beschaffungssystem seines Unternehmens und wählt den angebundenen PunchOut-Katalog.
2. Das Beschaffungssystem sendet einen PunchOutSetupRequest. Der Shop prüft Absender, Kunde, Benutzerkontext und erlaubten Vorgang.
3. Der Shop antwortet mit einem PunchOutSetupResponse und einer Startadresse für die zugehörige Sitzung.
4. Der Einkäufer wählt im Shop Artikel aus. Beim Abschluss gibt der Shop den Warenkorb als PunchOutOrderMessage an das Beschaffungssystem zurück.
5. Dort folgen Kontierung und Freigabe. Erst danach sendet das Beschaffungssystem die verbindliche Bestellung, beispielsweise als cXML OrderRequest, an den Fachgroßhandel.

Der cXML Reference Guide 1.2.071, Stand 14. August 2026, beschreibt diese Abfolge ausdrücklich. Die Warenkorbrückgabe gilt dabei als Angebot der ausgewählten Positionen. Der Lieferant hat zu diesem Zeitpunkt noch keine Bestellung erhalten und darf den Auftrag noch nicht buchen.

Welche cXML-Nachricht erfüllt welche Aufgabe?

Die Nachrichtennamen ähneln sich, ihre fachliche Wirkung ist jedoch verschieden. Diese Zuordnung gehört in das Abnahmedokument des Piloten:

Gerade die letzte Zeile verhindert einen gefährlichen Kurzschluss. Laut Referenzleitfaden bestätigt eine erfolgreiche Antwort auf den OrderRequest, dass die Nachricht verarbeitet werden konnte. Sie sagt nicht, welche Position lieferbar ist oder in Rückstand geht. Dafür braucht der Geschäftsprozess eine nachgelagerte Bestellbestätigung und klare Statusregeln.

Welche Daten müssen Shop, Einkaufssystem und ERP zuordnen?

Die cXML-Datei schafft keine gemeinsame Stammdatenlogik. Sie transportiert Felder, deren Bedeutung beide Seiten vorab festlegen müssen. Für den Elektrogroßhandel sind diese Zuordnungen besonders wichtig:

• Geschäftspartner: Käufergesellschaft, Kundennummer, Rechnungsempfänger und Lieferstelle müssen eindeutig zusammenpassen.
• Benutzer und Rechte: Benutzerkennung, Kostenstelle, Werk oder Einkaufsorganisation dürfen nur den vorgesehenen Kundenkontext öffnen.
• Artikel: Lieferantenartikelnummer, Herstellerartikelnummer, kundeneigene Artikelnummer und gegebenenfalls SupplierPartAuxiliaryID dürfen nicht verwechselt werden.
• Menge und Einheit: Stück, Pack, Meter, Trommel und Preisbezugsmenge brauchen eine eindeutige Übersetzung in das ERP.
• Preis und Währung: Kundenpreis, Projektpreis, Zuschlag und Gültigkeitszeitpunkt müssen aus der vereinbarten führenden Quelle stammen.
• Projektbezug: Kommission, Baustelle, Kostenstelle oder kundenseitige Anforderungsnummer müssen den Folgeprozess erreichen.
• Lieferung: Lieferanschrift, gewünschter Termin, Teillieferungsregel und Versandart müssen fachlich prüfbar sein.

Der Shop kann Artikelsuche, technische Merkmale und Konfiguration bereitstellen. Preise, Kundenzuordnung und Verkaufsauftrag bleiben in der Regel im ERP führend. Bestand und Reservierung können zusätzlich aus Lagerverwaltung oder Warenwirtschaft kommen. Eine saubere ERP-Integration legt deshalb für jeden Wert fest, welches System ihn führt, wann er gelesen wird und wer Abweichungen klärt.

Im Elektrogroßhandel gehören auch schwierige Artikel in den Test. Ein Standard-Schalter genügt nicht. Prüfen Sie etwa Kabelzuschnitte, unterschiedliche Verpackungseinheiten, kundenspezifische Projektpreise, Ersatzartikel und Positionen mit abweichender Lieferstelle. Erst diese Fälle zeigen, ob das Mapping im Tagesgeschäft trägt.

Wie unterscheiden sich cXML PunchOut, OCI und EDI?

cXML PunchOut und OCI lösen beide einen Katalogabsprung mit Warenkorbrückgabe. Sie sind trotzdem keine austauschbaren Endpunkte. cXML verwendet definierte XML-Nachrichten, einen Nachrichtenkopf mit Partnerkennungen, eine Versionslogik und eigene Dokumente für den PunchOut-Ablauf. cXML kann außerdem Bestellungen übertragen. Diese Bestellannahme ist laut Referenzleitfaden eine eigene Fähigkeit und nicht automatisch durch eine funktionierende PunchOut-Seite gegeben.

OCI konzentriert sich auf Katalogaufruf und Warenkorbrückgabe. Welche Felder und Prüfungen dort erforderlich sind, beschreibt der gesonderte Beitrag zur OCI-Schnittstelle im Fachgroßhandel. Ein Kundensystem, das OCI verlangt, wird nicht allein durch einen vorhandenen cXML-Endpunkt angebunden.

EDI ist der Oberbegriff für den strukturierten elektronischen Austausch von Geschäftsdokumenten. Dazu können EANCOM, cXML oder andere vereinbarte Formate gehören. Die Prozessseite zu EDI und E-Procurement ordnet Katalogzugriff, Bestellung, Bestellantwort und weitere Belege in die gesamte Kette ein. Für die Umsetzung reicht die Aussage „Wir können EDI“ nicht. Version, Nachrichtentyp, Übertragungsweg und Partnerprofil müssen konkret benannt sein.

Dass cXML im Elektrofachgroßhandel praktisch angeboten wird, zeigt Rexel Germany auf der Seite Digital Services, abgerufen am 25. Oktober 2026. Dort wird cXML neben OCI und IDS als PunchOut-Anbindung genannt. Das Branchenbeispiel belegt die praktische Relevanz, ersetzt aber keine technische Spezifikation für Ihren Shop und das Beschaffungssystem Ihres Kunden.

Wie schützen Sie Zugangsdaten und Partnerrechte?

Der cXML-Kopf unterscheidet From, To und Sender. Damit werden fachlicher Absender, Ziel und die tatsächlich sendende Stelle abgebildet. Die zugehörigen Credential-Elemente enthalten eine Identität für eine vereinbarte Domäne. Bei vermittelnden Plattformen kann der Sender wechseln, während Absender und Ziel gleich bleiben.

Für die IT folgen daraus klare Regeln:

• Partnerkennung und Domäne werden gegen eine freigegebene Konfiguration geprüft, nicht nur gegen einen frei übermittelten Text.
• Zugangsdaten liegen ausschließlich in einer Geheimnisverwaltung. Sie erscheinen weder im Quellcode noch vollständig in Protokollen.
• Test und Produktion erhalten getrennte Endpunkte, Kennungen und Zugangsdaten.
• cXML wird über HTTPS übertragen. Zertifikate, Ablaufdaten und erlaubte Gegenstellen werden überwacht.
• XML-Parser erhalten Größen- und Zeitgrenzen. Nicht benötigte externe Entitäten werden nicht nachgeladen.
• Rückgabeadressen, Sitzungen und Benutzerkontext werden gegen die vereinbarte Verbindung geprüft.

Der Referenzleitfaden warnt ausdrücklich davor, Authentifizierungsgeheimnisse in einseitigen Nachrichten zu übertragen, die durch den Browser laufen. Beim PunchOutOrderMessage stellt der BuyerCookie den Bezug zum ursprünglichen PunchOutSetupRequest her. Er ersetzt jedoch keine eigene Sitzungsprüfung und darf nicht als dauerhaftes Benutzerkonto behandelt werden.

Wie verhindern Sie Dubletten und verlorene Bestellungen?

Jedes cXML-Dokument trägt eine payloadID. Laut Referenzleitfaden muss sie räumlich und zeitlich eindeutig sein und bei einem Wiederholungsversuch unverändert bleiben. Genau das ermöglicht eine idempotente Verarbeitung: Derselbe Absender mit derselben payloadID darf nicht ein zweites Mal denselben Auftrag anlegen.

Für Bestellungen reicht die technische Kennung allein nicht. Prüfen Sie zusätzlich orderID, Bestellversion, Kundennummer und Nachrichtentyp. Ein echter Änderungsauftrag muss vom versehentlichen Wiederholungsversand unterscheidbar sein. Speichern Sie deshalb zuerst den Eingang samt Prüfergebnis, bevor Sie den ERP-Auftrag anlegen. Danach wird das Ergebnis derselben payloadID bei einem erneuten Versuch zurückgegeben.

Die Fehlerlogik muss zwischen dauerhaften und vorübergehenden Fehlern unterscheiden. cXML ordnet Antworten der Klassen 2xx, 4xx und 5xx zu. Ein unbekannter Partner oder ein unzulässiges Pflichtfeld darf nicht endlos wiederholt werden. Eine vorübergehend nicht erreichbare ERP-Übergabe braucht dagegen einen kontrollierten Wiederanlauf. Der Eingang bleibt in einer Warteschlange sichtbar, bis er verarbeitet oder fachlich zurückgewiesen ist.

Welche Tests gehören vor den Produktivbetrieb?

Vereinbaren Sie zuerst die tatsächlich unterstützte cXML-Version. Die Release Notes, abgerufen am 25. Oktober 2026, dokumentieren laufende Änderungen bis Version 1.2.071. Ein neueres Schema darf nicht ungeprüft vorausgesetzt werden, wenn das Beschaffungssystem des Kunden eine ältere Fassung unterstützt.

Ein belastbarer Abnahmesatz umfasst mindestens diese Fälle:

1. Berechtigter und unbekannter Partner rufen den richtigen Shopkontext auf.
2. Erstellen, Abbrechen und erneutes Öffnen einer PunchOut-Sitzung verhalten sich wie vereinbart.
3. Artikelnummer, Menge, Einheit, Preis, Währung und Projektbezug kommen vollständig zurück.
4. Sonderzeichen und Umlaute bleiben in Beschreibung und Referenzen erhalten.
5. Der zurückgegebene Warenkorb erzeugt vor der Freigabe keinen ERP-Auftrag.
6. Ein gültiger OrderRequest legt genau einen Auftrag an.
7. Derselbe OrderRequest wird nach einem Zeitablauf erneut gesendet und nicht doppelt gebucht.
8. Unbekannter Artikel, gesperrter Kunde, falsche Einheit und abweichender Preis landen mit erkennbarem Grund in der Prüfung.
9. Ein technischer Ausfall von Shop, Plattform oder ERP wird erkannt, protokolliert und nach dem vereinbarten Rückfallweg behandelt.
10. Eine erfolgreiche technische Antwort wird nicht als Lieferzusage an den Kunden ausgegeben.

Wie sieht ein kleiner cXML-Pilot aus?

Wählen Sie einen Kunden mit klarer Anforderung, ein Beschaffungssystem, einen Shop-Mandanten und ein abgegrenztes Sortiment. Im ersten Abschnitt prüfen Sie nur Anmeldung, Kundensicht und Warenkorbrückgabe. Erst wenn Artikel, Einheiten, Preise und Projektdaten stimmen, aktivieren Sie den OrderRequest bis zur kontrollierten ERP-Anlage.

Messen Sie vor und während des Piloten dieselben Größen: erfolgreiche PunchOut-Aufrufe, vollständig zurückgegebene Warenkörbe, Bestellungen ohne manuelle Korrektur, abgefangene Dubletten, fachliche Ausnahmen, technische Abbrüche, Zeit bis zur Fehlerklärung und laufenden Supportaufwand je angebundenem Kunden. Die Werte zeigen, ob die Anbindung den Innendienst entlastet oder nur neue Klärfälle erzeugt.

Dokumentieren Sie zum Abschluss das Partnerprofil mit Version, Endpunkten, Kennungsdomänen, unterstützten Nachrichten, Pflichtfeldern, Verantwortlichen und Rückfallweg. So bleibt die Anbindung auch nach einem Personalwechsel oder einer Systemaktualisierung betreibbar.

Wenn Sie eine konkrete Kundenanforderung vorliegen haben, prüfen Sie zuerst einen echten Warenkorb und eine echte Bestellung vom Beschaffungssystem bis zur ERP-Anlage. Den passenden Pilotumfang können Sie anschließend in einem unverbindlichen Gespräch mit Conveso abgrenzen.

Fynn Governatori

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