cXML ConfirmationRequest

Accusé de commande métier. Envoyé par le fournisseur en réponse à un OrderRequest, il indique pour chaque ligne si la commande est acceptée, modifiée, en backorder, rejetée ou en attente. Équivalent fonctionnel d'un ORDRSP EDIFACT.

Objet de la transaction

Le ConfirmationRequest existe parce que le fait qu'un fournisseur accepte ou non une commande n'est pas instantané — il y a vérification de stock, contrôle prix, contrôle crédit, etc. Le HTTP 200 sur OrderRequest signifie seulement "j'ai reçu le document" ; l'accord métier vient dans cette transaction.

L'attribut type de ConfirmationHeader est #REQUIRED et prend huit valeurs : accept (toute la commande OK), allDetail, detail (changements ligne par ligne), backordered (toute la commande en backorder), except (acceptée avec exceptions), reject (rejet total), requestToPay, replace.

Structure XML

Le DTD : ConfirmationRequest (ConfirmationHeader, OrderReference, (OrderStatusRequestReference | OrderStatusRequestIDInfo)*, ConfirmationItem*). Le OrderReference est obligatoire et porte un DocumentReference qui pointe vers le payloadID de l'OrderRequest d'origine.

ConfirmationHeader

Le contenu : ConfirmationHeader (DocumentReference?, Total?, Shipping?, Tax?, Contact*, Hazard*, Comments*, IdReference*, Extrinsic*). Aucun élément n'est obligatoire au contenu ; le minimum c'est les attributs type et noticeDate (le DTD déclare noticeDate en #REQUIRED).

ConfirmationItem

Le contenu : ConfirmationItem (UnitOfMeasure, Contact*, Hazard*, ConfirmationStatus+). Donc une unité de mesure obligatoire et au moins un ConfirmationStatus. Les attributs quantity et lineNumber sont #REQUIRED.

ConfirmationStatus

Le contenu : ConfirmationStatus (UnitOfMeasure, (ItemIn | (UnitPrice?, Tax?, Shipping?)), SupplierBatchID?, ScheduleLineReference?, ComponentConsumptionDetails*, Comments*, Extrinsic*). Les attributs quantity et type sont #REQUIRED. Le type prend sept valeurs : accept, allDetail, detail, backordered, reject, unknown, requestToPay. La somme des quantity des ConfirmationStatus d'un même ConfirmationItem doit égaler la quantity du ConfirmationItem — règle énoncée explicitement dans le DTD.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cXML SYSTEM "http://xml.cxml.org/schemas/cXML/1.2.069/cXML.dtd">
<cXML payloadID="260513.180000.conf@supplier.example"
      timestamp="2026-05-13T18:00:00+02:00"
      version="1.2.069">
  <Header>
    <From>
      <Credential domain="DUNS"><Identity>987654321</Identity></Credential>
    </From>
    <To>
      <Credential domain="DUNS"><Identity>123456789</Identity></Credential>
    </To>
    <Sender>
      <Credential domain="DUNS">
        <Identity>987654321</Identity>
        <SharedSecret>shared-secret-here</SharedSecret>
      </Credential>
      <UserAgent>supplier-erp/2.1</UserAgent>
    </Sender>
  </Header>
  <Request>
    <ConfirmationRequest>
      <ConfirmationHeader confirmID="CONF-2026-00123"
                          operation="new"
                          type="detail"
                          noticeDate="2026-05-13T18:00:00+02:00">
        <Total>
          <Money currency="EUR">129.97</Money>
        </Total>
        <Comments xml:lang="fr">Article 1 disponible sous 3 jours, article 2 en backorder.</Comments>
      </ConfirmationHeader>
      <OrderReference orderID="PO-2026-00789"
                      orderDate="2026-05-13T16:00:00+02:00">
        <DocumentReference payloadID="260513.160000.order@buyer.example"/>
      </OrderReference>
      <ConfirmationItem quantity="3" lineNumber="1">
        <UnitOfMeasure>EA</UnitOfMeasure>
        <ConfirmationStatus quantity="3"
                            type="detail"
                            shipmentDate="2026-05-16T08:00:00+02:00"
                            deliveryDate="2026-05-18T10:00:00+02:00">
          <UnitOfMeasure>EA</UnitOfMeasure>
          <UnitPrice><Money currency="EUR">29.99</Money></UnitPrice>
        </ConfirmationStatus>
      </ConfirmationItem>
      <ConfirmationItem quantity="2" lineNumber="2">
        <UnitOfMeasure>EA</UnitOfMeasure>
        <ConfirmationStatus quantity="2" type="backordered">
          <UnitOfMeasure>EA</UnitOfMeasure>
        </ConfirmationStatus>
      </ConfirmationItem>
    </ConfirmationRequest>
  </Request>
</cXML>

Requis vs optionnel

• ConfirmationHeader — attributs : type, noticeDate en #REQUIRED ; confirmID, operation, invoiceID, incoTerms, version en #IMPLIED.
• OrderReference — cardinalité 1 (obligatoire) ; contient un DocumentReference obligatoire avec un payloadID.
• ConfirmationItem — répétable 0..n. Pour un type "reject", le DTD interdit la présence d'items.
• ConfirmationStatus — au moins un par ConfirmationItem. quantity et type #REQUIRED.

Patterns courants

Confirmation partielle : un même ConfirmationItem peut porter plusieurs ConfirmationStatus de types différents — par exemple "2 unités acceptées, 3 unités en backorder" pour une ligne de 5. La règle de somme garantit qu'aucune quantité n'est perdue.

Mise à jour d'un accusé : réutiliser le même confirmID avec operation="update". Le DTD impose alors un DocumentReference pointant l'accusé précédent. Une nouvelle version remplace intégralement la précédente.

Pour les commandes scheduling agreement : utiliser ScheduleLineReference dans le ConfirmationStatus pour référencer une ligne de planning précise.

Documentation

• Fulfill.dtd — version courante — chercher ELEMENT ConfirmationRequest, ConfirmationHeader, ConfirmationItem, ConfirmationStatus.
• cXML Reference Guide (PDF) — chapitre Order Confirmation, matrices d'autorisation type ↔ statut.
• OrderRequest — la transaction référencée par OrderReference.