At year end you find the delivery nobody invoiced, and the order that was quietly edited after it shipped
The order is confirmed in one system and shipped in another, and by the time the books are being tidied the two have drifted. A line went out in full and was billed for less, because more was delivered than was ordered and nothing flagged it. A confirmed order was edited after the fact, a price nudged, a quantity changed, and there is no clean record of when it was locked or by whom. A quarter's worth of stale quotations sits open, each one a line someone has to decide about. None of this is a warehouse problem. It is the order record not holding its own commercial state, so the state gets reconstructed after the fact, which is the most expensive time to find it.
What you get with order management
One confirmed order that carries its own commercial state. A sales order in Odoo, once confirmed, holds the deliveries it raised and an invoice status computed from them, so what shipped and what is billable are read off the same record rather than pieced together from two systems.
A billable position derived, not asserted. Delivered quantity for goods is summed from completed stock moves with returns netted off, not typed onto the line, and invoice status is computed from that quantity, on every line and rolled up to the order, taking four values: nothing to invoice, to invoice, fully invoiced, and upselling.
The delivery you gave away, surfaced. That fourth value, upselling, is the case the accounts otherwise miss: a line billed on the ordered quantity where more was actually delivered gets its own status instead of being folded into "fully invoiced", so over-delivery is visible while it can still be billed rather than discovered at year end.
A confirmed order you can freeze. Independently of its state, an order carries a lock flag, so it can be frozen against further edits after confirmation without inventing an extra lifecycle stage to reason about, the confirmation and the freeze are two facts on one record.
Stale quotations cleared in one action. Cancellation is a mediated action, not a raw state write: one wizard cancels a single order and a second cancels a whole selection of quotations at once, so a quarter of dead quotes is closed off in one pass.
A queryable order history and a way in for structured orders. Community ships a sales analysis model you can report against, and an inbound EDI order format (UBL BIS Ordering 3.0) for receiving structured purchase orders into the same order record.
Where order management comes from
All of it is Odoo Community, verified against a live instance rather than read off a feature list. There is no module to buy, no tier to reach and no extra per-user fee, it runs on the deployment you own. That is the whole provenance answer for this page.
Two things NetSuite markets under order management, and a third it splits across two pages, do not belong here. There is no omnichannel or multichannel orchestration engine, orders from more than one source can land in one ledger, but the allocation-and-routing engine NetSuite sells is not standard. There are no promotions or coupons in the base order flow, pricelists give rule-based and customer- or currency-specific pricing, and campaign-style promotions are a separate matter. And the physical shipment side, carrier labels, drop-ship, multi-step pick-pack-ship, lives on /features/order-fulfillment, not here.
What does it mean for a sales order to carry its own invoice status?
It means the order record itself computes and holds how much of it is billable, rather than that being worked out separately at invoicing time. In Odoo the invoice status lives on both the order and each order line and takes one of four values, nothing to invoice, to invoice, fully invoiced, or an upselling status for over-delivery, and the line-level values roll up to a single status on the order. Because the status is computed from what was actually delivered rather than asserted, the question "what can we bill on this order" has an answer on the order at any moment, and the answer moves as deliveries complete. The alternative, where billability is decided by a person reading a delivery note against an order in another screen, is where a part-shipped order either gets invoiced too early or waits longer than it should, and where the two most common errors, billing for what has not shipped, and shipping what never gets billed, come from.
What is an over-delivery (upselling) status on a sales order, and why does it matter for billing?
An upselling status flags a specific and expensive situation: a line that is billed on the quantity ordered, where the quantity actually delivered came out higher than the quantity ordered. It exists as its own status, separate from "fully invoiced", because otherwise that line looks finished. It was ordered, it was billed for what was ordered, the invoice matches the order, and the extra that went out the door is invisible to any check that compares the invoice to the order alone. Giving it a distinct status means the over-delivery surfaces while it can still be billed or recovered, rather than turning up at a year-end margin review as work the business gave away without deciding to. It matters most for businesses that bill on ordered quantities and fulfil from stock, because that is exactly the combination in which delivered and billed quantities can diverge without anything in the invoice looking wrong.
Should a confirmed sales order still be editable, and what does locking one change?
A confirmed order usually should not stay freely editable, because edits made after confirmation are the ones that quietly break the link between what was agreed, what shipped and what was billed. The difficulty is that a business still needs some confirmed orders to be adjustable, a genuine change to a live order, so the answer is not to make confirmation permanent but to make the freeze a separate, deliberate act. In Odoo that is a lock flag that sits alongside the order's state: an order can be confirmed and then locked, and locking it is an explicit action rather than an automatic consequence of confirmation, and it does not add another lifecycle stage to reason about. The value of doing it this way is auditability, a locked order is one someone decided to freeze, at a point you can identify, rather than one that happened to stop being touched.
Does Odoo Community handle sales promotions and coupons on an order?
Not in the base order flow. What Odoo Community does handle on the pricing side is pricelists: multiple price levels, and customer- or currency-specific pricing, applied to the order as rules rather than typed in. What it does not include as standard is campaign-style promotions and coupon codes, the "buy X get Y", the percentage-off code, the time-boxed offer across channels. NetSuite markets both together: "Establish multiple price levels and customer- and currency-specific pricing. Easily create promotions for all sales channels." The first half of that sentence describes what pricelists do; the second half, the promotions engine, is a separate capability and is not part of the order management described here. A business that runs on coupon and promotion mechanics should raise it specifically rather than read it into "pricing", because the two are sold as one line and are not one capability.