Status mappings

3PLs report order progress in their own vocabulary (RDY2PK, PICKIP, COMPLT…). The status map translates each raw code into a human label and one of the connector's canonical statuses:

Received > Processing > Picked > Packed > Despatched, plus Hold and Cancelled.

The table is seeded automatically per instance with the provider's known codes (Sprint's ~20 codes, ShipHero's fulfilment statuses) the moment the instance is created - you normally never touch it. It stays editable per instance so you can relabel codes in your team's language or classify a new code the 3PL introduces.

What the canonical status drives:

• Despatched triggers the despatch fetch: tracking numbers, carrier and batch data are pulled and the Odoo delivery is validated.
• Hold counts the order in the dashboard's "On Hold" card - e.g. Sprint's AP_ER1 "Error - No Stock".
• Cancelled marks the 3PL order cancelled and applies the instance's If the 3PL Cancels an Order policy to the sales order.
• Everything else is progress information, shown on the sales order's 3PL tab and the Orders page.

An unmapped code is never an error: the order shows the raw code and is treated as "processing" until you classify it.

Example: Sprint introduces a new hold code AP_ER9. Orders show "AP_ER9" as their status; you add one mapping line (code AP_ER9, label "Error - Compliance Hold", canonical Hold) and from the next poll those orders count on the dashboard's On Hold card like any other hold.