"Has it shipped?" is a question somebody answers by walking to the warehouse
The order is confirmed in one place and picked in another, so the state of the shipment has to travel back by hand. Someone types the delivered quantity onto the order, from a note, a day late. Someone else decides whether a part-shipped order can be invoiced yet, and the answer depends on a screen they cannot see. The customer calls to ask when their pallet moves, and the person who takes the call reads a number that was true this morning. Nothing here is a system failure. It is two systems each holding half of one fact, and a person hired to be the join.
What you get with order fulfillment
One order that keeps hold of its own shipments. Confirming a sales order raises the deliveries behind it through a procurement group, and those transfers stay addressable from the order along with the warehouse, the incoterm, the commitment date, the expected date and the effective one. The shipment is reachable from the order rather than reconciled against it.
A delivery status computed rather than reported. It reads the linked transfers and resolves to one of four values, not delivered, started, partially delivered, fully delivered, so a part-shipped order is distinguishable from an untouched one without opening the warehouse screens.
Delivered quantity derived, not typed. For goods it is summed from completed stock moves with returns netted off, and only from moves that are actually done. Invoice status is then computed from that quantity on every line and rolled up to the order, including a distinct status for the case where more was delivered than was billed, which is the one that otherwise surfaces at year end as work you gave away.
Ship-complete or ship-as-available as a decision on the order. Two values, on the order itself and not only on the warehouse: as soon as possible, or when all products are ready.
Fulfilment paths that do not run through your own shelves. Drop-ship is a route: the order line raises a purchase order and the vendor ships direct to the customer with no warehouse leg. Multi-step delivery, pick, pack, ship, is a setting on the warehouse rather than a customisation.
Returns as records, with the credit attached. A return is a transfer of its own with its own slip, and the refund side runs through credit notes on the ledger rather than beside it.
And the answer a service rep needs, on the screen they already have: on-hand, free-to-promise and forecast quantities on the product, plus an expected date per order line.
Where order fulfillment comes from
All of it is Odoo Community, installed and verified against a running instance, not read off a feature list. There is no module to buy, no tier to reach and no extra per-user fee, and the deployment is one you own.
Two boundaries sit inside this subject, and both are things NetSuite markets under the same heading.
Carrier integration is not included. Pick, pack and ship are core, and so is everything above. What Community does not have is a live connection to a carrier: shipping methods can be a fixed price or a rules-based rate, and there is no connector in the product for any carrier, which means no rate shopping against live prices, no carrier label printed from the transfer, and no tracking number coming back onto the order. Anything that closes this is third-party or Enterprise, and we have not verified one, so we do not name one. If your shipping desk runs on live carrier labels today, put that on the table on the first call.
There is no order-orchestration engine. Routing rules, multi-warehouse resupply and drop-ship are all real and all Community, and they are rules you configure. What does not exist is a distributed order management layer that decides on its own which of your locations should fill a given order by proximity or cost, we searched every module in the image and found none. NetSuite markets that as "intelligently determine how best to fulfill orders based on global inventory availability", and the honest answer is that Odoo gives you deterministic routing rather than an allocation engine, and that for most operations the second one is a thing they believe they have and do not use.
What is the difference between ship-complete and ship-as-available?
Ship-complete means an order is held until every line on it can be shipped together, and ship-as-available means each line goes out as soon as the stock for it exists. The trade is between the customer's handling cost and their waiting time: a single consolidated delivery is cheaper to receive and cheaper to freight, while partial shipments get the urgent line moving and generate a backorder for the rest. What makes this a real setting rather than a preference is that the right answer differs by customer and sometimes by order, a distributor rebuilding a stocked shelf usually wants one delivery, and the same distributor with a line down wants the part today. A system that treats this as a warehouse-wide policy forces one answer on everyone; a system that puts it on the order lets the person taking the order decide, which is where the knowledge actually is.
Why is delivered quantity worth deriving from stock movements rather than entering?
Because a typed delivered quantity is an assertion, and a derived one is evidence. When the figure is summed from completed warehouse movements, with returns subtracted from what went out, the quantity that gets invoiced is the quantity that physically left, and the two cannot drift apart, because there is only one of them. The version that gets typed drifts in both directions: work delivered and never billed, which surfaces at year end as revenue nobody claimed, and work billed and not delivered, which surfaces as a credit note and a difficult phone call. The related check worth insisting on is the over-delivery case, where more was shipped than was ordered on a line billed at the ordered quantity, because that is invisible in a system that only compares the invoice to the order, and it is the single most common way a business gives work away without noticing.
Does Odoo Community print carrier shipping labels?
No. Odoo Community handles the fulfilment side of shipping completely, multi-step pick, pack and ship, packages with their own types and weights, delivery slips and package labels, and it handles the commercial side of a shipping method as either a fixed price or a rate calculated from rules you define. What it does not include is an integration with a carrier: there is no connector in the product for the major parcel and freight carriers, so there is no live rate returned from the carrier at the point of sale, no carrier-format label generated from the transfer, and no tracking number written back to the order. Connectors for this exist commercially and from third parties, and they are a separate decision with a separate cost. Anyone comparing systems on fulfilment should check this specifically rather than reading "shipping" on a feature list, because the word covers two different things and only one of them is included here.
What is drop shipping, and what changes in the order flow when it is used?
Drop shipping is fulfilment in which the supplier ships directly to the end customer, so the goods never pass through the seller's warehouse. In an ERP the significant change is not the shipping arrangement, it is that the sales order line raises a purchase order to the vendor instead of a picking to a warehouse, and the receipt and delivery collapse into a single movement recorded against both documents. That is what makes it worth having as a route rather than as a manual practice: the link between what the customer bought and what the vendor was told to send is a record rather than an email, so a margin question later has an answer. It also changes what can go wrong, the exposure moves from stock accuracy to vendor performance and to the gap between the price quoted to the customer and the price actually invoiced by the supplier, neither of which the warehouse can see.