Odoo 19's Dropship-Kit Cost Fix: Margin Needs a Component Trail

A kit is one customer-facing line and several supplier component lines. Odoo's August 15 upstream fix concerns what happens when those component costs are collapsed into one Sales Order Cost field, which then affects displayed margin.

Category: Odoo, E-commerce & ERP Profitability

In the documented path, a customer buys one kit: one sellable product represented by several components. A supplier ships those components directly to the customer. Odoo calls that dropshipping, and the component recipe is a bill of materials, or BoM. After the Odoo dropship picking was validated, the Sales Order Cost field could become zero even though the component purchase lines retained supplier prices.

Odoo's margin documentation ties line margin to sales price, cost, and quantity, so a zero Cost field can make the displayed margin look too high. That arithmetic consequence is the operational issue. The source does not say the vendor purchase order, vendor bill, inventory valuation, cost of goods sold, tax, revenue, or general ledger became zero.

What changed

Odoo's official commit documents the issue with Sales, Purchase, and Manufacturing installed; Margins and Dropshipping enabled; a kit BoM without cost shares; and FIFO/AVCO category-costing scope. FIFO means first-in, first-out; AVCO means average cost. The visible automated regression test explicitly configures FIFO, so an AVCO deployment needs its own recorded test.

Before the fix, confirming the purchase order and validating the dropship picking—the Odoo step that confirms the vendor-to-customer shipment—could recompute the kit's Sales Order cost as zero. The purchase order still held prices for the exploded component lines.

The root cause was an allocation path that produced a zero ratio when no BoM cost share was defined. The patch changes the dropship-kit calculation so it can derive value from component purchase prices in the tested path. Odoo added an automated regression test for kits both without and with BoM cost shares and checks the Sales Order cost after shipment validation.

This is an upstream code commit, not proof that every Odoo Online, Odoo.sh, on-premise, or customized database already contains it. Teams must identify the exact build before deciding whether an update is relevant.

Who should check this

This is not a general warning about all Odoo products or margins. The practical screen is short:

• The organization runs an Odoo 19 build.
• It sells a kit as one customer-facing line while purchasing its components separately.
• A vendor ships those components directly to the customer.
• The official reproduction's no-cost-share condition resembles the deployed setup, and teams rely on Sales Order Cost or Margin for decisions.

If all are yes, test the deployed build and configuration. If any are no, do not assume this reproduction applies.

Why operational leaders should care

One customer-facing line can cross several record structures. The catalog describes a kit. The BoM describes components and quantities. Procurement creates component purchase lines. Fulfillment confirms a direct vendor-to-customer movement. Sales then needs a cost against the original kit line so the margin view remains meaningful.

Reconcile where those records fan out and collapse. A validated picking does not prove component prices were reconstructed correctly at the commercial line. A dashboard can repeat the wrong Sales Order value.

Margin-based approvals, pricing reviews, commissions, alerts, exports, and analytics are systems to test—not failures established by the Odoo commit. The safe question is: which decisions consume this field, and can each result be traced back to the component price evidence?

The same design issue appears when Shopify or a custom storefront sells a bundle and Odoo expands it into components. The acceptance contract should preserve the bundle SKU, sold quantity, Odoo kit identity, effective BoM recipe, and component multiplier. A mapping that gets the shipment right but loses cost lineage is incomplete. The Odoo commit establishes no Shopify defect.

The kit-to-margin record map

AorBorC recommends treating the calculation as an evidence trail rather than a trusted field:

• Catalog and commercial line: Preserve the kit product, sold quantity, sales price, currency, company, BoM identity, and the effective recipe snapshot expected for that order.
• Component recipe: Record each component, quantity per kit, unit of measure, and any deliberate cost-share rule. Do not invent a cost share merely to hide a zero result.
• Procurement: Preserve the related supplier, purchase order line, component quantity, unit price, currency, and price changes approved after confirmation.
• Fulfillment: Link the dropship movement and its validation event back to the sales and purchase records. A completed shipment is evidence of movement, not cost correctness.
• Commercial cost and margin: Reconcile the Sales Order Cost field to the expected component-price calculation on the same quantity and currency basis.
• Reporting and decisions: Trace exports, dashboards, approvals, or other rules that use the field. Show exceptions instead of silently substituting a guessed value.

A ten-step implementation checklist

1. Identify the deployed build and modules. Record the Odoo version or hosting build, required apps and features, relevant custom modules, and company configuration. An upstream 19.0 commit is not a deployment receipt.

