cXML Order Integration - Change Orders

  • Updated

In Unimarket, change orders (edits to existing purchase orders) can be handled using two distinct logical configurations. The method chosen determines how integration messages are structured when they are sent to your ERP or supplier systems.

 

Comparison Summary

FeatureNew Order NumbersOrder Versions
PO ID StatusChanges with every editRemains the same
cXML Typedelete followed by newupdate
TraceabilityLinked via order-source-identifierLinked via orderID and orderVersion
Best ForERPs that cannot modify existing POsERPs that support multi-versioning

 

Option 1: Using New Order Numbers

In this configuration, every time an order is edited, the system treats the change as a cancellation of the old record and the creation of a completely new one.

 

The Integration Sequence:

  1. Original Order: Sent as type="new" with a unique ID (e.g., 1004891).

  2. Order Edit: Triggered when a user saves changes.

  3. Cancellation Message: Sent with the original ID (1004891) and type="delete".

<OrderRequest>
    <OrderRequestHeader orderDate="2023-04-06T14:33:37.680+12:00"
                        orderID="1004891"
                        orderType="regular"
                        type="delete">

 

  1. Replacement Message: Sent with a new ID (1004892) and type="new".

 <OrderRequest>
     <OrderRequestHeader orderDate="2023-04-06T14:35:19.707+12:00"
                         orderID="1004892"
                         orderType="regular"
                         type="new">

 

Key Extrinsics for Traceability:

To help your ERP link these two separate records, the replacement order contains specific metadata:

  • order-source-type: Set to EDIT_ORDER.

  • order-source-identifier: Contains the original order number (e.g., 1004891).

</Extrinsic>
<Extrinsic name="shippingNote"/>
<Extrinsic name="order-submission">ELECTRONIC</Extrinsic>
<Extrinsic name="requisition-created-date">2023-04-06T14:34:20.000+12:00</Extrinsic>
<Extrinsic name="organization">Unimarket eProcurement</Extrinsic>
<Extrinsic name="organization-unit">Information Technology</Extrinsic>
<Extrinsic name="requisition-justification"/>
<Extrinsic name="is-retrofit-order">no</Extrinsic>
<Extrinsic name="order-source-type">EDIT_ORDER</Extrinsic>
<Extrinsic name="order-source-identifier">1004891</Extrinsic>
<Extrinsic name="requisition-source-type">EDIT_ORDER</Extrinsic>

 

Option 2: Using Order Versions

In this configuration, the Purchase Order maintains its unique identifier throughout its lifecycle. Changes are tracked via an incrementing version number.

The Integration Sequence:

  1. Original Order: Sent as type="new" with a unique ID (e.g., 100024).

<OrderRequest>
        <OrderRequestHeader orderDate="2023-03-09T16:54:51.281+10:00"
                            orderID="100024"
                            orderType="regular"
                            type="new">

 

  1. Order Edit: Triggered when a user saves changes.

  2. Update Message: Sent with the same ID (100024) but the header changes to type="update".

 

XML Header Attributes:

When an update is sent, the OrderRequestHeader includes:

  • type="update": Signals a change to an existing record.

  • orderVersion="2": Indicates the revision level (starts at 2 and increases).

  • isInternalVersion="no": Confirms this is an external change intended for the supplier/ERP.

<OrderRequest>
       <OrderRequestHeader isInternalVersion="no"
                           orderDate="2023-03-09T16:55:38.672+10:00"
                           orderID="100024"
                           orderType="regular"
                           orderVersion="2"
                           type="update">