Modelling a Declaration-to-GMR Workflow

Stages as states

Treat the movement as a state machine.

• declarations_created
• mrns_issued
• gmr_built
• checked_in
• embarked
• inspection_resolved ## Transitions

Each transition depends on the previous state. gmr_built cannot occur without at least one mrn_issued on the load. checked_in cannot occur without a valid GMR whose vehicle and trailer match the physical unit at the barrier.

Ownership of each transition

• Trader or intermediary produces declarations that trigger MRN issue.
• Haulier drives gmr_built (either automated via TSS or manual via GVMS).
• Carrier verifies at checked_in and notifies HMRC at embarked. You can compare that ownership model against the source in this declaration-to-GMR walkthrough.

Mutability window

The gmr_built state remains mutable until the boarding barcode scan triggers the checked_in to embarked transition. That is the update window your ops tooling should expose.

Failure surface

Most operational failures live at two transitions: MRN issued to GMR built (late or wrong-format references) and GMR built to checked in (vehicle and trailer mismatches).

Build ops workflows that surface these state changes automatically. Watch a demo.