Explore the flow
One order. Four stages.
Select a stage to follow the exchange between systems and the movement of a load.
1 / 4 · WMS
Order
The WMS specifies what needs to happen: which load to move and its requested destination.
Illustrative logical flow. Interfaces and responsibilities are defined for each project.
Two authorities that must agree
A WMS manages inventory, orders and logistics tasks. A WCS coordinates physical automation execution. This is a reference division, not a universal packaging rule: products may include functions from other layers. Document the actual project boundary.
A load may be physically delivered while the WMS still awaits confirmation. Conversely, an accepted task may not have started. Treating both systems as one synchronous transaction ignores the windows where inconsistencies arise.
Task and event contracts
Identify load, origin, destination, priority and relevant constraints. Acceptance means the request was validated and recorded. Completion means the agreed physical condition was observed. Failure, cancellation and partial execution need unambiguous states.
Carry correlation identifiers throughout the flow. Distinguish invalid content from temporary unavailability. Repeating an invalid destination indefinitely blocks valid work; retry requires limits and an operational exception process.
Cancellation after commitment
A business cancellation cannot erase a carton already beyond a physical point of no return. Execution may need an exception destination or an authorized compensating move. Return an explicit rejection or alternative outcome rather than silently deleting the task.
Inventory records reflect the authorized business outcome; tracking preserves what actually happened. Manual corrections need an operator, reason, evidence and reference to the original task.
Worked scenario: lost confirmation
P7 reaches the outbound buffer and WCS records completion, but communication fails before the WMS receives the event. The pending event is sent again with the same identity. The WMS recognizes duplicates without posting inventory twice.
Compare accepted tasks, observed deliveries and business postings. Every task should finish completed, rejected, cancelled or in an explicit exception. Counting transmitted messages does not demonstrate logistics integrity.
Task contract: intention, execution and inventory
A movement task identifies the load, origin and condition that proves delivery. WMS may use orders, lines or handling units; WCS must map those objects to the identity observed by automation. An order split into three cartons is not three duplicate submissions of one task.
Specify identifier ownership, uniqueness scope and reuse rules. Distinguish business destination from physical position: a shipping door may use several buffers, but selecting a buffer does not automatically change the shipping commitment.
| Information | Reference authority | Validation before acceptance |
|---|---|---|
| Load / handling unit | WMS or agreed identification process | Recognized identity unambiguously linked to the task. |
| Business destination | WMS / orchestration | Existing destination eligible for this flow. |
| Route and intermediate position | WCS/MFC as designed | Capacity, restrictions and physical observations. |
| Inventory movement | WMS | Execution evidence and a deduplicable event identity. |
Cancelling a task that has already started
Cancellation is a state-dependent request. Decide against the physical commitment point, not merely when WMS transmitted the message. If execution starts while cancellation is in transit, accepting it without checking execution can leave inventory inconsistent with reality.
Define explicit outcomes: cancelled before execution, rejected after commitment, or an authorized compensating task linked to the original. Compensation preserves history; it does not retroactively erase a physical movement.
WMS → WCS
Request cancellation of T42 at the known version.
WCS → execution state
Check version, acknowledged command and physical commitment.
WCS → WMS
Return cancelled, rejected or pending decision with a reason.
Operations / WMS → WCS
If needed, authorize a compensating task linked to T42.
A cancellation timeout does not prove acceptance. Query the outcome before releasing incompatible work for the same load.
Partial execution and actual location
Use verifiable stages for induction, buffering and final delivery. Completing the first stage must not close a business task that requires the last. Feedback distinguishes in transit, equipment-held, delivered and exception states.
C18 leaves IN-01, reaches B2 and waits for S3. If S3 blocks, keep the task open at B2. Changing the business destination requires authorization; choosing another route to the same destination may belong to local coordination under the agreed rules.
| Observation | Supported statement | Still required |
|---|---|---|
| Departure from origin | Movement started | Identified arrival and final destination. |
| C18 identified at B2 | Intermediate stage complete | Capacity and delivery at S3. |
| Diversion command sent | Request issued | Acknowledgement and outcome evidence. |
| Load delivered to S3 | Physical execution complete | Business confirmation received/processed by WMS. |
Reconcile identities, not counters
Compare records by task and load. Equal completion counts can hide different load identities. Include version, last accepted event, known location and supporting evidence. Record age helps prioritization, but does not establish which system is correct.
The query window must cover outages and event retention. Where physical evidence is unavailable, preserve uncertainty and request operational identification. Corrections require a reason, authorized operator and links to earlier events.
| WMS | WCS / evidence | Reference response |
|---|---|---|
| Open | Delivery proven; notification pending | Replay the outcome with original identity. |
| Cancelled | Equipment already executing | Block incompatible new work and resolve the discrepancy. |
| Completed | Insufficient evidence | Investigate history and load; never invent a location. |
| Open | Load manually removed | Identify actual position and record an authorized correction. |
Acceptance criteria for WMS/WCS consistency
An acceptance test links business intention, physical route and final posting. For T42 record request, acceptance, commands, identified passage and WMS processing. Repeat both request and completion to verify coherent responses without duplicated effects.
Include cancellation racing with startup, alternative delivery and restart at an intermediate stage. Every task ends with one business outcome or an explicit owned exception. Waiting and reconciliation limits are project requirements, not universal constants.
Project verification criteria
- Distinguish transport acknowledgement, task acceptance and physical completion.
- Resend a completion already processed by the WMS.
- Test cancellation before and after physical commitment.
Examples describe engineering decisions and test scenarios. Implemented interfaces, limits and features are defined by each project’s scope.