Why these three words

Every screen you use in Odoo is made of the same three things. Once you know them, “we need a field on the sales order” and “the list view is missing a column” stop being mysterious phrases and become specific requests.

This article is for people who commission or discuss Odoo work, not for people writing it. No code required.

Models

A model is a type of thing.

A customer is a model. A product is a model. A sales order is a model. A journal entry is a model.

Each one is a table in the database, holding many records — the individual customers, products and orders.

When a developer says “the sale.order model”, they mean the sales order. When they say “a new model”, they mean a new type of thing that did not exist before.

Two useful facts:

Some models are shared. Customers, suppliers and contacts are all the same model, distinguished by flags. One company that both buys from you and sells to you is one record, not two.

Some are split. Products have a template and variants. A shirt is the template; each size and colour is a variant with its own stock.

Fields

A field is a piece of information on a model.

A customer has a name, an email, an address, a payment term. Each is a field.

The types matter more than they sound, because they determine what a field can do.

Text and numbers. Straightforward.

Selection. A fixed list of options — a state, a priority, a type.

Relational. A link to another record. The customer on a sales order is not text; it is a link to a customer record. That link is why the address, price list and payment terms fill in automatically.

Computed. Calculated from other fields rather than typed. An order total is computed from its lines.

A computed field cannot usually be typed into. If somebody asks why they cannot edit a total, this is why — and the answer is to change what it is computed from.

Views

A view is how a model appears on screen. The same data can be shown several ways.

Form. One record in detail. What you see when you open a customer.

List. Many records in rows. What you see when you open the Customers menu.

Kanban. Cards in columns. Used for pipelines and stages.

Calendar. Records on dates.

Pivot and graph. Aggregated data for reporting.

Search. The filter panel — filters, groupings and the search box.

A model can have several views of each type. That is how the same sales order can look one way to a salesperson and another way in a report.

The practical point: “add a column to the list” and “add a field to the form” are different requests, even though both concern the same field. A field can exist on the model and not appear on a particular view.

How they fit together

Take a sales order.

The model is `sale.order`. It holds the customer link, dates, state and totals. Order lines are a separate model linked to it.

Fields include customer, order date, salesperson, state, total. Some are typed, some are computed, some are links.

Views include the form you edit, the list you scan, the kanban board grouped by state, and the pivot for reporting.

When you ask for “a field on the sales order”, you are asking for two things: a new field on the model, and that field placed on one or more views.

Worth being explicit about the second part, because it is where requests get misunderstood. A field added and not placed on any view exists and is invisible.

Customisation, in these terms

Now the levels of customisation make more sense.

Configuration changes settings, not models or fields.

Studio adds fields and places them on views, by dragging.

A custom module adds fields, adds logic behind computed fields, modifies views, and can create entirely new models.

Inheritance is how a module changes an existing model without copying it. It says: take the sales order, and add this field, and change this calculation. Your changes are a layer on top rather than a replacement — which is why an upgrade re-applies them instead of wiping them.

Why some things are blocked

Two familiar refusals, explained in these terms.

You cannot change a product’s unit of measure once it has transactions. The unit is referenced by every stock move and order line. Changing it would make those records wrong.

You cannot delete a customer with invoices. The invoices hold a relational field pointing at that customer. Deleting it would leave them pointing at nothing.

Both are protections, not obstacles. And in both cases archiving is the right answer.

Reports

A printed report — an invoice PDF, a delivery note — is a template that reads fields from a record and lays them out.

Which means: if a field exists on the model, it can usually be added to a report. If it does not exist, that is a bigger request.

When asking for a report change, say which fields you want and where. “Add the customer’s VAT number under the address” is a request somebody can act on.

What this gives you

Three practical benefits from knowing the vocabulary.

Clearer requests. “Add a date field called Site Visit Date to the opportunity form and show it as a column in the pipeline list” is something a developer can build without a meeting.

Better estimates. Adding a field to an existing model is small. Creating a new model with its own views and permissions is not. Knowing the difference tells you which you are asking for.

Fewer surprises. When somebody says a change requires modifying a view rather than adding a field, you know those are different pieces of work.

The short version

Models are types of thing. Fields are the information on them. Views are how they appear.

Every Odoo screen is those three. Custom work adds fields to models and places them on views.

When you ask for something, say both parts — what the field holds, and where it should appear. That one habit removes most of the back-and-forth in customisation requests.