These settings decide how orders leave Odoo and what happens when reality at the warehouse disagrees with the plan. Each entry covers what the setting does, its default, and a scenario where it matters. The Order Field Mappings section at the end covers which sale-order fields feed the 3PL.

Order Behaviour

Send Orders Automatically (default on). The master switch between hands-off and reviewed despatch. On: every eligible order is pushed by the scheduler with no human step. Off: orders accumulate as "To Send" (visible on the dashboard) until a user presses Send to 3PL on the order, or runs Send Orders to 3PL from the Orders page - where they can deliberately send all eligible orders, several chosen orders, or a single order. Manual sends work even when this is off - that is the point of the switch. Example: a business that gift-wraps some orders keeps this off, reviews each morning's orders, and sends everything except the ones needing wrapping; those are sent individually after preparation.

Require Delivery Method (default on). An order without a delivery method (shipping method) is not eligible for pushing - it will not be sent automatically or offered in the manual order picker. Prevents orders reaching the 3PL without the carrier/service information the warehouse needs to book a shipment. Turn off only if your 3PL chooses the carrier itself. Example scenario this prevents: a webshop order imports without a shipping method; with the gate on it sits visibly in "To Send" until someone fixes it, instead of arriving at the warehouse as an un-shippable order.

Send to 3PL if Out of Stock (default on). On: orders are sent regardless of Odoo's on-hand stock - correct when the 3PL's stock is the real stock (the usual case: goods live at the warehouse, not with you). Off: an order is held back until the mapped Odoo warehouse shows enough on-hand quantity for every line; the hold and its reason appear on the sales order's 3PL Connector tab and the order stays in "To Send". Example: if you run inventory sync with 3PL-as-master overnight, Odoo's stock mirrors the warehouse - turning this off then means "don't send orders the warehouse can't fill", and backordered items wait in Odoo instead of going on hold at the 3PL.

Auto-create Delivery Methods (default off). Applies to inbound despatch confirmations. When the 3PL ships with a carrier/service that has no mapping: off, the despatch fails with a clear "unmapped carrier" error in the Sync Log (retryable after you add the mapping); on, the connector creates the Odoo delivery method and the mapping automatically and carries on. Trade-off: on keeps goods flowing unattended but can quietly grow your delivery-method list; off keeps the carrier list curated at the cost of an occasional manual fix.

Shipping Product (default empty). The service product placed on every delivery method the connector creates - by despatch auto-creation or by a carrier fetch. One shipping product serves any number of delivery methods. Left empty, the connector uses Odoo's shared default delivery product; on multi-company databases set a per-company product here, because the shared default cannot be restricted to one company once it has been used in another company's orders.

Order Reference Sent (default Odoo order number). Which reference the 3PL receives as the order number - it is also the reference printed on despatch paperwork and used to match returns back to the order. Customer reference, else order number suits sales-channel setups where the shop's own number should appear on the parcel; orders without a customer reference fall back to the Odoo number. The default is the previous behaviour.

Products Use Batch/Lot Tracking (default on). Tells the connector whether your products are configured with Odoo's lots/serial tracking. On: batch numbers the 3PL reports become real Odoo lots on despatches, receipts, returns and inventory syncs. Off: batch data from the 3PL is kept for information - it stays visible in the Sync Log and on reports as a warning-level note - but stock is booked without lots, no batch records are ever created in Odoo, and inventory syncs reconcile the total quantity per product instead of per batch. Turn this off if you deliberately run Odoo without lot tracking; the warehouse can keep batch-managing on their side without forcing that model onto your database. Example: your 3PL tracks expiry batches internally but your Odoo products are plain. A despatch of 4 units across two of their batches books as one clean 4-unit move; the batch split is preserved in the log entry for traceability, and nothing batch-shaped pollutes your inventory.

If a Despatch Reports an Unknown Batch (default Create the batch automatically; shown when lot tracking is on). What happens when the 3PL despatches from a batch number that does not exist in Odoo. Create: the batch is created on the fly with its reported expiry - the normal choice for 3PL-managed stock, where batches are born at the warehouse. Fail - handle manually: the despatch errors in the Sync Log naming the exact SKU and batch, no stock moves, and a person either creates the batch (or has the 3PL correct their data) and presses Retry. Choose Fail where batch numbers are contractually controlled - a typo at the warehouse then becomes a visible, blocking question instead of a phantom batch in your books. Returns always create reported batches regardless - goods arriving define new stock. Example: the 3PL despatches from "N-M33916/2S142" - a mistyped batch. With Fail set, the despatch waits in the log; you spot the typo, the 3PL fixes their record, the retry ships cleanly against the real batch.

