A manager checks several carrier portals, copies dates and still calls to learn whether warehouse receiving can be prepared. Numerous route points do not answer the question when their meanings remain unclear. Supply management needs a minimum set of facts for resource, document and communication decisions. We propose building visibility around those decisions, adding signals when they change an action or help investigate an exception.
Start with warehouse, trade and finance decisions
A hypothetical importer expects container S-32 containing two supplier orders. The business must receive the goods, check documents and prepare information for an internal financial approval. Order numbers, container contents and the planned route are known. The example establishes neither customs status nor transfer of ownership; those questions need separate supported decisions.
The warehouse decides when to reserve staff and space. The supply manager decides whether to change sales plans or notify a customer. Finance checks whether the agreed package is available for its next action. For each decision identify the minimum fact: acceptance for carriage, a relevant route transition, handoff to the next operator, warehouse arrival or a verified receiving outcome.
GS1 EPCIS describes visibility events through objects and business context. The useful principle is to begin with meaning rather than the number of integrated signals. Using a standard does not itself establish source reliability. Check who observed the event, how it connects to S-32 and which evidence can support a disputed case.
Sources: [1]
Define an event record and its accountable source
Each event needs a stable identifier, shipment, type, occurrence time, time zone or offset, receipt time, source and evidence reference. Keep external keys separate from S-32’s internal identity. Container, booking and supplier order are different objects. If one container becomes two warehouse deliveries, preserve that relationship instead of losing the second part behind one status.
Agree the vocabulary with the partner. Completed may mean the end of their service rather than acceptance by your warehouse. Integration ownership documents the mapping; operations confirms which internal decision it supports. An unknown code should enter a clarification queue with its original message rather than automatically becoming the nearest familiar state.
Define correction handling separately. If a partner revises departure time, retain the previous version, replacement fact and available reason. Internal history should explain why the warehouse previously received a particular forecast. Expected future times need their own type and must not replace observed events merely because carrier messages use similar fields.
Communicate only what the evidence supports
For S-32, confirmed handoff to a local operator triggers a warehouse-readiness check. It does not establish site arrival. After arrival is recorded, receiving identifies a discrepancy in one order line. External status should preserve the distinction: physically arrived, verification underway and one line unresolved. A general delivered state would conceal the next task.
Show source and freshness beside important states. If the last confirmed fact exceeds an agreed age, display the gap and the next review action. The decision owner sets freshness requirements for each stage rather than a developer applying one limit to the entire route. Dock allocation and management reporting may need different update frequencies.
Finance receives verified receiving results and the necessary documents without an automatic conclusion about payment or accounting recognition. In our scenario, the discrepancy creates a separate review before internal approval. The table links events to actions and limits. It helps remove states that change no decision and exposes missing facts that block work.
↔ Scroll the table horizontally
| Confirmed fact | Action | What it does not establish |
|---|---|---|
| Accepted for carriage | Begin route monitoring | Buyer receipt |
| Handed to local operator | Check warehouse capacity | Physical warehouse arrival |
| Arrived at warehouse | Begin receiving | Every line conforms |
| Receiving verified | Pass result to the next owner | Automatic payment authority |
Specify repeat handling, delays and reconciliation
OpenAPI defines a description format for HTTP requests and responses. Your flow also needs business rules covering accepted events, repeat identification, acknowledgement meaning and retrieval of missing data. A field specification does not assign responsibility for an absent fact. Name support contacts and the operating review owner in the agreed exchange contract.
Repeating an event with the same key must not create a second warehouse task. An older packet arriving after a newer one can enrich history but cannot overwrite the current confirmation outside an authorised correction. Define retry behaviour, referral to manual review and history retrieval when the channel is unavailable. After recovery, reconcile expected events for specific shipments as well as message counts.
For the pilot, we propose daily review of S-32 and other open shipments for missing expected facts. Each task records its next check, adjusted to the operational impact. The technical team restores the channel, supply management seeks partner confirmation and the warehouse changes plans using verified information. Do not invent a missing physical event from its neighbouring states.
Sources: [2]
Accept visibility through decisions without private searches
The test set covers S-32’s normal route, repeated local-operator handoff, arrival recorded late and an unknown partner code. Separately change container contents after the plan was agreed. Verify that orders retain correct relationships and customer messages do not claim acceptance of an unverified line. Write expected warehouse, management and finance actions before execution.
From the shared record, an employee should identify the last confirmed fact, next required evidence and owner of the unresolved question. If they still need someone’s private inbox, examine how evidence reaches the shared record. Users do not all need every raw message: provide a clear result with access to provenance and technical history for investigation.
Acceptance evidence includes input messages, mappings, event versions, tasks and observed decisions. Supply management confirms operational usefulness while architecture ownership confirms recovery and relationship integrity. Start by listing the calls made about one shipment and identifying the missing fact behind each. That list should determine the initial integration scope.
Action checklist
- List warehouse, trade and finance decisions and the minimum facts supporting each.
- Agree shipment, order and container keys and the partner event vocabulary.
- Separate facts, forecasts, receipt times and corrected versions.
- Test repeats, gaps, unknown codes and actions after channel recovery.
Questions and answers
Does every shipment need a coordinate stream?
Only if it supports a defined decision or exception check. Handoff confirmation, document readiness or receiving outcomes may matter more for a particular process.
What if a partner has no API?
Use controlled imports or manual recording with the same keys, evidence and owners. Preserve checks for freshness and completeness; the transport format does not change what a fact means.