Format · Lesen und Schreiben
cXML-Bestellungen aus Coupa und Ariba
Kunden, die mit Coupa oder SAP Ariba einkaufen, stellen Bestellungen als cXML bereit oder lassen Sie sie im Portal abholen und abtippen. every-edi liest cXML-Bestellungen (OrderRequest) und erzeugt sie auch, wenn Ihr System oder ein Partner cXML erwartet.
Auf einen Blick
- Standard
- cXML (commerce eXtensible Markup Language)
- Dokument
- OrderRequest (Bestellung)
- Typische Quelle
- Coupa, SAP Ariba und andere Einkaufsplattformen
- every-edi
- Lesen und Schreiben
- Verarbeitung
- Regelbasiert, ohne KI
Wofür cXML da ist
cXML ist ein XML-Format für den Austausch von Beschaffungsdokumenten zwischen Einkaufssystemen und Lieferanten. Anders als EDIFACT ist es für Menschen lesbar, wird meist per HTTPS übertragen und trägt die Anmeldedaten des Absenders im Kopf jeder Nachricht mit.
Die Bestellung heißt in cXML OrderRequest. Sie besteht aus einem Kopf mit Bestellnummer, Datum, Gesamtbetrag sowie Liefer- und Rechnungsadresse und aus einer Liste von ItemOut-Positionen.
Wer cXML verlangt
Lieferanten begegnen cXML vor allem über die Einkaufsplattformen ihrer Kunden. Großunternehmen, die mit Coupa oder SAP Ariba beschaffen, stellen ihre Bestellungen dort ein. Der Lieferant kann sie im Portal ansehen und von Hand ins eigene ERP übertragen, oder er lässt sich so anbinden, dass die Bestellung als cXML direkt in sein System fließt.
Gerade bei wenigen, aber großen Portal-Kunden ist das ein typischer Engpass: Die Bestellungen sind beim Kunden längst elektronisch und kommen beim Lieferanten trotzdem als Abtipp-Arbeit an.
Beispiel
Eine fiktive OrderRequest über drei Positionen. Das Shared Secret ist unkenntlich gemacht: In echten Nachrichten ist es ein Passwort und gehört weder in E-Mails noch in Tickets.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.050/cXML.dtd">
<cXML payloadID="20261008093000.4711@einkauf.example"
timestamp="2026-10-08T09:30:00+02:00" xml:lang="de-DE">
<Header>
<From>
<Credential domain="NetworkID"><Identity>AN01000000001</Identity></Credential>
</From>
<To>
<Credential domain="NetworkID"><Identity>AN01000000002</Identity></Credential>
</To>
<Sender>
<Credential domain="NetworkID">
<Identity>AN01000000001</Identity>
<SharedSecret>********</SharedSecret>
</Credential>
<UserAgent>Beschaffungssystem</UserAgent>
</Sender>
</Header>
<Request deploymentMode="production">
<OrderRequest>
<OrderRequestHeader orderID="4500012345"
orderDate="2026-10-08T09:30:00+02:00" type="new">
<Total><Money currency="EUR">1499.00</Money></Total>
<ShipTo>
<Address addressID="HB-LAGER-NORD">
<Name xml:lang="de-DE">Beispiel Haustechnik GmbH</Name>
<PostalAddress>
<DeliverTo>Lager Nord, Tor 3</DeliverTo>
<Street>Hafenstraße 40</Street>
<City>Bremen</City>
<PostalCode>28217</PostalCode>
<Country isoCountryCode="DE">Deutschland</Country>
</PostalAddress>
</Address>
</ShipTo>
<BillTo>
<Address addressID="HB-ZENTRALE">
<Name xml:lang="de-DE">Beispiel Haustechnik GmbH</Name>
</Address>
</BillTo>
</OrderRequestHeader>
<ItemOut quantity="4" lineNumber="1" requestedDeliveryDate="2026-10-15">
<ItemID><SupplierPartID>ART-7720</SupplierPartID></ItemID>
<ItemDetail>
<UnitPrice><Money currency="EUR">285.00</Money></UnitPrice>
<Description xml:lang="de-DE">Hydraulikzylinder HZ-200/100</Description>
<UnitOfMeasure>PCE</UnitOfMeasure>
<Classification domain="UNSPSC">40151500</Classification>
</ItemDetail>
</ItemOut>
<ItemOut quantity="4" lineNumber="2" requestedDeliveryDate="2026-10-15">
<ItemID><SupplierPartID>ART-3381</SupplierPartID></ItemID>
<ItemDetail>
<UnitPrice><Money currency="EUR">42.50</Money></UnitPrice>
<Description xml:lang="de-DE">Dichtungsset DS-200</Description>
<UnitOfMeasure>SET</UnitOfMeasure>
<Classification domain="UNSPSC">31411700</Classification>
</ItemDetail>
</ItemOut>
<ItemOut quantity="10" lineNumber="3" requestedDeliveryDate="2026-10-15">
<ItemID><SupplierPartID>ART-9910</SupplierPartID></ItemID>
<ItemDetail>
<UnitPrice><Money currency="EUR">18.90</Money></UnitPrice>
<Description xml:lang="de-DE">Hydraulikschlauch 2m DN10</Description>
<UnitOfMeasure>MTR</UnitOfMeasure>
<Classification domain="UNSPSC">40142000</Classification>
</ItemDetail>
</ItemOut>
</OrderRequest>
</Request>
</cXML> Alle Namen, Nummern und GLNs im Beispiel sind fiktiv.
| Element | Bedeutung |
|---|---|
| <!DOCTYPE cXML … 1.2.050 …> | Version der cXML-DTD, gegen die die Nachricht geprüft wird. |
| payloadID, timestamp | Eindeutige Kennung und Zeitstempel der Nachricht. Kommt dieselbe payloadID zweimal, ist es dieselbe Nachricht. |
| <From>, <To> | Käufer und Lieferant, jeweils über eine Credential mit domain und Identity (hier eine Netzwerk-ID). |
| <Sender> mit <SharedSecret> | Das System, das die Nachricht technisch verschickt, und das Passwort, mit dem es sich beim Empfänger ausweist. |
| deploymentMode | test oder production. Testbestellungen dürfen nicht im echten Auftragsbestand landen. |
| <OrderRequestHeader … type="new"> | Bestellkopf mit Bestellnummer und Datum. new = neue Bestellung, update = Änderung, delete = Storno. |
| <Total> | Gesamtbetrag der Bestellung. |
| <ShipTo>, <BillTo> | Liefer- und Rechnungsadresse; addressID ist die Adresskennung im System des Käufers. |
| <ItemOut quantity lineNumber …> | Position mit Menge, Positionsnummer und Wunschtermin. |
| <SupplierPartID> | Ihre Artikelnummer. |
| <UnitOfMeasure> | Mengeneinheit als Code nach UN/ECE Recommendation 20: PCE = Stück (manche Plattformen nutzen EA), SET = Satz, MTR = Meter. |
| <Classification domain="UNSPSC"> | Warengruppe nach UNSPSC; im Beispiel nur zur Veranschaulichung. Den Wert gibt meist der Käufer vor. |
Typische Stolperfallen
-
Credentials und Shared Secret
domain und Identity in From, To und Sender müssen genau so ankommen, wie die Plattform sie erwartet, bis hin zur Groß- und Kleinschreibung des domain-Werts. Ein falsches oder abgelaufenes Shared Secret führt zur Ablehnung.
-
Änderungen und Stornos
Eine Bestelländerung kommt als vollständige neue OrderRequest mit derselben orderID und type="update", ein Storno mit type="delete". Wer nur „new“ erwartet, legt Aufträge doppelt an.
-
Einheiten-Codes
UnitOfMeasure erwartet UN/CEFACT-Codes. Ein „Stk“ aus dem eigenen ERP ist kein gültiger Wert und wird von strengen Systemen abgelehnt.
-
Test- und Produktivmodus
deploymentMode="test" kennzeichnet Testnachrichten. Werden sie nicht aussortiert, landen Testbestellungen im echten Auftragsbestand.
-
Zusatzfelder je Plattform und Käufer
Kostenstellen, Projektnummern oder Freigabevermerke stehen oft in Extrinsic-Feldern, die jede Plattform und jeder Käufer anders belegt. Welche davon Ihr ERP braucht, gehört in die Zuordnung.
-
Zeitzonen
Datumsangaben in cXML tragen eine Zeitzone. Eine Bestellung kurz nach Mitternacht kann nach der Umrechnung im ERP auf dem Vortag landen.
Was every-edi damit macht
- Lesen: cXML-OrderRequests werden direkt verarbeitet, regelbasiert und ohne KI, und in das Format übersetzt, das Ihr ERP versteht.
- Schreiben: Aus PDF-, E-Mail-, CSV- oder EDIFACT-Bestellungen entsteht eine cXML-OrderRequest, wenn ein System cXML erwartet.
- Unvollständige oder unplausible Bestellungen landen im Prüf-Dashboard.
- Den Übertragungsweg (Datei, E-Mail, SFTP oder HTTPS-Schnittstelle auf Anfrage) stimmen wir mit Ihnen und der Plattform Ihres Kunden ab.
Was (noch) nicht dazugehört
Bei cXML verarbeitet every-edi Bestellungen (OrderRequest). Auftragsbestätigungen (ConfirmationRequest), Lieferavise (ShipNoticeRequest), Rechnungen (InvoiceDetailRequest) und PunchOut-Kataloge gehören derzeit nicht zum Umfang.
Weitere Formate
Außerdem verarbeitet every-edi GEVIS-XML (GEVISEDI01), CSV mit Kopf- und Positionszeilen (HDR/POS), frei aufgebaute CSV-Tabellen über gelernte CSV-Profile sowie JSON über eine REST-Schnittstelle.
Schicken Sie uns eine echte Datei.
Ob every-edi zu Ihren Kunden passt, klären wir am schnellsten an echten Beispielen: drei Bestellungen und, falls vorhanden, die Spezifikation Ihres Partners. Sie bekommen das Ergebnis im Zielformat zurück.
Demo anfragen