How a sales order travels from Odoo to the warehouse and back: what makes it eligible, the three ways to send it, what the statuses mean, what a despatch confirmation does to your stock, holds, and cancellation in both directions.

The 3PL order record

When an order is sent, the connector creates a 3PL Order (visible under Operations > Orders and on the sales order's smart button) linking the sales order to the instance. It carries the 3PL's own reference (the 3PL's AWB, the 3PL's order id), the raw and translated status, tracking, timestamps and any hold reason. One sales order can have bindings on more than one instance over its life (e.g. after a re-route), each with its own history.

The sales order itself gains a 3PL Connector tab showing the same information where salespeople actually look, and the order's chatter receives a note for every meaningful event: sent, status changes, despatched with tracking, cancellation, returns.

Eligibility - what "To Send" means

An order is eligible for an instance when all of these hold:

1. It is confirmed (a sales order, not a quotation).
2. Its warehouse is mapped on the instance.
3. It belongs to the same company as the instance.
4. It has a delivery method - unless Require Delivery Method is off.
5. It has not already been sent to this instance (orders in a failed state count as still-to-send so they retry).

The dashboard's To Send card counts exactly this set, so the number on the card is always "orders that would go if a push ran right now".

Three ways an order gets sent

1. Automatically. With Send Orders Automatically on, the scheduler pushes every eligible order at the configured interval, oldest first.
2. From the sales order. The Send to 3PL button (visible to Ops and Admins whenever the order is eligible) sends that one order immediately - it works even when automatic sending is off, and also from the order list via the Send to 3PL bulk action.
3. From the Orders page. Send Orders to 3PL opens the run popup: pick the instance, then choose scope - all eligible orders or specific orders (pick one or many; only eligible, unsent orders are offered). Deliberate manual sends bypass the automatic-sending switch: a person explicitly asked.

Whatever the path, if Send to 3PL if Out of Stock is off the stock gate is checked at send time and a shortfall holds the order back with the reason on its 3PL tab.

What actually goes to the 3PL: consignee name and address, phone and email, your order reference (this becomes the 3PL's customer reference - it is also how returns find their way back to the order), each storable line's SKU, quantity and unit price, currency, the mapped warehouse code, the mapped carrier service, expected delivery date if set, customs data (HS code, country of origin) where products carry it, and the IOSS number when the destination rules call for it. Every product line must have an Internal Reference (SKU) - a missing SKU fails the push with a clear error before anything is sent.

Routing orders between several 3PLs

With one 3PL instance nothing changes - skip this section. With more than one, Configuration > Routing Rules decides which 3PL fulfils what. Routing requires the 3PL Connector: Order Routing companion app (purchased separately); the Routing Rules menu appears when it is installed. Without the app any rules are stored but inert, and every order goes wholly to its warehouse's instance. Rules are tried top to bottom, per order line, and the first match wins. A rule can match on delivery country, delivery method, product category (children included), product tag, or SKU prefix - conditions left empty always match, and the rule names the 3PL instance that takes the line.

• Whole-order routing: when every line of an order matches rules pointing at the same instance, that instance simply takes the order.
• Order splitting: when lines match rules pointing at different instances, the order is split. Each 3PL receives a 3PL order scoped to its lines only (the 3PL order record shows a "Routed Lines" section and a Split flag), pushes and despatches independently, and the Odoo delivery completes progressively: the first despatch validates its lines and leaves the rest as a backorder for the other 3PL's despatch.
• Unrouted lines stay with the instance that would have taken the order anyway (the first live instance mapping the order's warehouse), so partial rule sets are safe.
• With no rules at all, behaviour is exactly as before routing existed.

One rule of thumb: never write rules that split the same SKU across two instances on one order - despatch confirmations are reconciled by SKU, so each SKU must belong to exactly one 3PL per order.