ERPixel insights

Odoo for eCommerce: How Online Sales Connect with Your Business

Conceptual illustration connecting an online shop, sales, inventory, CRM and finance

Odoo can connect online orders with stock, purchasing, warehouse operations and accounting. You can run the shop itself on Odoo eCommerce or keep an existing Shopify or WooCommerce store and connect it to Odoo. The useful choice depends on how you want orders, payments, deliveries and exceptions to move through the business.

This guide is for retailers, wholesalers and growing online sellers evaluating Odoo as their operational system. It explains the process behind a sale, rather than how to design a storefront or install a particular connector.

When an online sale creates more work than it should

A customer pays, but the warehouse has not received the order. Someone copies the address into another system, checks stock in a spreadsheet and sends a tracking number by hand. Later, the accountant has to work out which payment belongs to which sale.

This is an illustrative situation. The problem is the handoff between teams and systems: each may hold a different version of the same order. Adding a new sales channel can make those differences harder to notice.

Good order management gives each stage a clear status and a responsible person. The customer knows what is happening, the warehouse knows what to prepare, and finance can check the documents behind the transaction.

Do you need to replace your existing online store?

No. Odoo can provide both the storefront and the operational applications, or serve as the ERP behind a separate shop. ERP means the business system that connects functions such as sales, inventory, purchasing and accounting.

Storefront and back-office options
ApproachWhen to consider itWhat to check
Odoo eCommerce and Odoo operationsYou want the shop and business processes in the same environmentStorefront requirements, payment and delivery options, configuration and data preparation
Shopify or WooCommerce connected to OdooYou want to retain an existing shop while connecting operationsConnector scope, product matching, update timing, ownership of data and exception handling
1C-Bitrix: Site Management connected to OdooYou use or need this CMS-based storefront while keeping ERP operations in OdooSelected edition, existing customisations and the connector/API scope; this refers to the store CMS, not Bitrix24 CRM
Shoper connected to OdooYou use the Shoper storefront and want connected back-office processesAPI access, available connector and supported product/order/stock flows; verify the exact coverage
A standalone shop with a simpler back officeThe current process is reliable and operational needs remain limitedWhether reservations, multiple locations or repeated manual work justify a larger system

Bitrix and Shoper are additional storefront choices in this table, not a ranking of ERP systems. Shoper provides integration APIs; API availability alone does not establish that a specific Odoo connector supports every required workflow.

Odoo's all-in-one approach lets applications share business records. It can reduce duplicate data entry between those applications, but payment providers, carriers, marketplaces and external warehouses still need suitable connections.

For application capabilities, see Odoo eCommerce. For merchandising and the customer-facing experience, use the separate digital storefront guide. The platform-specific guides cover Shopify integration and WooCommerce integration.

Why ERPixel always uses an external connector for ecommerce integrations

For integrations between external sales platforms and Odoo, we always use a dedicated third-party connector. This is our expert approach: the integration should give the business control over its channels, not just copy orders from one system to another.

We select the connector around four practical requirements:

  • More control over products and prices. Configure product and variant matching, category mapping, price handling and order-processing rules for the relevant channel.
  • Different stores, different processes. Connect several shops while keeping their pricing, order handling and fulfilment rules distinct where required.
  • More precise management. Define what is exchanged, in which direction and under which conditions, with monitoring that makes failed or incomplete exchanges visible.
  • Value beyond the licence price. In our view, a connector licence is a relatively modest expense compared with the operational control it can add. Include configuration and support in the budget, then judge the value against the manual work and errors it replaces.

For a new business planning to connect sales channels to Odoo, we regard a suitable connector as a must-have. It is a practical way to establish a professional technology stack for growth from the beginning. We strongly recommend this standard integration approach whenever separate sales platforms need to share operational records.

For example, a company can take orders through its office sales team, a WooCommerce shop, Amazon and TikTok Shop while using Odoo for central operations. Each external channel needs a suitable connection, and TikTok Shop availability and connector coverage must be checked for the business's market. The channels can follow distinct processes without forcing staff to maintain a separate stock spreadsheet for each one. See our Amazon warehouse integration guide alongside the Shopify and WooCommerce guides above.

Odoo also documents a native Shopify connector. Our use of an external connector is a delivery choice based on the controls we want for the project; it is not a claim that Odoo has no native integration options.

Why a B2B portal adds value beyond a public shop

A B2B portal gives approved partners a place to check their commercial terms and place orders without asking a salesperson for every price or availability update. The useful question is what each type of partner should be able to see and do.

  • Private prices. An invited wholesale customer can receive an assigned pricelist rather than see the public retail offer.
  • Relevant stock availability. Show the availability appropriate to the partner and fulfilment arrangement. Decide whether this means an exact quantity, a simple availability indicator or a delivery estimate.
  • Different information for different partners. A distributor, reseller and service partner may need different catalogues, documents and ordering permissions. Define these access rules explicitly.
  • Order and document history. Partners can review the records they are entitled to access, reducing repeated requests for quotations, order status or invoices.

For example, an invited reseller could see its wholesale prices and available products, while a retail visitor sees the public offer. A distributor may require a different catalogue or ordering process. This is an illustrative design: test each partner role to confirm that restricted information is actually protected.

Odoo's customer accounts and pricelists provide starting tools for invitation-based access and customer-specific pricing. Detailed catalogue restrictions, stock visibility and permissions across partner organisations depend on the portal design and may require additional configuration or development. For external storefronts, these rules also need to be supported by the shop and connector. See Odoo 19 customer accounts and ecommerce pricelists.

Design the operating process in four steps

