Becoming an Odoo consultant stages 10
Technical literacy, not development
Enough of the technical layer to be useful: how Odoo stores data, what a model and a view are, developer mode, reading an error, and knowing exactly when to hand something to a developer.
After this stage: Ability to talk to developers precisely, judge whether a request is small or large, and diagnose problems instead of forwarding them.
You are not becoming a developer. You are becoming someone a developer can work with — who can describe a problem precisely, estimate whether something is small or large, and diagnose an issue rather than forwarding a screenshot.
That is a genuinely different skill, and it is worth a few weeks.
How Odoo is organised
Four ideas cover most of what you need.
Models. A type of record — a customer, a sales order, a product. Each has a technical name like sale.order or res.partner. When a developer says “on the sale order model”, they mean the thing you call a sales order.
Fields. The pieces of data on a model. The types matter, because they explain what is easy and what is not:
| Type | What it holds | Example |
|---|---|---|
| Text, number, date, boolean | A simple value | Reference, quantity, order date |
| Many2one | A link to one other record | The customer on an order |
| One2many | The many records that point back | The lines on an order |
| Many2many | Links in both directions | Tags on a contact |
| Computed | Calculated from other fields | Order total |
| Related | Borrowed from a linked record | Customer’s country, shown on the order |
Understanding many2one against one2many is the single most useful technical concept for a functional consultant. It explains why “add a field” is sometimes ten minutes and sometimes a redesign.
Views. How a model is displayed — form, list, kanban, search, pivot. The data and its display are separate, which is why the same records appear differently in different places.
Modules. Everything is a module, including Odoo’s own apps. Customizations should always be separate modules that add to standard behaviour, never edits inside Odoo’s own code.
Developer mode
Switch it on in your own database and explore. It shows technical names, lets you inspect fields and views, and exposes the underlying settings.
The most useful habit: hover a field and read its technical name. Being able to say “the problem is on sale.order.line, the price_unit field” instead of “the price is wrong on the order screen” changes every conversation you have with a developer.
Two cautions. Do not change things in developer mode on a client system to see what happens. And developer mode is a tool for understanding, not a licence to start building.
Reading an error
When Odoo shows an error, do not screenshot it and send it on. Read it.
- The last lines are the useful ones. They name the file, the model and the specific problem.
- Distinguish the kinds. A validation message is the system enforcing a business rule — usually a configuration matter. A traceback is a genuine fault. An access error is security configuration, not a bug.
- Record how to reproduce it. Which user, which record, which steps. A developer cannot fix what they cannot reproduce, and “it sometimes fails” wastes days.
Getting good at this makes you dramatically faster, because a large share of “bugs” are configuration and you can fix them yourself.
Estimating: what is actually small
You will be asked constantly whether something is small. A rough guide:
Usually small: adding a simple field, changing a label, a new list view or filter, an automated email, a straightforward approval step, a report layout change.
Usually not small: anything touching accounting entries or stock valuation, anything that must work across companies or currencies, changes to how documents are numbered, anything involving another system, anything that must run on historical data, and anything described with the word “just”.
When unsure, say you will check. Nobody has ever been fired for coming back the next day with an accurate answer.
Knowing when to call a developer
Hand it over when:
- It touches accounting or stock valuation.
- It has to be tested and repeated across environments.
- It involves an external system.
- Several pieces of logic depend on each other.
- It must survive upgrades in a controlled way.
Keep it yourself when it is a setting, a view arrangement, an access rule, a simple automated action, or a report the existing tools already produce.
The dangerous middle is Studio. It is easy to build something in Studio that should have been a module. If you cannot explain what it does and where it lives, it should not be in Studio.
What to ask a developer for
A good request contains: the business need, the model and fields, exactly what should happen and when, what should happen in the edge cases, how it will be tested, and how urgent it is.
A bad request is “can you make the report show the right number”.
Practise this
- Turn on developer mode and find the technical names of five fields you use often.
- Trace a sales order to its delivery and its invoice, and name the models involved.
- Cause a validation error deliberately, then a real traceback, and describe the difference.
- Look at a custom module’s file structure and identify the models, views and security files.
- Write a specification for a small change, as if handing it to a developer, and ask one to review it.
Exercise 5 is the one that makes you valuable. A consultant who writes clear specifications is worth more than one who writes mediocre code.