Standard Odoo implementations cover roughly 80% of what most businesses need. For F&B and retail chains, that remaining 20% is where operations either hold together or fall apart. The gaps are not random - they cluster around the same pressure points: multi-store promotion logic, real-time inventory visibility, loyalty programs that span channels, and recipe-based cost tracking. Left unaddressed before go-live, these gaps generate expensive workarounds, user frustration, and a second implementation within 18 months. This article maps the specific customizations that close those gaps, and explains why they must be built into the project plan - not retrofitted after launch.
TL;DR
Standard Odoo modules handle generic business flows well but consistently under-serve F&B and retail chain operations in four key areas: promotions, multi-store inventory, POS loyalty, and food costing.
Customization is not optional for chains with more than a handful of locations - it is a planning requirement, not a late-stage upgrade.
The 80/20 rule applies to Odoo ERP: use standard modules wherever possible, and customize only the logic that is genuinely chain-specific.
Customizations built into the initial scope cost significantly less in rework, data migration, and retraining than retrofitting them after go-live.
Pre-go-live testing against real operational data - not demo data - is the single most effective way to catch integration failures before they reach the shop floor.
About the Author: 724SOFTWARE is a Top 5 Odoo service partner in Vietnam with direct delivery experience across F&B and retail ERP deployments, including TocoToco Milk Tea (101 stores), Samsung's largest Vietnam dealer SAMNEC, and the INTELLIFE retail chain. The observations in this article come from production implementations, not theory.
Why Do Standard Odoo Modules Struggle with Chains Specifically?
Standard Odoo is designed for a single-entity business model. Its default assumptions - one warehouse, one price list, one promotional rule set - work well for businesses with a single location. Chains break those assumptions at scale.
The core tension is this: Odoo's out-of-the-box modules are built for breadth across industries, not depth within a specific operational model. A retail chain with 20 stores and an F&B operator with 50 branches both need logic that the standard modules do not expose at the configuration layer. That logic must be written.
Four problem areas account for most go-live failures in these sectors:
Promotion and discount engines that cannot handle dealer- or branch-level rules
Multi-store inventory visibility without real-time synchronisation
POS loyalty programs that fragment across channels
Recipe-based COGS tracking for food and beverage production
Each of these is examined below with specific fix strategies.
What Does the Standard Promotion Engine Miss for Retail Chains?
Standard Odoo pricelist and promotion tools handle straightforward discount logic: percentage off, buy-X-get-Y, date-bound offers. Retail chains need more.
The missing layers typically include:
Branch-level override rules - a promotion valid nationally except at airport locations or franchise stores
Dealer-tier pricing - different price schedules for wholesale, modern trade, and direct retail simultaneously
Stacking logic controls - preventing a customer from combining a member discount with a flash sale on the same transaction
POS-specific triggers - promotions that activate based on basket composition, not just individual SKUs
In the SAMNEC deployment, 724SOFTWARE built a custom promotion and discount engine directly into Odoo to support Samsung's complex dealer-based sales programs. The standard pricelist module could not accommodate the tiered dealer structure, so the logic was written as a custom module layered over the core.
Fix before go-live: Map every promotion scenario from the last 12 months of trading data. Build and UAT the custom engine against those scenarios before launch. Do not assume the standard module will handle edge cases - test them explicitly.
How Should Multi-Store Inventory Be Handled in Odoo?
Multi-location inventory in standard Odoo uses the warehouse and location hierarchy, which works for warehouses but becomes slow and opaque when applied to 20+ retail stores.
The practical problems:
Store managers cannot see real-time stock at other branches without custom views
Inter-branch transfer workflows are clunky and under-audited in the default setup
Replenishment rules do not account for store-level sell-through velocity
Central purchasing cannot reconcile branch-level consumption against a consolidated purchase order
For F&B chains, this is compounded by perishability. A branch that cannot see its own stock level in real time will over-order perishables, inflate waste costs, and distort COGS calculations.
Fix before go-live:
Build a custom multi-store dashboard that surfaces live stock by location, configurable by role (store manager vs. central buyer)
Implement inter-branch transfer approvals with automated audit trails
Configure replenishment rules per store using historical velocity, not flat minimums
For F&B, connect inventory consumption to the production/recipe module so that ingredient depletion posts automatically against the correct branch's cost centre
What POS Customizations Does a Loyalty Program Actually Require?
The standard Odoo loyalty module works for a single storefront. For a chain with both physical POS and an e-commerce or app channel, it breaks in two specific ways:
Points earned in-store are not visible or redeemable through the online channel in real time
Tier recalculation (e.g., moving a customer from Silver to Gold) runs on a batch schedule, not transactionally
Both of these are visible failures at the point of sale. A customer who earned points yesterday and cannot redeem them today will notice.
Fix before go-live:
Centralise the loyalty ledger in a custom module that sits above both the POS and eCommerce modules, so both channels write to and read from the same record
Trigger tier recalculation on every transaction completion, not on a nightly cron job
Build a customer-facing points balance view accessible via both the POS receipt and the online account portal
Test redemption flows across channels before go-live using a staging environment with production-mirrored data
For the INTELLIFE retail chain, 724SOFTWARE customised the Odoo POS module and bridged it to SAP S/4HANA to achieve real-time store-to-HQ synchronisation across a nationwide network. The integration required custom mapping logic that did not exist in either standard system - it had to be built as part of the implementation scope.
How Do F&B Chains Handle Recipe-Based COGS in Odoo?
This is the most under-estimated customisation in F&B implementations. Standard Odoo manufacturing and inventory modules track raw materials, but they do not natively support the F&B concept of a recipe-level bill of materials (BoM) that auto-calculates COGS per dish or drink across multiple store locations.
For a milk tea chain with 100 branches, the business needs to know:
The theoretical COGS per SKU based on the current recipe and ingredient prices
The actual COGS per branch, based on recorded consumption vs. theoretical usage
Variance reporting that flags branches with abnormal waste or portion deviation
In the TocoToco deployment across 101 stores, this required a custom manufacturing module with automated COGS calculation, aligned to Vietnamese Accounting Standards. The semi-finished goods logic - where a base syrup is produced centrally and then used as an ingredient at store level - does not exist in standard Odoo.
Fix before go-live:
Define the full BoM hierarchy (finished product, semi-finished components, raw ingredients) before development begins
Build variance reporting into the costing module, not as a separate BI layer
Validate COGS calculations against at least one month of real transaction data before go-live
Frequently Asked Questions
How much customisation is too much for an Odoo implementation?
The 80/20 principle applies: use standard Odoo for 80% of workflows and customize only where your business logic genuinely differs from the standard. Each custom module adds maintenance overhead, especially across version upgrades. Customise processes that are core to your competitive operation - not every preference.
When should F&B or retail customisation be scoped in the project plan?
At the requirements phase, before development begins. Customizations added after go-live require data migration, retraining, and often downtime. The cost of late-stage changes consistently exceeds the cost of scoping them correctly from the start
Can standard Odoo POS handle a 50-branch retail chain without customisation?
For basic sales recording, yes. For real-time inventory sync, cross-branch loyalty, and promotion logic at scale, the standard POS module requires meaningful customisation
What is the most common cause of Odoo go-live failure in retail?
Inadequate testing against real data. Demo data masks integration failures that only surface under production volumes and actual SKU complexity.
Does Odoo support omnichannel retail out of the box?
Odoo 19 has significantly improved its eCommerce and POS integration, but omnichannel flows - particularly loyalty, returns, and real-time inventory - still require custom development for multi-store chains.
How long does a retail or F&B Odoo customisation typically take?
It depends on scope. A focused customisation (one module, well-specified) can be delivered in four to eight weeks. A full chain deployment with custom promotions, POS, inventory, and costing typically runs six to twelve months, including UAT and training.
Should customisation be maintained by the implementation partner or in-house?
For chains that update Odoo versions regularly, the implementation partner should own upgrade compatibility for custom modules. In-house teams can handle configuration changes, but custom module maintenance requires Python and Odoo framework expertise.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based technology company and Top 5 Odoo service partner in Vietnam, with a team of 200+ professionals (58% senior-level) and delivery experience across 10+ countries. The company has implemented and customised Odoo for F&B and retail operators including TocoToco Milk Tea, SAMNEC (Samsung's largest Vietnam dealer), and INTELLIFE, handling complex scenarios such as multi-branch inventory, dealer-tier promotions, and recipe-based COGS. Certified under ISO 9001, ISO 27001:2022, SOC 2 Type II, and GDPR, 724SOFTWARE works as a long-term technology partner - not a project shop - supporting clients from initial implementation through ongoing operations.
If your F&B or retail chain is approaching an Odoo implementation or planning a go-live, the gaps described in this article are solvable - provided they are in scope from day one. Visit https://724software.com.vn to speak with a certified Odoo specialist about what your specific operation needs before launch.