1. Decide where each record is managed

Agree where products, prices, customer information and stock availability are maintained. Use consistent product references and distinguish variants such as size or colour. If different customer groups use different prices, configure and test the relevant pricelists.

A shared product reference is especially important when a storefront, Odoo and a warehouse partner each identify the same item differently. Decide how new products and changes reach the other systems.

2. Define payment and order statuses

Agree what counts as a confirmed order and a confirmed payment. An online payment provider, bank transfer and payment on account may follow different paths. A checkout submission, payment authorisation, captured payment and bank settlement should not be treated as interchangeable evidence.

Specify who checks failed or pending payments and when an order may be released to the warehouse. Odoo's available payment functions depend on the provider and configuration; see the official online payments documentation.

3. Connect the order to fulfilment

Define which warehouse supplies the order, when stock is reserved and how picking, packing and dispatch are recorded. Order fulfilment may take place in your stockroom or at a third-party logistics provider, often called a 3PL.

Agree how dispatch status and tracking reach Odoo, the shop and the customer. External connections may exchange events promptly or synchronise on a schedule. For example, the connector described in the Odoo 19 Shopify documentation uses scheduled synchronisation; other connectors have their own behaviour. Check the supported hosting and version in its setup requirements.

For outsourced fulfilment, see how the Odoo Mintsoft Connector connects warehouse operations. Product mapping, stock updates and failed-message handling still need configuration and testing.

4. Agree how exceptions and financial checks work

Write down what happens if only part of the order can ship, a customer cancels, the carrier reports a problem or goods are returned. Each case needs an operational action and, where relevant, a financial action.

Decide how finance checks sales, invoices, payment-provider fees and settlements. A successful checkout alone does not complete that reconciliation.

How it works in Odoo: one order from checkout to dispatch

This is a hypothetical example, not an ERPixel client result. The standard Odoo explanation refers to Odoo 19; external-store behaviour depends on the selected connector.

A customer buys two lamps. Both are available in the chosen warehouse, and the business uses an online payment provider and a configured delivery method.

  1. The customer checks out. The shop records the selected products, delivery address, shipping option and payment attempt.
  2. The order and payment are checked. Once the applicable confirmation conditions are met, the sales order can proceed. With an external shop, the connector must create or update the corresponding Odoo record without duplicating it.
  3. The warehouse prepares the lamps. Odoo uses the configured reservation rules and delivery operation. Staff pick and pack the goods, then validate the quantities actually dispatched.
  4. The customer receives an update. Where the carrier connection supports it, tracking and shipment status can feed the customer notification process.
  5. Finance checks the documents. Invoicing follows the configured policy and automation. Payments and provider settlements must be matched to the appropriate records.

Odoo's order-handling documentation describes the sale, delivery and invoicing stages. Automatic invoicing and notifications need the relevant configuration; they should be verified during acceptance testing.

When does the order change stock?

A sales order can reserve stock according to configuration. The validated stock movement records what actually moved. The order date, reservation and physical dispatch therefore represent different events.

In the example, two lamps reserved for this customer should not be promised again to someone else. If only one is dispatched, the delivery record must reflect that quantity and the outstanding item must be handled explicitly. See inventory management for small businesses for the practical starting process, and the inventory synchronization definition for exchanging balances between systems.

Does a refund automatically return the goods to stock?

No. A refund or credit note concerns money and accounting. A return operation concerns the goods. The business must record what came back, inspect it and decide whether it is fit for resale.

If the customer returns one lamp, that return should be linked to the appropriate delivery. A damaged lamp may need a different destination from a saleable one. The refund decision and the stock decision should be checked together, while remaining separate actions.

What is standard, and what needs additional work?

Standard Odoo applications can share product, order, inventory and accounting records when configured for the business. Product variants and pricelists support different catalogues and selling arrangements. Requirements such as subscriptions or manufacturing introduce additional applications and process decisions.

A connector adds data exchange with an external shop, marketplace or warehouse. Custom development addresses requirements beyond the selected standard applications and connector scope. Record those gaps before assuming they are included.

Growth may mean adding applications, but it can also require better product data, revised warehouse flows, more hosting capacity or integration changes. Test a representative order and an exception before expanding to more channels.

What belongs in the implementation budget?

Build the budget around the agreed process. A single licence figure cannot describe the whole project.

  • Applications and licensing: edition, required applications, users and applicable subscription terms.
  • Hosting: deployment choice, capacity, backups and maintenance responsibilities.
  • Configuration and data: product records, taxes, prices, opening balances and order history where needed.
  • Integrations: connector licences, supported data, mapping, monitoring and external service fees.
  • Training and launch: user preparation, acceptance testing and responsibility for the transition.
  • Ongoing support: updates, failed exchanges, operational changes and connector maintenance.

Doing configuration yourself still takes working time and may require paid services. Ask for an estimate tied to a defined scope, rather than treating an old starting price as a current offer. Our Odoo implementation and integration services explain the project work involved.

How to evaluate the change

Use your own baseline to check manual re-entry, orders waiting for intervention, stock mismatches, dispatch delays and time spent reconciling settlements. Review returns and cancellations by reason rather than assuming every one is a systems problem.

The aim is a process the team can follow and verify: one customer order, clear operational statuses, reliable stock records and explainable financial entries. Start by mapping one complete sale and its most common exception. To discuss which setup fits your business, book a meeting with Alexander Koltsov.

CategoriesBusiness, ERP Development, Odoo
TagseCommerce, ERP, Odoo

Let’s talk

Discuss your project with ERPixel

Choose a convenient time to discuss your business requirements with our team.