2. Choose one synthetic representative kit. Use production-shaped but non-customer test data. Capture the kit, sold quantity, BoM identity, effective recipe snapshot, component quantities, cost method, supplier setup, currency, and expected result.

3. Snapshot the component recipe. Export or record each BoM line and unit of measure. Run a case without cost shares if that matches operations, and a separate case with deliberately configured shares. Do not change production master data to make the test pass.

4. Confirm the commercial starting point. Create the Sales Order and record the kit line's sales price, initial Cost field, margin, company, currency, and links to the generated procurement. Keep the expected calculation outside Odoo for comparison.

5. Reconcile the exploded purchase lines. Confirm that every required component appears on the purchase order with the expected quantity, supplier, unit price, and currency. Investigate missing or duplicated lines before moving to fulfillment.

6. Capture the shipment event. Validate the dropship picking and record the event time, user, related sale and purchase records, and retry or automation activity. Confirm that fulfillment completion does not break record links.

7. Recalculate the Sales Order cost. Keep company, currency, and unit of measure consistent in the first test; multiply approved PO unit price by component quantity and sum the lines. Compare that commercial-cost evidence—not accounting valuation—with the post-validation Cost field. Test conversions and AVCO separately where used.

8. Test operational exceptions. Exercise the cases the business actually permits, such as changed supplier prices, partial quantities, cancellation, return, multiple currencies, or a revised BoM. Treat these as client-specific regression tests, not behaviours the patch promises to cover.

9. Trace every downstream consumer. Follow the Sales Order cost and margin into approvals, exports, analytics, pricing reviews, commissions, integrations, and management reports where they exist. Mark each as passed, failed, not applicable, or awaiting a named reviewer.

10. If a change is required, release it with evidence. Keep the build ID, test inputs, before-and-after values, result, reviewer, and rollback path together. Monitor zero or implausible kit costs, and route exceptions to an operations owner with finance review.

Risks, limits, and where the hype is not useful

“Odoo margins were wrong” is not supported. The commit documents and regression-tests a specific Sales Order cost calculation path in upstream Odoo 19. It does not establish how many databases used that configuration or whether a given hosted build was affected.

“The accounting was zero” is also unsupported. Sales Order cost visibility is not the same record as a vendor bill, stock valuation, cost of goods sold, or general ledger posting. A finance reviewer should determine which accounting records and reports need separate evidence.

Do not populate arbitrary BoM cost shares as a universal workaround. Odoo's stated fix is designed not to assume those shares always exist. Master-data changes need an operational reason, ownership, and regression evidence.

Do not assume the commit repairs historical orders or custom reports. The source describes code and a regression test, not a backfill. Check older affected-looking records separately and preserve corrections rather than overwriting evidence.

AI is not the remedy for missing cost lineage. It can flag a zero or unusual value, group exceptions, or help a reviewer assemble related records. It should not invent supplier prices, allocate component cost, change a BoM, or approve a margin-sensitive action without a defined rule and human review.

The AorBorC view

AorBorC is a founder-led Zoho, AI, e-commerce, and business-systems partner. Our Odoo implementation work starts with the real record flow: catalog, BoM, procurement, fulfillment, finance boundary, integration, reporting, and exception ownership.

For connected storefronts, our e-commerce systems delivery covers bundle and product-catalog mapping, checkout readiness, order handoffs, inventory and fulfillment behavior, and support recovery. Where standard behavior does not match the operating model, ERP module development includes scoped extensions and regression tests without treating customization as the first answer.

Rescue work follows the same method. An AorBorC cost-lineage review returns one evidence pack with the build ID, expected and observed cost, affected downstream consumers, and a remediation or test decision. Where stable UI or API checkpoints exist, Zoho QEngine test automation or another suite can rerun the order, component-line, shipment, and post-validation assertions. Human-reviewed AI can surface anomalies, but operational and finance owners decide what a cost means.

Business takeaway

An Odoo dropship picking can be valid while its Sales Order margin signal is wrong. When one sellable line expands into several supplier lines, commercial margin review needs a traceable component calculation.

Your next move

Create one synthetic kit order in a safe environment. Record the component purchase quantities and prices, validate the dropship shipment, and compare their expected total with the Sales Order Cost field. Have an operations or Odoo owner run the test and a finance reviewer confirm what the result does—and does not—prove.

If the trail breaks between the kit, component purchase lines, fulfillment, or reporting, bring that representative order to an AorBorC Odoo cost-lineage review.