From Excel Chaos to a Future-Proof Odoo System — Across Three Version Migrations.
A specialised Belgian scooter, motorcycle, and light EV retailer needed their growing Odoo operation stabilised, automated, and built to survive the future. Here's exactly what we built — and what it achieved.
Excel Eliminated
Product catalogue management moved entirely into Odoo
3 Version Migrations
V17 → V18 → V19 survived cleanly
95% Migration-Proof
Codebase built to Odoo's official standards
Fully Automated
Vehicle repair status, fleet servicing, and stock workflows automated end to end
A one-stop urban mobility shop in the heart of Belgium.
Our client is a specialised Belgian retailer and service provider for scooters, motorcycles, and light electric vehicles — based in Halle, Belgium. They operate as a true one-stop-shop for urban mobility: selling vehicles, accessories, apparel, and providing repair and servicing for everything they sell.
Their customer base spans individual urban commuters, fleet operators, and businesses looking for light electric transport solutions. Their operation combines retail, eCommerce, workshop servicing, fleet management, and accessories — all under one roof.
They were running on Odoo Online — which meant no custom Python code, no server access, and all customisation had to be done within Odoo Studio's constraints. This made their requirements technically demanding: everything needed to be built Studio-native, future-proof, and capable of surviving Odoo's aggressive version release cycle.
The stakes were high. A business this operationally complex — managing serialised vehicle inventory, repair workflows, eCommerce categories, multi-company branding, and retail POS simultaneously — needed Odoo to work exactly right. It wasn't.
Operational Snapshot
Location
Halle, Belgium
Complexity Stack
Retail POS, eCommerce, Fleet, Workshop Repair, Serialised Inventory, Multi-Company
System Constraints
Odoo Online Edition
Strictly Studio-native. No custom Python. No server access. Must survive v17 → v18 → v19 migrations cleanly.
A growing business running on workarounds — with an Odoo system that hadn't kept pace.
When Rootlevel came in, the business was live on Odoo but fighting it daily. They were managing multiple channels, but because their Odoo Online setup had no custom structure, critical parts of their operation were managed outside the system or resolved via slow manual workarounds.
Product Catalogue Managed in Excel
Their product catalogue — spanning vehicles, accessories, apparel, and parts — was still being managed in Excel. This resulted in a duplicate catalogue system, out of sync across multiple places, which demanded hours of manual maintenance.
No Automated Repair & Status Tracking
Vehicle repair and servicing jobs moved through workshop stages manually. Service reminders had to be triggered by staff remembering to do so. Fleet management was entirely disconnected from the active servicing database.
Broken eCommerce Category Hierarchy
The online store was active, but the category structure did not match how customers navigated or how internal inventory was organised. Re-linking products and finding correct items was a continuous operational bottleneck.
Multi-Company Branding Conflicts
Branding conflicts caused incorrect logos to display on customer websites and mailings based on the active company context. A massive credibility issue for a retail mobility brand where visual consistency is a primary touchpoint.
The Odoo Online constraint was the core technical challenge
Because they were on Odoo Online, every solution had to be built inside Odoo Studio's boundaries. No custom server scripts, no external backend libraries. Every customization needed to be native, maintainable, and built to survive the sequential V17 → V18 → V19 upgrades cleanly.
Six distinct problems.
All interconnected. All solvable.
A complex retail operation requires all gears to turn in unison. When inventory sync fails, repairs lag, or company contexts overlap, it directly damages the brand's customer experience and bottom line.
Product Catalogue Management in Excel
The business was managing their entire product catalogue — vehicles, accessories, apparel, and parts — in Excel. Every update required manual work in two places. Errors crept in, sync was never perfect, and the team was doing work Odoo should have done automatically.
No Automated Repair & Vehicle Status Tracking
Vehicle repair jobs had no automated status workflow. Technicians updated status manually — or didn't update it at all. Reminders were triggered by memory, fleet data was disconnected, and management had no real-time view of workshop throughput.
Odoo Studio Constraints Required Expert Navigation
No custom Python, no external modules, and no server access. Custom fields had to work across multiple models with proper dependency and QWeb reports had to be modified safely. Building robust structures in Studio that survive migrations requires rare expertise.
eCommerce Category Hierarchy Broken
The online store was live, but the category structure didn't match customer navigation or internal stock systems. The hierarchy needed a complete rebuild: logical parent-child categories, proper product mappings, and clean inventory links.
Multi-Company Logo & Mailing Conflicts
Across the multi-company setup, branding was inconsistent. The wrong logo appeared on the website and in customer mailings depending on active context — causing a real credibility issue for a brand where presentation matters.
Migration-Proof Future Requirement
The client knew they were on a migration path from V17 to V18 to V19. Every configuration had to survive. The technical standard required was explicit: 95%+ migration-proof, with adjustments limited to unavoidable backend Odoo changes.
Six solutions. All Studio-native.
All migration-proof. All in production.
By combining deep architectural knowledge of Odoo's backend database with Odoo Studio's official frameworks, we delivered a system that resolved every operational pain point while remaining ready for future updates.
Studio-Native Product Catalogue Generator
The Requirement
A product catalogue generator built entirely within Odoo Studio — no custom Python, no external tools — capable of producing branded product catalogues from live Odoo data.
What We Built
A custom QWeb report template built using Odoo's native report engine, driven entirely by Studio-configured fields and data structures. The catalogue pulls live product data — images, specifications, pricing, category, availability — and renders it in the client's brand design. New products added to Odoo appear in the catalogue automatically. No Excel. No manual layout. No separate design tool required.
Engineering Context
Building a presentation-quality catalogue generator within Studio's boundaries required careful architecture of the underlying data model — custom fields structured to feed the report correctly, with proper dependency handling between product, category, and variant models. Every field relationship was designed to survive version migration without manual intervention.
Vehicle Repair & Fleet Automation Workflows
The Requirement
Automated status tracking for vehicle repair jobs, service reminders, and fleet management — all connected and running without manual triggers.
What We Built
Native Odoo automation rules driving vehicle repair status through defined workflow stages — job received, diagnostic, in repair, quality check, ready for collection, collected. Each stage transition triggers the appropriate team notification and customer communication automatically.
Engineering Context
Fleet module configured with proper servicing records, mileage tracking, and reminder automations for scheduled maintenance. Service due dates are calculated automatically based on last service date and service interval — sending reminders to the right person at the right time without anyone having to remember.
Inventory Serialisation for Vehicles & Accessories
The Requirement
Proper serialised inventory management for vehicles (each unit tracked individually by serial number) and lot-based management for accessories — jackets, apparel, helmets, parts — with correct stock valuation and movement tracking.
What We Built
Serial number tracking configured for all vehicle SKUs — every unit has a unique identity from receipt to sale. Lot tracking configured for accessories with appropriate grouping logic.
Engineering Context
Stock moves, delivery orders, and warranty tracking are all connected to serialisation data. Inventory reports are configured to show serialised stock positions clearly for management and audit purposes.
eCommerce Category Hierarchy Rebuild
The Requirement
A logical, customer-facing eCommerce category structure that matched how customers browse — and connected cleanly to internal inventory categories.
What We Built
Complete rebuild of the eCommerce category hierarchy — parent categories (Vehicles, Accessories, Apparel, Parts, Services), child categories (by vehicle type, gender, product type), and correct product assignments throughout.
Engineering Context
Internal inventory categories are aligned with eCommerce categories so stock management and online presentation stay in sync. Fully responsive navigation was rigorously tested across device types before go-live.
Multi-Company Logo & Mailing Conflict Resolution
The Requirement
Correct company branding on the website and in all customer-facing mailings regardless of which company context is active.
What We Built
Diagnosed the root cause of the multi-company branding conflicts — incorrect company context resolution in website rendering and email template inheritance.
Engineering Context
Rebuilt the relevant template inheritance chains to correctly resolve company context before rendering logos and branding elements. Tested across all company combinations to confirm consistent, correct branding in every scenario — fixed at the root, not patched.
Migration-Proof Codebase Across V17 → V18 → V19
The Requirement
Every customisation built to survive three consecutive Odoo version migrations with 95%+ intact.
What We Built
Every Studio configuration built using Odoo's official field types, view inheritance patterns, and automation rule structures — no workarounds, no unofficial hooks, no features that were deprecated in the next version.
Engineering Context
QWeb reports built using stable rendering APIs. Automation rules use trigger types with confirmed long-term support. Before each migration, a compatibility review identified elements at risk, leading to proactive adjustments. Result: sequential migrations completed with 95% of customisations intact.
Team Training to Full Self-Sufficiency
The Requirement
The client's team trained to manage their Odoo independently — not dependent on Rootlevel for routine operations.
What We Built
Structured training programme covering Odoo's import/export functionality (the team now manages product data independently), native search bar usage for operational reporting and historical data analysis, fleet module management, and eCommerce catalogue maintenance.
Engineering Context
The ultimate measure of success: the client's team handles their own product updates, generates their own reports, and manages their fleet — without calling us for routine tasks.
A business that used to fight its Odoo system now runs on it.
By shifting from ad-hoc spreadsheets and manual reminders to a unified, Studio-native Odoo database, we transformed their backend operations into a smooth engine of growth.
Excel Eliminated Entirely
Product catalogue management moved completely into Odoo. The team no longer maintains two systems. Product data is entered once, lives in one place, and flows to the catalogue, eCommerce store, and inventory simultaneously. The manual synchronisation effort — and the errors it produced — is gone.
Repair & Fleet Workflows Fully Automated
Vehicle repair status updates happen automatically as jobs progress through the workshop. Service reminders are triggered by the system on schedule. Fleet records are accurate and current. Management has real-time visibility into workshop throughput without asking anyone for a status update.
Three Version Migrations Survived
V17 → V18 → V19 — completed with 95% of all customisations intact. The client's investment in their Odoo system compounds across versions rather than being rebuilt from scratch with each upgrade. This is what migration-proof development looks like in practice.
Team Fully Self-Sufficient
The client's team manages product imports and exports independently. They generate operational reports using Odoo's native search and grouping tools — saving significant time during monthly and annual audits. New team members can be onboarded to standard operations without Rootlevel involvement.
Brand Consistency Restored
Website and customer-facing mailings display correct company branding in every scenario. The credibility issue created by inconsistent logos is resolved at the root — not patched with a workaround that breaks on the next update.
eCommerce Navigation Improved
Customers find products through a logical, well-structured category hierarchy. Internal inventory management and eCommerce presentation are aligned — changes in one reflect correctly in the other.
Technical Snapshot
The architectural configurations, module specifications, and engineering compliance levels defining this deployment.
Odoo Version
v17, v18, v19 (sequential migrations)
Odoo Edition
Online (Studio-native builds only)
Modules Used
Inventory, eCommerce, POS, Fleet, Repairs, Sales, Accounting, Email Marketing
Key Constraints
No custom Python — all Studio-native
Automation Tools
Odoo Native Automations, Scheduled Actions
Report Engine
QWeb (native Odoo report builder)
Migration Standard
95% future-proof across 3 versions
Serialisation
Serial number tracking (vehicles) + Lot tracking (accessories)
Three things every Odoo Online business should know.
Studio constraints are not limitations — they're a discipline
Building within Odoo Studio's boundaries forces a level of architectural discipline that often produces better long-term outcomes than unconstrained custom development. Every solution has to work within Odoo's official framework — which means every solution survives Odoo's version upgrades. The constraint is the feature.
Migration-proof development is a standard, not a premium
Most vendors treat migration-proof code as an optional extra — something you pay more for. It shouldn't be. Every customisation built outside Odoo's official development standards is technical debt that compounds with every version. Building to the standard costs no more time when you know what you're doing. The Belgian client's 95% migration-proof result across three versions is proof that the standard is achievable consistently.
Training to self-sufficiency is part of the deliverable
An Odoo system your team can't operate independently is only half a delivery. The most valuable moment in this engagement wasn't a technical build — it was watching the client's team generate their own audit reports using Odoo's native search tools for the first time, realising they no longer needed to export to Excel to answer a management question. That's what successful implementation looks like.
If you recognised your business in this case study:
Here are the specialised services, industry configurations, and regions related to this deployment.
Services That Delivered This Project
Related Industries
- Odoo for Retail & Point of Sale
- Odoo for eCommerce
- Odoo for Wholesale & Distribution
Similar Geographies
- Odoo ERP for Belgian Businesses
- Odoo ERP for UK Businesses
Running a retail, eCommerce, or mobility business on Odoo — and recognise any of this?
Whether your Odoo needs stabilising, automating, or migrating to a new version — we've done it. Book a free discovery call and we'll tell you exactly what's possible for your setup.