Allow Un-batched Despatches (default off; only shown for providers with batch support and when lot tracking is on). Governs what happens when the 3PL despatches a lot-tracked product without telling us the batch numbers. Off: the despatch fails hard - nothing is booked until the 3PL supplies batch data (the safe default for expiry-controlled goods). On: if Odoo holds enough un-batched stock of that product at the location, exactly the shipped quantity is relabelled to a special lot named UNBATCHED and shipped, and the event is logged as a warning rather than a failure; if there is not enough un-batched stock, it still fails hard. Serial-tracked products always fail hard. Later, when an inventory sync reports real batch detail for a product, its UNBATCHED bucket is cleared automatically so stock is never double counted. Example: the 3PL's despatch feed omits batches for one SKU for a week. With the fallback on, orders keep shipping from the un-batched pool and every despatch carries a visible warning; when the 3PL fixes their data, the next inventory sync rebuilds true batch-level stock.

Un-batched Lot Name (default UNBATCHED; shown when the fallback above is on). The name of the per-product batch that absorbs un-batched despatches. Change it only if UNBATCHED clashes with a real batch naming scheme at your business.

If the 3PL Ships More Than Ordered (default Reject the despatch - handle manually). What happens when the warehouse reports despatching more units of a line than the order asked for. Reject (the default, and the previous behaviour): the despatch fails to the Sync Log for a person to review - a manager can still force it through. Trim: the ordered quantity is delivered and the reported surplus is adjusted out of stock automatically, with the detail noted on the order.

If the 3PL Ships Less Than Ordered (default Create a backorder for the remainder). What happens to the undelivered remainder when the 3PL despatches fewer units than ordered. Backorder (the default, and the previous behaviour): the remainder becomes a backorder delivery that a later despatch completes. Cancel the remainder: the shipped quantity closes the line - choose this where the 3PL never ships a second parcel for the same order.

IOSS Registered (default off) and IOSS Registration Number. Tick if the business holds an Import One-Stop-Shop VAT registration, then enter the number (IM followed by 10 digits - required once ticked). On order push, the IOSS number is passed to providers that support it (currently the 3PL) only for destinations outside the UK for IOSS purposes. Great Britain, Northern Ireland, the Channel Islands (Jersey, Guernsey) and the Isle of Man all count as UK, so orders to those destinations never carry the number - this matters because a naive "not GB" check would wrongly attach IOSS to a Jersey order. Example: an order to Berlin is pushed with IOSSNumber; the same basket shipped to St Helier (Jersey) is pushed without it.

IOSS Home Territories (default GB,XI,JE,GG,IM; shown when IOSS Registered is on). The comma-separated country codes that count as domestic for IOSS - orders to these destinations never carry the IOSS number. The default is exactly the UK list described above, so nothing changes unless you edit it; a seller registered outside the UK replaces the list with their own home territories.

If the 3PL Cancels an Order (default Flag for review). What happens to the Odoo sales order when a status poll discovers the 3PL cancelled the order on their side. Flag for review: the order stays confirmed, gets a chatter note and a to-do activity for the salesperson - right when you might re-route the order to another warehouse. Cancel the Odoo order automatically: Odoo mirrors the 3PL and cancels the sales order and its delivery. If Odoo Cancels an Order (default Cancel in Odoo and note a failed 3PL cancellation). The opposite direction. Cancelling an Odoo order that is already at the 3PL always attempts the cancellation there too; this policy decides what happens when the 3PL rejects it - usually because the parcel is already being picked. Cancel and note (the default, and the previous behaviour): the Odoo order is cancelled anyway and the refusal lands in its chatter, so you know to handle the parcel that will still ship (it usually comes back as a return). Block the Odoo cancellation: the sales order stays confirmed until the situation at the warehouse is resolved - choose this where Odoo must never disagree with a parcel that is actually leaving.

Order Field Mappings

Which sale-order fields feed the 3PL. The defaults are the field names used by the legacy integration, so migrated databases work unchanged; on a database where a named field does not exist it is simply ignored.

Requested Method Field (default x_studio_rdelivery_method). Technical name of the sale-order field carrying the customer's requested delivery method (a text, selection or relational field). It feeds the Requested Methods mapping and, through it, the service sent to the 3PL. Clear it if your orders only ever use Odoo's native Delivery Method.

Delivery Instructions Field (default x_studio_order_delivery_instructions). Technical name of the sale-order field with delivery instructions for the carrier ("leave in the porch"). Sent to providers that support special instructions.

Packing Note Field (default x_studio_order_detail_information). Technical name of the sale-order field with a note for the warehouse - packing or detail information the pickers should see.

Contact Name Split (default First word / rest). How a contact's single Odoo name becomes first name / last name for providers whose addresses require both. First word / rest (the default), All but last word / last word, or Whole name as first name.