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.<\/p>\n
This article is for people who commission or discuss Odoo work, not for people writing it. No code required.<\/p>\n
A model<\/strong> is a type of thing.<\/p>\n A customer is a model. A product is a model. A sales order is a model. A journal entry is a model.<\/p>\n Each one is a table in the database, holding many records<\/strong> \u2014 the individual customers, products and orders.<\/p>\n 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.<\/p>\n Two useful facts:<\/strong><\/p>\n Some models are shared.<\/strong> 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.<\/p>\n Some are split.<\/strong> Products have a template and variants. A shirt is the template; each size and colour is a variant with its own stock.<\/p>\n A field<\/strong> is a piece of information on a model.<\/p>\n A customer has a name, an email, an address, a payment term. Each is a field.<\/p>\n The types matter more than they sound<\/strong>, because they determine what a field can do.<\/p>\n Text and numbers.<\/strong> Straightforward.<\/p>\n Selection.<\/strong> A fixed list of options \u2014 a state, a priority, a type.<\/p>\n Relational.<\/strong> 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.<\/p>\n Computed.<\/strong> Calculated from other fields rather than typed. An order total is computed from its lines.<\/p>\n A computed field cannot usually be typed into.<\/strong> If somebody asks why they cannot edit a total, this is why \u2014 and the answer is to change what it is computed from.<\/p>\n FIGURE 1: THE THREE WORDS<\/p>\n Model<\/p>\n Field<\/p>\n View<\/p>\n A view<\/strong> is how a model appears on screen. The same data can be shown several ways.<\/p>\n Form.<\/strong> One record in detail. What you see when you open a customer.<\/p>\n List.<\/strong> Many records in rows. What you see when you open the Customers menu.<\/p>\n Kanban.<\/strong> Cards in columns. Used for pipelines and stages.<\/p>\n Calendar.<\/strong> Records on dates.<\/p>\n Pivot and graph.<\/strong> Aggregated data for reporting.<\/p>\n Search.<\/strong> The filter panel \u2014 filters, groupings and the search box.<\/p>\n A model can have several views of each type.<\/strong> That is how the same sales order can look one way to a salesperson and another way in a report.<\/p>\n The practical point:<\/strong> “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.<\/p>\n Take a sales order.<\/p>\n The model<\/strong> is `sale.order`. It holds the customer link, dates, state and totals. Order lines are a separate model linked to it.<\/p>\n Fields<\/strong> include customer, order date, salesperson, state, total. Some are typed, some are computed, some are links.<\/p>\n Views<\/strong> include the form you edit, the list you scan, the kanban board grouped by state, and the pivot for reporting.<\/p>\n 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.<\/p>\n Worth being explicit about the second part<\/strong>, because it is where requests get misunderstood. A field added and not placed on any view exists and is invisible.<\/p>\n FIGURE 2: WHAT TO ASK FOR CLEARLY<\/p>\n The field itself<\/p>\n Where it appears<\/p>\n Who can see it<\/p>\n Now the levels of customisation make more sense.<\/p>\n Configuration<\/strong> changes settings, not models or fields.<\/p>\n Studio<\/strong> adds fields and places them on views, by dragging.<\/p>\n A custom module<\/strong> adds fields, adds logic behind computed fields, modifies views, and can create entirely new models.<\/p>\n Inheritance<\/strong> 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 \u2014 which is why an upgrade re-applies them instead of wiping them.<\/p>\n Two familiar refusals, explained in these terms.<\/p>\n You cannot change a product’s unit of measure once it has transactions.<\/strong> The unit is referenced by every stock move and order line. Changing it would make those records wrong.<\/p>\n You cannot delete a customer with invoices.<\/strong> The invoices hold a relational field pointing at that customer. Deleting it would leave them pointing at nothing.<\/p>\n Both are protections, not obstacles.<\/strong> And in both cases archiving is the right answer.<\/p>\n A printed report \u2014 an invoice PDF, a delivery note \u2014 is a template that reads fields from a record and lays them out.<\/p>\n Which means:<\/strong> 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.<\/p>\n When asking for a report change<\/strong>, say which fields you want and where. “Add the customer’s VAT number under the address” is a request somebody can act on.<\/p>\n FIGURE 3: REQUESTS THAT ARE CLEAR AND ONES THAT ARE NOT<\/p>\n Clear<\/p>\n Unclear<\/p>\n Three practical benefits from knowing the vocabulary.<\/p>\n Clearer requests.<\/strong> “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.<\/p>\n Better estimates.<\/strong> 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.<\/p>\n Fewer surprises.<\/strong> When somebody says a change requires modifying a view rather than adding a field, you know those are different pieces of work.<\/p>\n Models<\/strong> are types of thing. Fields<\/strong> are the information on them. Views<\/strong> are how they appear.<\/p>\n Every Odoo screen is those three. Custom work adds fields to models and places them on views.<\/p>\n When you ask for something, say both parts<\/strong> \u2014 what the field holds, and where it should appear. That one habit removes most of the back-and-forth in customisation requests.<\/p>\n Struggling to describe what you need changed?<\/p>\n Get in touch. Tell us what the information is and where you want to see it \u2014 that is enough for us to scope it properly.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":3,"featured_media":9098,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9097","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\nFields<\/h2>\n
\n
\n
\n
Views<\/h2>\n
How they fit together<\/h2>\n
\n
\n
\n
Customisation, in these terms<\/h2>\n
Why some things are blocked<\/h2>\n
Reports<\/h2>\n
\n
\n
What this gives you<\/h2>\n
The short version<\/h2>\n