Configuration: where a user becomes a consultant

Up to now you have been learning what Odoo does. This stage is about deciding how it should behave for one particular company — which is the actual job.

The settings with the widest blast radius

Some settings affect one screen. These affect everything, and several are difficult or impossible to change later.

Decision	Why it is hard to reverse
Chart of accounts and localization	Everything posts into it. Changing it after transactions exist is a project of its own.
Costing method and valuation	Set per product category. Changing it revalues stock and moves the ledger.
Multi-company structure	Whether two entities are one database or two shapes every later decision.
Lot or serial tracking	Easy to enable on an empty product, painful once stock exists.
Units of measure	Changing a product’s unit after transactions is not a small edit.
Warehouse steps	Users learn a routine; changing it means retraining everyone.
Document sequences	Auditors care about numbering. Renumbering afterwards is unpleasant.

Slow down on these. Ask more questions than feel necessary, write the answer down, and get it agreed before building.

Multi-company

Clients with several legal entities always ask for “one system”. What they mean varies enormously.

Establish:

• Are they separate legal entities with separate books, or branches of one?
• Do they trade with each other? Inter-company transactions need deliberate setup.
• What is shared — products, customers, employees — and what is not?
• Who sees which company’s data?
• One chart of accounts or several? Different currencies?

Getting this wrong is one of the few errors that can require starting again. Take the time.

Access rights

The area beginners skip and clients care about most, because it is about trust and money.

Three layers, and the difference matters:

• Groups — what kind of user someone is. Access is granted by adding a user to groups, never by editing a user directly.
• Access rights — what a group may do to a type of record: read, write, create, delete.
• Record rules — which specific records a group may see. “Salespeople see only their own opportunities” is a record rule.

Two rules of practice. Start restrictive and open up; going the other way means taking access away from people who have grown used to it. And always test as the user, not as administrator — the administrator bypasses record rules, so testing as admin proves nothing.

Product categories

A quiet setting with a large effect. Categories usually drive stock valuation and the accounts that stock movements post to. Design them around how the business needs to see value and cost, not around a marketing hierarchy.

Two products that must be valued differently or post to different accounts belong in different categories, even if the sales team thinks of them as the same thing.

Automation, and when to stop

Automated actions react to changes — send an email when a stage changes, set a field when a condition is met, create a follow-up activity. Approval rules add sign-off steps. Server actions do more.

This is the boundary between configuration and development, and it needs judgment.

Configuration and Studio are right when the need is small, stable, and the client may want to adjust it. Write a real module instead when the logic is complex, it must be tested, it must move between databases in a controlled way, or several pieces depend on each other.

The failure mode is a database with fifty undocumented Studio changes that nobody can explain and nobody dares upgrade. Avoiding that is your responsibility, not the client’s.

Write down why

The habit that separates a professional from an enthusiast.

For every non-obvious decision, record: what was decided, why, what the alternative was, and who agreed it. A short document, kept with the project.

In eighteen months someone will ask why stock valuation is set this way. Without notes, the honest answer is “nobody remembers”, and the system slowly becomes something people are afraid to touch.

Practise this

1. Set up a company from an empty database: localization, journals, taxes, a small chart of accounts, product categories with automated valuation, and a warehouse. Time yourself.
2. Do it again for a two-company group sharing products but not customers.
3. Create three user groups — salesperson, warehouse, accountant — and test each by logging in as them.
4. Write a record rule so salespeople see only their own customers, then verify it as that user.
5. Build an automated action that notifies a manager when an order exceeds a value.
6. Write the configuration notes for what you built, as though handing it to another consultant.

Exercise 6 is the one people skip and the one that matters. If your notes cannot be followed by someone who was not there, they are not notes.