Ecommerce and ERP integration should connect the submitted order, fulfilment progress and accounting decision without confusing their meanings. Start with a shared record map and an agreed handoff for each state. Then test a paid order, a payment awaiting confirmation and a partial delivery so the receiving team can act on the evidence the connection actually supplies.
An online order can involve a storefront, warehouse process and accounting record even when they sit inside one product suite. Write which component owns each decision and which identifiers connect the records. This makes the same questions useful when assessing an external integration, where the relationships must cross another application boundary.
The original handoff exercise below uses a fictional physical-goods order. Narrow examples come from Odoo 19 ecommerce order-handling and Sales invoicing-policy documentation, retrieved on 24 October 2026. General online stores and business systems remain broader discussions.
Which order state should the ERP receive?
Odoo’s ecommerce workflow distinguishes sale, delivery and invoicing. Its order-handling guide describes separate records supporting those stages. Use that distinction to identify the meaning of the proposed handoff instead of sending one unexplained complete flag between systems.
Odoo labels a completed checkout awaiting payment confirmation Quotation Sent. Odoo labels a confirmed checkout with payment received Sales Order. Record the actual source state and the evidence the receiving process needs. A customer completing a form and a payment being confirmed are different events in this documented example.
Odoo wire-transfer orders require manual confirmation after payment is received. Include a pending-confirmation case in the test brief. Ask the receiving team which action is permitted while confirmation remains outstanding and what later evidence changes that decision.
For the fictional order, give the storefront and ERP records distinct identifiers on the worksheet. Add the mapping that should connect them. If the proposed solution uses another platform or connector, request its own documented state contract rather than assuming it uses Odoo’s terminology.
How should fulfilment progress cross the boundary?
Odoo requires the Inventory app to process ecommerce deliveries. For eligible physical-goods orders, Odoo creates a delivery order after the sales order is confirmed. Odoo does not generate delivery orders for Service or subscription products. Delivery scope. Check each sample product’s type before specifying warehouse work. These documented prerequisites and transitions provide concrete questions for the proposed system: which source event creates work for the warehouse and where does the resulting record remain identifiable?
Write what picking, dispatch and delivery evidence mean in the actual operation. The integration brief should state which observation each system records and which role confirms it. A warehouse update can describe work completed within the warehouse without establishing every later event in the customer’s delivery journey.
Use a partial-delivery case to expose the quantity relationship. Record ordered, prepared, dispatched and outstanding quantities separately where the business requires them. The expected relationship belongs in the written exercise so a reviewer can compare it with the configured result.
| Handoff | Proposed information to exchange | Acceptance question |
|---|---|---|
| Submitted order | Stable order reference and selected items | Which purchase does the ERP record represent? |
| Payment confirmation | Actual state and relevant reference | What permits the next business action? |
| Warehouse preparation | Product type, eligible physical items and required quantities | Should a delivery order exist, and can the warehouse identify its work? |
| Partial fulfilment | Completed and outstanding quantities | Is the remainder still understandable? |
| Invoicing | Agreed quantity basis and transaction reference | Does billing follow the intended policy? |
| Reconciliation | Differences and responsible owner | Who investigates an unmatched record? |
The table is an original integration contract sheet. Its expected values should be agreed for the particular systems being assessed.
Which quantity should accounting use?
Odoo supports invoicing ordered quantities or delivered quantities. Its invoicing-policy guide shows how a business decision affects the later handoff. Identify the intended policy per relevant product and keep that policy with the test case.
Odoo applies a newly selected default invoicing policy to newly created products. Existing Odoo products need their policy updated separately. Include an existing and a new fictional product in the proposed review if a configuration change is part of the implementation. This makes the policy scope visible rather than assuming a default change rewrites every record.
Odoo’s delivered-quantity policy requires validated delivery before invoicing. Odoo says that policy cannot use its Automatic Invoice feature. Preserve these product-specific qualifications when assessing automation. A general preference for automatic billing does not establish that every quantity policy and feature can be combined.
Ask the accounting owner to explain the intended invoice for the partial-delivery example before viewing the system output. Retain their expected quantity basis and the source transaction reference. This creates an independent acceptance point for the handoff instead of accepting whichever invoice the demonstration happens to generate.
Keep units beside every exchanged quantity. Ask whether the source and receiving records use the same unit and how an agreed conversion is represented. Include the expected calculation in the fictional exercise so a plausible total cannot conceal a mismatched pack, item or delivery unit.
Original order-to-accounting handoff exercise
Prepare a fictional order with two sample items and explicit quantities in a separate test environment. Record each item’s product type, intended payment state, warehouse action and invoicing policy. Include a separate Service or subscription sample to check that it does not generate a delivery order; keep that result distinct from the physical-goods fulfilment case. Use invented customer details and the documented test arrangement appropriate to the payment integration.
Begin with the normal confirmed-order route. Follow the source order into the receiving operational record and retain both identifiers. Ask the warehouse owner to identify the work and the accounting owner to explain when billing becomes appropriate. Record the evidence each role actually uses.
Next, run the payment-awaiting-confirmation case. Inspect which records exist and what operational action is available. Compare the result with the written requirement and keep any mismatch as a specific state or authorisation question. Then introduce a partial fulfilment and inspect the outstanding quantity alongside the proposed invoice basis.
Where a default policy is being changed, include an existing sample product and a newly created sample product in the exercise. Inspect both product records before preparing their orders. Retain their actual policies beside the expected invoice basis so the configuration scope can be checked directly.
Finally, compare the source and receiving records in a small reconciliation sheet. Include one deliberately unmatched test reference and ask the responsible owner to explain the investigation route. Preserve the discrepancy and its decision so a later correction remains understandable.
Use the exercise to assess the handoff rather than the visual similarity of two dashboards. For connecting the chosen systems, see web development. To discuss the order states, quantity policy and unresolved mappings, get started with the contract sheet.
For the handoff exercise, keep one order identifier visible across the proposed store and ERP records. Ask the owner of each stage to show what evidence permits the next stage to proceed and where discrepancies will be assigned.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.