Odoo for retail & wholesale.

Odoo retail ERP runs POS, e-commerce, inventory, purchasing and finance on one platform, so brick-and-mortar, webshop and warehouse share the same stock and customer record. For wholesalers, EDI and customer-specific price lists sit on the same model.

Yes. Odoo connects POS, the webshop and marketplace listings to one stock pool, so a sale in the store, on the website or through a marketplace reduces the same inventory in real time. Order management decides per channel which warehouse fulfils, supports click-and-collect and ship-from-store, and feeds returns back to the same SKU and customer record. The work is the channel rules: which warehouse ships which order, how returns flow back, where pricing differs. Decided before go-live, not patched in after.

Yes. Odoo POS deploys per shop on a tablet or desktop, syncing to the central Odoo instance with offline fallback when connectivity drops. Each store runs its own till session, cash count and end-of-day Z-report, while inventory, loyalty, gift cards and returns roll up centrally. Per-store price lists and promotions are set in the back office, and barcode scanning at the till keeps checkout fast on the same stock record. For a chain, the work is the rollout plan, the master data and the staff training, not the software.

Through a sync connector. Products, prices, stock levels, orders and customers move between Odoo and Shopify or other tooling near real time, so the webshop keeps selling while Odoo runs the back office. Odoo native e-commerce is the simpler architecture when you want one front office and one back office. The choice depends on which platform owns the catalogue and the customer experience, decided in blueprint, not treated as a connector problem after the fact.

Yes. Odoo handles EDI with retail buyers and 3PLs through EDIFACT and X12 message types (ORDERS, ORDRSP, DESADV with SSCC, RECADV, INVOIC, PRICAT), plus Peppol BIS for e-invoicing. These map to Odoo sales orders, deliveries, GS1 GTIN and EAN barcodes, and supplier invoices, with three-way matching reconciling order, receipt and invoice. The setup is rarely the protocol. It is the per-buyer message variant, since each retailer demands its own dialect of the standard.

Through one stock model across stores, warehouses and the webshop. Odoo allocates stock per warehouse based on customer postcode, product availability and shipping cost, with FEFO or FIFO picking and replenishment on min-max levels and supplier lead times. Lot and serial traceability cover end-to-end batch genealogy where the sector demands it, in food distribution, technical components or regulated goods. The discipline that makes this hold is the master data, the supplier hierarchies and the location structure set up before go-live, not the platform.

Yes. The Odoo Barcode app processes receiving, picking, internal transfers, batch transfers and stock counts on a phone or tablet on the warehouse floor, updating stock in real time instead of after the fact. Lot and serial numbers are scanned at the point of movement, and GS1 barcodes that carry GTIN, lot and quantity are read in a single scan with a 2D-capable scanner. At the till, the Odoo POS scans product barcodes on the same stock and customer record as the rest of the platform. The work is rarely the scanner. It is the product master, the barcode nomenclature and the location structure decided before go-live, so the right scan moves the right stock.

Yes. Odoo runs accounting on the same platform as POS, e-commerce and purchasing, so POS sessions and Z-reports reconcile to the ledger without a separate export. Peppol BIS e-invoicing is native and mandatory in Belgium, with rollout under way in France and other EU markets. For Spain, Odoo's localisation addresses the Verifactu invoicing requirements. Multi-entity groups consolidate across companies with intercompany flows, so month-end close stops being a manual reconciliation exercise.

Odoo runs B2B and B2C on one customer record and one stock pool, with channel-specific pricing, payment terms, credit limits and tax treatment. B2B customers log into a self-service portal showing their negotiated price list, real-time stock, quick reorder from order history and credit balance. B2C buyers see the public catalogue and standard prices. Account managers see the same customer in CRM with quotes and margin. The make-or-break is the customer hierarchy and price-list model decided in blueprint, not the technology.

A return started in store, on the webshop or through a marketplace creates an RMA (return authorisation) linked to the original order, the customer and the SKU. Returned stock goes to a quarantine location for inspection, with disposition rules deciding what returns to sellable inventory, what goes to clearance and what is scrapped. Refunds and credit notes post to accounting automatically, and marketplace returns arrive through the connector with the platform reason codes intact. Returns reporting rolls up by SKU, channel and supplier, the data you need to push quality issues back upstream.

Yes. Take-overs of underperforming Odoo retail and wholesale setups are a recurring intake pattern. We start with an assessment of the data model, the customisations, the channel integrations and the master data quality, then decide what stays, what gets refactored and what is rebuilt cleanly. Common findings are product master drift between channels, broken marketplace connectors, EDI mappings that no longer match the buyer spec, and POS-to-accounting reconciliation that breaks monthly. We stabilise first, then add new capability. Dynapps remains an Odoo implementation partner. We bring the discipline that decides whether Odoo holds up in production, not a separate product.