ERP marks an order fulfilled, WMS marks it dispatched and TMS reports partial delivery. These can all correctly describe different objects until an interface compresses them into one word. The architect and operations owner need to decide who owns each fact and how those facts produce a useful customer-facing state. Our proposed model assigns ownership to events and makes the overall status an explainable result of rules.
Separate objects before assigning responsibility
Hypothetical order O-41 contains ten pallets and is fulfilled through two shipments: S-1 with six pallets and S-2 with four. WMS has dispatched both, but the consignee has accepted only S-1. TMS should show the order as partially delivered even if the first trip is complete. ERP may already hold a dispatch document, which does not establish receipt of the second shipment.
Map the customer order, line, warehouse shipment, transport task, stop, receipt evidence and settlement. Define a stable key and relationships for each. A trip can contain several orders, and an order can require several trips. A trip number is therefore unsuitable as a universal integration key and should not replace the originating order identifier.
GS1 EPCIS defines a visibility event model and business-step context. The useful principle here is to describe what happened to a specific object. The ownership rules below are our proposed operating method: the standard does not assign ERP, WMS or TMS ownership of every possible state in your organisation.
Sources: [1]
Assign the source of each fact and its correction path
The warehouse owner confirms dispatch and quantity through WMS, transport operations confirms delivery at a specific stop through TMS, and finance confirms posted settlement through ERP. A defined commercial process owns the customer promise. If that promise resides in ERP, changes originate there; a new arrival forecast in TMS should not overwrite the agreed delivery window.
Give every event an identifier, type, object, version, occurrence time, record time and source. A correction references the earlier fact and explains why it changed. Preserve the history of an incorrect confirmation: otherwise it becomes difficult to explain why finance or a customer already received a message. Authority to correct a fact differs from permission to read it or change its display.
A named service or system calculates the overall state using a published rule. In this example, O-41 is delivered only when both shipments have accepted delivery results covering their pallets. If the second shipment returns, the rule displays a separate outcome with a return. It must not describe the return as successful delivery merely to close the order.
Specify the exchange contract and repeat handling
OpenAPI provides a format for describing HTTP APIs. Your exchange contract also needs agreed status meanings, supported versions and responses to business errors. Technical acknowledgement of a message does not establish completion of an operation. If an event has entered a queue, distinguish that from application to the order and from successful data validation.
A repeated event with the same identifier must not create another shipment. An older version must not erase a newer one, and an unknown object enters a review queue with an owner. Delivery retries need limits, observable state and a recovery procedure. A persistent failure requires an integration operator’s decision; silent indefinite retries conceal a gap between systems.
Choose acceptable display latency for each scenario rather than a single universal limit. A dispatcher needs current readiness information before departure, while financial reconciliation may follow a different cycle. When data exceeds the agreed age, show the last confirmation time and its implications for the decision. Do not hide a missing fresh fact behind a green overall status.
↔ Scroll the table horizontally
| Fact | Owner in this model | Still unconfirmed |
|---|---|---|
| Cargo readiness | WMS and warehouse | Vehicle departure |
| Dispatch | WMS and warehouse | Consignee receipt |
| Delivery outcome | TMS and transport operations | Financial closure |
| Posted settlement | ERP and finance | Absence of an open claim |
Sources: [2]
Accept the model through contradictions and recovery
Periodic reconciliation compares expected business objects as well as message counts. O-41 should have two shipments totalling ten pallets and their delivery outcomes. If S-2 is missing in TMS, the integration team receives a specific gap. If the record exists with a different quantity, route the discrepancy to the source owner rather than arbitrarily changing every database.
During acceptance, deliver events out of order, repeat one and delay confirmation for S-2. Then correct a quantity through the authorised procedure. Check the aggregate state, customer messages and financial records after each step. Retain the aggregation rule version, input events, computed result and contradiction decision. These records explain the status at a particular moment.
Every hour, calculate events received in the previous 24 hours that remain unapplied as a share of all events received in that period; show no data when the denominator is zero. Age of the oldest gap equals current time minus its first detection in reconciliation; recalculate every minute. Group manual corrections by reason for the completed day. Use integration logs and reconciliation records, with the integration support lead accountable. This is a proposed cadence to agree with operations. Action thresholds depend on the consequence of a gap. Start with one disputed status and identify who can confirm its source facts.
Action checklist
- Map the order, shipments, trips, stops and acceptance evidence.
- Assign each fact an owner and a versioned correction procedure.
- Specify repeats, delays, unknown objects and the manual review queue.
- Reconcile business objects and reproduce the overall state from retained events.
Questions and answers
Is one master system needed for every status?
One agreed presentation rule is needed, while facts may belong to different systems. Assign ownership of the aggregate calculation and keep the origin of each component accessible.
Can manual status correction be allowed?
Yes, as a controlled action with a reason, authority and history. It should correct a source fact or explicitly mark an exception rather than introduce an invisible competing record.