An electronics B2B distributor stocked fast-moving components and a long tail of accessories across three warehouses in three countries, all on Odoo 17. Each site ran its own min-max table. Global availability suffered anyway, and planners spent hours every week moving stock after a stockout had already happened. Seven years of movement history, read once through a single connector, gave the team the multi-warehouse inventory management they had been rebuilding by hand every Monday.
The situation
Around 9,500 active SKUs, three warehouses (Netherlands, Poland, Spain), and a planning team of four. Roughly 300 SKUs carried customer SLA commitments with contracted OEM accounts. A stockout on one of those lines meant a penalty or, worse, a lost design-in.
Odoo proposed replenishment per company and per warehouse. It did not know, or did not say, that the Polish site already held eleven weeks of cover on the same global SKU that Spain was about to reorder from the manufacturer with a six-week lead time.
The legacy min-max fields had been set at go-live, three years earlier. Nobody had the time to review 9,500 × 3 parameters, so they stayed.
What the data showed, and didn't say
Seven years of receipts, sales and inter-company transfers held the true global velocity per SKU and the real transfer lead time between sites (two to four days, versus six weeks from the supplier). The data also showed a recurring pattern: central stock high, regional velocity spiking, then an emergency air-freight shipment a fortnight later.
What the ERP never combined was site-level days of supply with global cover. Every warehouse was an island in the replenishment logic, even though the trucks between them ran twice a week.
Connecting Flowra
IT created a read-only Odoo user with access to the three companies and connected it through the native XML-RPC connector. Webhook-triggered syncs pick up new moves during the day; the full re-scoring runs nightly or on demand. No write permission was granted, and none was needed.
Flowra ingested the full history and reconstructed a stock trajectory per SKU per site from the net transaction flow. The first global risk report was ready the following morning, under 24 hours after access was granted.
What Flowra surfaced
- A single global reorder queue, ranked by stockout risk and revenue at stake, with a ship-from suggestion per line: transfer from a sister site or order from the supplier.
- Relocate-stock proposals on more than 60 SKUs where one site sat in the overstock tier (forward cover above eight weeks) while another was inside one supplier lead time of running out.
- Stockout risk windows mapped to SLA tiers, so contracted OEM lines were checked on a 14-day horizon and long-tail accessories on 60 days.
- A handful of lines marked unknown where the transfer history was incomplete. Flowra withheld a recommendation on those rather than guess, and listed what was missing.
- Fact
- Valencia days of supply on CAP-4471: 9 days against a 42-day supplier lead time (stockout risk: critical). Poznań forward cover: 14 weeks (overstock tier: high). Two contracted accounts pull this line from Valencia.
- Forecast
- Without action, Valencia runs out in the second week; a supplier order would land four weeks after that. Transfer lead time Poznań to Valencia: 3 days.
- Recommendation
- Transfer 1,200 units, covering 8 weeks of Valencia demand and bringing Poznań to 6 weeks of cover. Alternative: transfer 800 units and place a reduced supplier PO for the remainder.
- Hypotheses
- Velocity in Valencia holds at the 12-week average (+6% trend). Transfer route runs on schedule. No open supplier PO in transit for Valencia.
- Next step
- Approve, adjust the quantity, or ask why. Nothing changes in the ERP until you do.
What the team did
Every Monday, the head of planning opened the ranked queue and approved transfers first, then the reduced list of supplier POs. Approved actions were exported to the WMS pick-and-transfer workflow. Flowra did not write to Odoo; the planners kept the purchase order and transfer creation exactly where it had always been.
Site managers received their own view in Slack: only the lines affecting their warehouse, with the proposed action and the evidence. When the Spanish site manager disagreed with a transfer because a local promotion was about to start, the override and its reason were logged and the forecast hypothesis was corrected for the next run.
By the third week, the Monday balance spreadsheet, four tabs and roughly five hours of work, was retired.
Results
| Metric | Before | After | Timeframe |
|---|---|---|---|
| Emergency inter-warehouse freight (air and express) | Baseline quarter | −27% | One quarter |
| Same-SKU stockouts on contracted accounts | Baseline quarter | −19% | One quarter |
| Planner hours on manual balance spreadsheets | ~20 h per week (team) | ~10 h per week | From week 3 |
| Supplier POs raised while a sister site held cover | Not measured | Flagged and reviewed before release | Ongoing |
"Odoo knew how much stock we had in every warehouse. It just never told Valencia that Poznań had it. Now the transfer is the first thing on the list, and the supplier order is the exception."
— Head of Planning, electronics B2B distributor
What made it work
- One queue, not three. Ranking every site's needs in one list, by risk and revenue at stake, is what makes transfer-first possible. Per-site min-max rules can never see the sister warehouse. Stockout risk windows explains how the horizons were matched to SLA tiers.
- Lead time from history. The three-day transfer route versus the 42-day supplier route only matters if both numbers come from real receipts, not from the supplier card. See when to reorder: days of cover vs supplier lead time.
- Site managers kept the decision. Flowra routes the signal to the right role and logs the override. Adoption came from planners seeing their corrections change the next recommendation.
Frequently asked questions
How does Flowra handle multi-warehouse inventory management in Odoo?
One read-only Odoo user across the companies is enough. Flowra reconstructs a stock trajectory per SKU per warehouse from the transaction flow, scores stockout and overstock risk per site, and ranks transfers alongside supplier reorders in a single queue.
Does Flowra create the transfers or purchase orders in Odoo?
Not by default. Flowra drafts the transfer or reorder with the evidence and a planner approves it in the ERP or WMS. Write-back requires connector support, explicit opt-in per data source and the right user role.
What happens when transfer history is incomplete for a SKU?
Flowra marks the stock position as unknown and withholds the recommendation instead of showing a guessed number. The report lists what is missing, so the team can fix the source data rather than act on a false figure.
Same playbook, your data. Book a 20-minute walkthrough or upload a file and get your first ranked action list.
Get my free inventory report →