ERP ERP Platform Modernisation

The brief

A long-running Odoo V18 deployment had grown most of its customisation surface through Studio. When the team ran a V18 → V19 upgrade test, the majority of those Studio customisations did not survive cleanly. The remit was to rebuild every piece of business logic in proper backend Python, ahead of the V19 cutover, without losing any of the workflow nuance the team relied on day to day.

What I built

A focused set of backend Python modules across the platform — covering order and logistics, customer and product master data, inventory workflows, and reporting. Each piece replaces a previous Studio customisation with a proper backend implementation that will survive future Odoo upgrades.

The analytics layer

Alongside the module work, a sales-and-margin analytics console — a single-page client action built in Odoo’s OWL framework with Chart.js visualisations, hierarchical pivot tables, and multi-select filtering. Read-only SQL view models (recreated cleanly on every upgrade) handle the aggregations that would otherwise require expensive ORM walks on every refresh.

Patterns that earned their place

A few patterns recurred across the suite:

• _auto=False SQL view models for any aggregation that would otherwise require an expensive ORM walk on every refresh.
• Snapshot-on-create with onchange duplication for fields that must not retroactively change when their source record moves.
• Stored computed flags with manual recompute hooks for cases where @api.depends can’t see sibling-record creation.
• Defensive Studio-field access so modules degrade gracefully across databases with different customisation histories — important during migration when the Studio schema is half here, half gone.

Outcome

A codebase that’s portable, version-controlled, and free of Studio dependencies. The V18 → V19 upgrade now has a clean path forward, and every customisation in the new platform will survive the next major release the same way.