Odoo customisation: configuration, Studio, code

Everything so far was learning the system as it is. This station teaches something different: when to stop changing it.

Professionally it is the most important station on the path, because what separates a good consultant from a poor one is not what they can build, but what they refuse to build. A consultant who implements every request that arrives hands the client a system that works today and is impossible to upgrade in two years.

The four levels, and what each one costs

Level	Example	Who does it	Cost at upgrade
1 — Configuration	Enabling an option, payment terms, a numbering sequence, a pricelist rule	A capable user	None
2 — Data and reports	Grouping a report, saving a view, an item list, a chart of accounts	A capable user	Almost none
3 — Visual customisation	An extra field, moving it on the screen, a visibility condition, editing a print template	A functional consultant	Moderate — reviewed at every release
4 — A written module	New computation logic, an external integration, a workflow that does not exist	A developer	High, and annual

The governing rule, and the one worth writing down and holding to: do not descend a level until you have proved the one above it is insufficient.

The reason is in the last column. Configuration is part of the product, so it travels with it into the next release. Code is something you added from outside it, so at every annual release you — not Odoo — are the one who makes it work again.

Why level one gets skipped

Because nobody looked there. Most customisation requests reaching developers have a ready configuration answer the requester did not know existed.

The same examples recur verbatim:

• “We need a different price for this customer” — pricelists.
• “We need the invoice due in 30 days” — payment terms.
• “We need numbering that starts with the branch letter” — a numbering sequence.
• “We need manager approval on large orders” — the approval rules built into purchasing.
• “We need a monthly sales report per salesperson” — a grouping on an existing report, the skill you built at station seven.

An hour spent in the settings saves a week of development and years of maintenance. That sentence is the station in one line.

Level three: the visual customisation tool

Odoo ships a visual customisation tool — Studio — that adds a field, moves an element on the screen and edits a print template without writing code. It is outside the Community edition, which is one reason for the two-environment decision taken at station one.

What Studio produces is not magic: it is modifications stored in the database — an added field, an inherited view, an automation rule. That means they can be exported and moved, and it also means they get reviewed at every upgrade.

The practical boundaries, worth knowing before you promise them to a client:

• Fits: an extra field on an existing model, conditional showing and hiding, reordering a screen, a print template, simple automation triggered by a record’s state.
• Does not fit: multi-step computation logic, integration with an external service, any change to the accounting or inventory engine, anything that runs outside a user session.

Its trap is that it is frictionlessly easy. Anyone who opens it without discipline adds forty fields in a month: the screen becomes crowded, the fields nobody fills accumulate, and then the same thing gets measured by two different ones. A practical judgement: every added field must have an owner who uses it in a report or a decision — otherwise it is debt, not a feature.

Level four: when the thing genuinely earns code

Three cases, and only three, earn it without argument:

1. Computation logic that does not exist in the product — a compound commission rule, pricing on a formula specific to the sector.
2. Integration with an external system — a government platform, a bank, a third-party warehouse.
3. An industrial workflow with no equivalent — a control procedure or approval chain the product has no counterpart for.

Outside those three the right question is not “can we?” but “why is our process different from that of the thousands of companies the product works for as shipped?”. Sometimes the answer is a genuine competitive reason. More often it is a habit inherited from an old system whose rationale nobody remembers.

And if you do write code, one non-negotiable rule: a separate module that extends the product, never an edit inside its files. Odoo is built on inheritance for exactly this purpose. Editing the product’s own files loses the change at the first update, possibly without anyone noticing.

The upgrade test

Before approving any customisation, ask this question in these words: when Odoo ships its next release, who makes this work again, and at what cost?

• Configuration: Odoo, at no cost.
• Visual customisation: you, with a review.
• A written module: you, with testing and fixing — every year.

Multiply that by the number of customisations and you understand why companies get stranded on a release five years old. Nobody decided to stay there; upgrading simply became more expensive than tolerating it.

That is the bill that appears in no sales presentation, and its financial effect is set out in the Odoo guide.

The written decision rule

This is what you leave the station with, and you apply it to every request that reaches you.

1. Is this asked for because it is necessary, or because the old system did it? If the second, stop here.
2. Is there a setting? Search for an hour before saying no.
3. Is there a report or a grouping that yields the same information?
4. Does the visual tool solve it with one field? If it needs five fields and three automations, you are writing software with tools that were not built for it.
5. If you do reach code: write it as a separate module, document its reason in one line, cost its annual maintenance and tell the client that figure before you build.

The last clause of point five is what marks out the professional. Customisation is not refused because it is impossible; it is accepted or refused once whoever pays knows what they will pay every year.

The acceptance test for this station

1. Take three real customisation requests — from your work or from user groups — and classify each at its level with a written justification.
2. Deliver one of them by configuration alone and prove it needed nothing more.
3. Add one field with the visual tool, then export the customisation and examine what was actually created in the database.
4. Write one line per customisation you have made saying who uses it and in which decision. Anything you cannot write that line for, delete.
5. Estimate the annual upgrade cost for a list of ten customisations spread across the levels.

What comes next

You now have, in practice, everything asked of a functional Odoo consultant. The final station turns that into something visible from outside: the certification with its published figures, and a portfolio you can present in an interview — plus a straight answer to a question that deserves one: is the certification worth its fee at all?