Odoo customisation, migration and support
Custom modules, report and invoice templates, integrations and version upgrades, in Community and Enterprise, from Odoo v13 to v19.
What this covers
- Custom modules across Sales, Purchase, Stock, Accounting, CRM, Planning, Maintenance, Repair and Field Service
- Report and document templates: order confirmations, invoices and receipts, including DIN 5008 and Swiss layouts
- Website, eCommerce and eLearning customisation, down to checkout rules and course access
- Version migration in both editions, v13 through v19, with your custom modules carried forward and re-tested
- Integrations: WhatsApp messaging from CRM and Sales, payment gateways, and REST or file-based feeds
- Odoo Online, Odoo.sh and your own servers, including deployment and the pipeline around it
How an engagement runs
- 01
A first conversation
You describe what is slow, manual or fragile. I ask questions, not for a budget, and say plainly whether it is work I should do.
- 02
Scope in writing
What changes, what does not, how we will know it worked, and what I need from you: access, a copy of the site, a person who knows the process.
- 03
Build on a copy
Work happens on a staging copy of your site. You review it there before anything touches production.
- 04
Go-live with a gate
Releases and migrations follow a rehearsed plan with a tested rollback. Nothing writes to production without approval.
- 05
After go-live
Fixes, monitoring and upgrades under support and maintenance, if you want them.
What this has looked like
An invoice that has to satisfy an auditor, not a designer
The document layer is where Odoo meets a country's paperwork rules, and it is the request that keeps coming back: an invoice built to DIN 5008, a Swiss layout, an A6 receipt for a counter. The header is the hard part, because delivery notes, repair orders and invoices all have to carry it and stay in step. Built once against the localisation modules rather than as a copied template, then carried from v16 to v18 when the upgrade came — which is the test of having built it properly.
AI in Odoo on v15, and again on v19
In v15 that meant a GPT reader for vendor bills, built and demoed: the PDF goes to the model, and a draft bill, its vendor and a follow-up activity come back for a person to approve — the same shape the Frappe work took later, arrived at from the Odoo side first. In v19 it is an agentic automation engine sitting on base_automation: recipes that plan a sequence of steps, run them as a real user, and stop at a person before anything posts. Odoo is not a second-class citizen in this; it is where the pattern started.
Questions I get asked
- Which Odoo versions do you work in?
- Odoo v13 through v19, in Community and in Enterprise. An upgrade is usually one or two majors, and carrying the custom modules across and re-testing them is most of the work — the standard apps move themselves.
- Is Enterprise a problem, or only Community?
- Both. Planning, Field Service and Helpdesk customisation is Enterprise work; the invoice, report and integration layers are the same in either edition.
- Our invoices have to match a national layout standard.
- That is a template job rather than a code job. Layouts have been built against DIN 5008 and Swiss requirements, and the same approach fits any other — the standard fields move, the rest of the document stays yours.
- Can you take over an Odoo instance somebody else built?
- Yes, and it is common. The first pass is reading the custom modules already installed, which is what an upgrade needs anyway: what is yours, what came from OCA or an app store, and what has been patched in place.
