A parcel can appear dispatched in one system and uncollected in another when warehouse and transport milestones have different meanings. Warehouse dispatch, carrier handover and customer delivery are separate physical facts. A scan may report one of them without proving the others. Define each milestone, who confirms it, and how an exception such as a missing parcel is represented.
What good engineering looks like
What operational fact does each milestone represent, and who confirms it? Answer this for a named workflow and an accountable team. Identify the information needed at the moment of decision, the system that can settle a dispute, and the route for correcting dependent copies. The technical design should make those business rules visible to the people who operate and support the handoff.
-
Agree on dispatch, handover, in-transit, delivery and exception definitions.
-
Carry identifiers and timestamps across both systems.
-
Reconcile missing or conflicting signals with a named owner.
-
A named owner for a rejected, delayed or repeated item.
-
Evidence that the receiving system applied the intended business state.
A practical starting point
-
Choose one real case and write down its trigger, expected outcome and responsible team.
-
Run a case with a scan delayed until after the vehicle leaves and another with a failed receipt.
-
Check how the order view presents uncertainty, whether duplicate scans are harmless, and which team owns reconciliation. The model should support a real exception, not just a perfect journey.
-
Record what the test exposed, who will resolve each open question and how the fix will be checked.
Keep the first design small enough to review with the people who run the process. Test an exception alongside the normal case. A successful transport test shows that data moved; it does not by itself prove that the receiving team can make the right decision or recover from a partial failure.
The decision to make
A scan is evidence of a recorded event, not proof that every physical handoff happened as planned. Decide what level of timing, traceability and recovery this workflow actually needs. Document assumptions that remain untested and revisit the choice when a partner, process or business rule changes. The point is a dependable operating decision, not simply a working interface.
Explore Algoza's related services: https://algoza.co.za/services/supply-chain-software-development