Sample documents
One worked example of every message this sandbox sends or receives. Each is generated by the same builder that produces the real thing, at the moment you ask for it — so they are DTD-valid by construction and cannot drift out of date the way a pasted example does.
PunchOutSetupRequest
What your system sends to open a session. The one document here that you send and we receive.
PunchOutOrderMessage
The cart coming back. Your extractor reads this — note that SupplierPartAuxiliaryID must survive unchanged into your order.
ConfirmationRequest
Order confirmation. UnitOfMeasure appears TWICE, once in ConfirmationItem and again in ConfirmationStatus: both are mandatory.
ShipNoticeRequest
Dispatch notification. ItemID is OPTIONAL here and UnitOfMeasure is not — the reverse of every other item block in cXML, and the usual reason an extractor written from the other documents fails on this one. ShipControl is a SIBLING of ShipNoticePortion, not inside it: one shipment can cover several orders.
InvoiceDetailRequest
Invoice. Both indicator elements are mandatory and ordered even when empty, and UnitOfMeasure and UnitPrice come BEFORE the item reference.
Documents designed to break your parser
Every sample above agrees with itself — the ship notice despatches
exactly what was ordered, in the same unit, at the same price. So an
extractor that ignores UnitOfMeasure entirely passes all of
them.
These do not. Each is conformant cXML that a real supplier really sends, disagreeing with the order in exactly one way. The point is not malformed input — the validator already covers that — but well-formed input carrying a fact your code may be assuming away.
Ship notice — despatched in a different unit
Ordered as 1 BX (a box of 30). Despatched as 30 EA. Both are true, and a supplier splitting a box legitimately does this.
Ship notice — partial shipment
Three ordered, one despatched, fulfillmentType="partial" with the rest to follow.
Confirmation — accepted at a different price
type="detail" carrying a UnitPrice above the one ordered, and a delivery date later than requested. Entirely routine.
Confirmation — backordered
type="backordered": accepted, but nothing is coming yet.
Invoice — one PO line, two invoice lines
A single order line invoiced across two invoice lines, as happens whenever a shipment is split.
Cart — every catalogue quirk at once
A cart built entirely from the deliberately imperfect products: free-text unit, pack size smuggled into the unit, a description past 256 characters, delimiters in the part number, non-ASCII text, an over-length auxiliary id, a sub-penny price and a punctuated UNSPSC.
Why these are generated rather than written
Both sets are generated, not written. A sample typed into a page is correct on the day it is typed and silently wrong after the next change to the code that produces the real document. A wrong example in the documentation of a conformance tool is worse than no example at all, because people trust it. These come from the builders themselves, and the test suite asserts every one of them validates against the real DTD.