Introduction

In logistics integrations where orders are fulfilled by an external warehouse (WMS), the warehouse returns feedback on the orders it receives using EDI messages. The Data Hub converts and imports two of these messages so that the feedback is visible directly on the order, line by line:

• ORDRSP — the warehouse order response (acknowledgement). It tells you whether each order line was accepted by the warehouse or blocked.
• DESADV — the warehouse despatch advice. It tells you the quantity the warehouse actually shipped for each order line.

Both flows are inbound and file-based: the WMS deposits its files, the Data Hub converts them and updates the matching order lines. No additional API call is required on your side to trigger the update.

📘

Note: These flows are optional. Orders that are not covered by an ORDRSP or DESADV flow keep their existing behaviour — nothing changes for them.

Key concepts

✅

Tip: The two flows answer two different questions and are complementary. ORDRSP answers "did the warehouse accept my line?" — early in the lifecycle. DESADV answers "what did the warehouse actually ship?" — at despatch time.

Typical workflow

flowchart LR
%% Styles (Readme)
classDef create   fill:#e8f1ff,stroke:#2f6feb,stroke-width:2px,color:#0b3d91;
classDef read     fill:#ede9fe,stroke:#7c3aed,stroke-width:2px,color:#1e1b4b;
classDef update   fill:#e0f7fa,stroke:#06b6d4,stroke-width:2px,color:#0c4a6e;
classDef add      fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
classDef remove   fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;
classDef decision fill:#fff4e5,stroke:#f59e0b,stroke-width:2px,color:#7a3e00;
classDef place    fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d;
classDef sys      fill:#f2f4f7,stroke:#475569,stroke-width:2px,color:#111827;
classDef ok       fill:#ecfdf5,stroke:#10b981,stroke-width:2px,color:#064e3b;
classDef stop     fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#7f1d1d;

  A[🧾 Order sent<br>to the warehouse] --> B[📦 WMS deposits<br>ORDRSP file]
  B --> C[🔗 Data Hub converts<br>and imports the file]
  C --> D{Line accepted<br>by the warehouse}
  D -->|Accepted| E[📦 WMS deposits<br>DESADV file at despatch]
  D -->|Blocked| F[⚠️ Line flagged<br>for investigation]
  E --> G[🔗 Data Hub converts<br>and imports the file]
  G --> H[➕ Shipped quantity<br>set on the order line]
  H --> I{Shipped quantity<br>equals ordered quantity}
  I -->|Yes| J[✅ Line fully shipped]
  I -->|No| K[⚠️ Shipping gap<br>visible on the line]

  style A rx:8,ry:8
  style B rx:8,ry:8
  style C rx:8,ry:8
  style D rx:8,ry:8
  style E rx:8,ry:8
  style F rx:8,ry:8
  style G rx:8,ry:8
  style H rx:8,ry:8
  style I rx:8,ry:8
  style J rx:8,ry:8
  style K rx:8,ry:8

  class A sys
  class B sys
  class C update
  class D decision
  class E sys
  class F stop
  class G update
  class H add
  class I decision
  class J place
  class K stop

Step by step:

1. The order is transmitted to the warehouse. This is done by your existing order export flow — it is unchanged by these two imports.
2. The WMS deposits an ORDRSP file on the agreed drop location, acknowledging the order it received.
3. The Data Hub converts and imports the ORDRSP. Each order line covered by the file is updated with its WMS integration status.
4. You review blocked lines immediately, without waiting for the delivery. Only the lines in anomaly need to be handled — accepted lines continue their normal lifecycle.
5. The WMS deposits a DESADV file when it despatches the goods.
6. The Data Hub converts and imports the DESADV. Each order line covered by the file is enriched with the quantity actually shipped.
7. You compare ordered and shipped quantities line by line to detect any gap between the order and the despatch.

Monitoring the imports

ORDRSP and DESADV imports are regular Data Hub import jobs. They are monitored exactly like any other import:

• Execution history — retrieve the executions of the job with GET /v2/jobs/{jobId}/executions (operationId: ADM-JOB-550, dj-client: OPERATOR), or browse them from the Data Hub section of the Back-Office. Each execution exposes its status and a unique execution ID.
• Error reports — lines that cannot be integrated are reported per line, with a code and a message, in the execution's error report.
• Error codes — see the dedicated page: Error / Warning codes.

For the general behaviour of import jobs (execution modes, scheduling, concurrent executions, stopping an execution), see Job Configuration - Overview.

✅

Tip: When reporting an issue on a warehouse feedback import, always include the execution ID of the failing execution. It removes any ambiguity when several files are processed on the same day.

Best practices

• Match on a stable line identifier. The warehouse feedback must be attachable to an existing order line. Make sure the identifier your WMS returns in its ORDRSP and DESADV files is the one agreed during the integration setup, and that it is stable over the order lifetime.
• Import ORDRSP before DESADV. The acknowledgement describes what the warehouse committed to; the despatch advice describes what it shipped. Processing them in that order keeps the line history coherent.
• Do not rely on the absence of feedback. A line with no WMS integration status simply means no ORDRSP has been imported for it yet — it does not mean the line was rejected.
• Treat blocked lines as an operational alert. The value of the ORDRSP flow is early detection: monitor blocked lines continuously rather than at delivery time.
• Reconcile quantities systematically. A shipped quantity lower than the ordered quantity is a business event (partial despatch, stock shortage) that usually requires a follow-up with the warehouse or the customer.
• Keep the drop location clean. Use a dedicated directory per message type (ORDRSP, DESADV) so that a malformed file of one type never blocks the other flow.

Common mistakes

Example scenarios

Scenario 1 — Order line blocked by the warehouse

An order of two lines is transmitted to the warehouse. The WMS deposits an ORDRSP acknowledging the first line and rejecting the second one (unknown item on its side).

After the Data Hub import:

• Line 1 is flagged as taken in charge by the warehouse and continues its normal lifecycle.
• Line 2 is flagged as blocked. The buyer can immediately contact the warehouse instead of discovering the problem at delivery.

No DESADV is expected for line 2 until the blocking cause is resolved.

Scenario 2 — Partial despatch detected through DESADV

An order line is placed for 100 units. The warehouse only has 80 in stock and despatches them, reporting a shipped quantity of 80 in its DESADV.

After the Data Hub import:

• The order line carries an ordered quantity of 100 and a shipped quantity of 80.
• The gap of 20 units is visible directly on the line, without any manual reconciliation.

The buyer can then decide whether to wait for a complementary despatch or to handle the shortage commercially.

Scenario 3 — Order without EDI feedback

An order is fulfilled by a supplier that is not connected through an EDI warehouse flow. No ORDRSP or DESADV file is ever deposited for it.

The order behaves exactly as before: no WMS integration status and no shipped quantity are set on its lines, and the existing order lifecycle is unaffected.