{"id":36340,"date":"2026-03-21T11:18:22","date_gmt":"2026-03-21T11:18:22","guid":{"rendered":"https:\/\/tenthplanet.in\/odoo\/?p=36340"},"modified":"2026-03-21T11:22:23","modified_gmt":"2026-03-21T11:22:23","slug":"odoo-customization-best-practices-the-5s-framework-for-developers","status":"publish","type":"post","link":"https:\/\/tenthplanet.in\/odoo\/product\/odoo-customization-best-practices-the-5s-framework-for-developers\/","title":{"rendered":"Odoo Customization Best Practices: The 5S Framework for Developers"},"content":{"rendered":"

5S Framework <\/b>is a technical documentation standard used for\u00a0Odoo Architects and Developers to bridge the gap between functional requirements and high-quality code. This framework ensures that every customization is documented with precision, covering the UI, logic, automation, database structure, and data retrieval.<\/span><\/p>\n

Each layer answers one core question:<\/h2>\n\n\n\n\n\n\n\n\n
Layer<\/th>\nAnswers<\/th>\nOutput<\/th>\n<\/tr>\n
Screen<\/strong><\/td>\nWhat does the user see?<\/em><\/td>\nXML views, fields, layouts<\/td>\n<\/tr>\n
Pseudo Code<\/strong><\/td>\nWhat does the system think?<\/em><\/td>\nLogic in plain English before Python<\/td>\n<\/tr>\n
Script<\/strong><\/td>\nWhat runs automatically?<\/em><\/td>\nAutomations, cron jobs, workflows<\/td>\n<\/tr>\n
Schema<\/strong><\/td>\nHow is data stored?<\/em><\/td>\nPython models, field types, relations<\/td>\n<\/tr>\n
SQL<\/strong><\/td>\nHow is data retrieved?<\/em><\/td>\nRaw queries, reports, dashboards<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

5S Framework\u00a0for Odoo<\/h2>\n

Here’s a clean visual overview of the 5S Framework, followed by a breakdown of each layer.<\/span><\/p>\n

<\/p>\n

The golden rule of 5S<\/strong> is that you work top-to-bottom, never jumping ahead. You don’t write Python until the Screen is documented. You don’t write SQL until the Schema is defined. This prevents the most common Odoo mistake \u2014 developers writing code before they’ve agreed on what the field is called or where it lives.<\/span><\/p>\n

Here’s how each layer maps to actual files inside your custom Odoo module<\/span>:<\/p>\n\n\n\n\n\n\n\n\n
Layer<\/b><\/td>\nName<\/b><\/td>\nFocus<\/b><\/td>\nOutput<\/b><\/td>\nOdoo Artifact<\/b><\/td>\n<\/tr>\n
S1<\/td>\nScreen<\/td>\nUI\/UX<\/td>\nXML views<\/td>\nir.ui.view<\/td>\n<\/tr>\n
S2<\/td>\nPseudo Code<\/td>\nLogic<\/td>\nPython code<\/td>\nmodels.Model<\/td>\n<\/tr>\n
S3<\/td>\nScript<\/td>\nAutomation<\/td>\nCron \/ triggers<\/td>\nir.cron \/ ir.actions<\/td>\n<\/tr>\n
S4<\/td>\nSchema<\/td>\nDatabase<\/td>\nModel definition<\/td>\nmodels.Model (_name)<\/td>\n<\/tr>\n
S5<\/td>\nSQL<\/td>\nReporting<\/td>\nPostgreSQL view<\/td>\nSQL + read-only model<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

1\ufe0f\u20e3<\/i><\/p>\n

\n

Screen \u2014 UI & Field Mapping<\/b><\/span><\/h2>\n

XML views \u00b7 form \u00b7 tree \u00b7 kanban \u00b7 xpath inheritance<\/span><\/p>\n<\/div>\n<\/div>\n

What is Screen?<\/h2>\n

The Screen phase defines how the user interacts with the system. In Odoo, this translates directly to XML view definitions. Before writing a single line of Python, the developer documents which fields exist, where they appear in the UI, and who can see or edit them.<\/span><\/p>\n

Key decisions in Screen<\/b><\/h3>\n\n\n\n\n\n\n\n\n
Decision<\/b><\/td>\nWhat to document<\/b><\/td>\n<\/tr>\n
View type<\/td>\nForm (edit one record), Tree\/List (browse many), Kanban (card layout), Pivot (reports)<\/td>\n<\/tr>\n
Field type<\/td>\nChar, Float, Many2one, Selection, Boolean, Monetary, Html, Date<\/td>\n<\/tr>\n
Inheritance<\/td>\nWhich existing Odoo view ID is being inherited (use xpath expressions)<\/td>\n<\/tr>\n
Visibility<\/td>\nattrs=invisible \/ readonly per user group or field value<\/td>\n<\/tr>\n
Permissions<\/td>\nWhich groups (Sales Manager, Inventory User) see or edit the field<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Example \u2014 adding commission fields to sale.order form<\/h3>\n

Scenario: Add a Commission Rate and Commission Total field to the Sales Order form view.<\/span><\/p>\n\n\n\n\n\n
Technical name<\/b><\/td>\nLabel<\/b><\/td>\n<\/tr>\n
x_comm_rate<\/td>\nCommission %<\/td>\n<\/tr>\n
x_comm_total<\/td>\nTotal Commission<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

2\ufe0f\u20e3<\/i><\/p>\n

\n

Pseudo Code \u2014 Business Logic<\/span><\/h1>\n

Python \u00b7 @api.depends \u00b7 @api.constrains \u00b7 UserError<\/span><\/p>\n<\/div>\n<\/div>\n

What is Pseudo Code?<\/b><\/h2>\n

Before writing actual Python, every developer must document the logic in plain, structured English. This ensures that business rules are agreed upon before implementation begins \u2014 preventing costly rewrites when requirements are misunderstood.<\/span><\/p>\n

Logic types<\/b><\/h3>\n\n\n\n\n\n\n\n\n
Type<\/b><\/td>\nWhen to use<\/b><\/td>\n<\/tr>\n
Computed field (@api.depends)<\/td>\nAuto-recalculates a field value when a source field changes. Use store=True to save to DB.<\/td>\n<\/tr>\n
Constraint (@api.constrains)<\/td>\nRaises a ValidationError to block saving invalid data (e.g. credit limit exceeded).<\/td>\n<\/tr>\n
Onchange (@api.onchange)<\/td>\nUpdates the UI instantly before saving (useful for live feedback to the user).<\/td>\n<\/tr>\n
Override (super())<\/td>\nExtend Odoo built-in methods like action_confirm or write to inject custom logic.<\/td>\n<\/tr>\n
UserError<\/td>\nRaise a user-facing error message to halt an operation with a clear explanation.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Example \u2014 commission total computed field<\/span><\/h3>\n

Pseudo logic: If the order is in state ‘sale’ or ‘done’, calculate commission as untaxed amount \u00d7 rate. If no rate is set, default to 10%. Otherwise set commission to zero.<\/span><\/p>\n

\n

3\ufe0f\u20e3<\/i><\/p>\n

\n

Script \u2014 Automation & Scheduled Actions<\/b><\/span><\/h1>\n

Cron jobs \u00b7 automated actions \u00b7 server actions \u00b7 API sync<\/span><\/p>\n<\/div>\n<\/div>\n

What is Script?<\/b><\/h2>\n

Script refers to automated actions and background processes that keep the ERP running without manual intervention. The focus is: who does what, in what order. This covers scheduled jobs, event-based triggers (on create \/ on update \/ on delete), server actions tied to buttons, and external API integrations.<\/span><\/p>\n

Script types<\/b><\/h3>\n\n\n\n\n\n\n\n
Type<\/b><\/td>\nDescription<\/b><\/td>\n<\/tr>\n
Automated Action<\/td>\nTriggers on record creation, update, or deletion. Configured in Settings \u2192 Technical \u2192 Automation.<\/td>\n<\/tr>\n
Scheduled Action (Cron)<\/td>\nRuns at a fixed interval (hourly, daily, monthly). Ideal for reports, syncs, and digest emails.<\/td>\n<\/tr>\n
Server Action<\/td>\nMulti-step process triggered by a button click (e.g. Batch Validate, Send Reminders).<\/td>\n<\/tr>\n
External API Script<\/td>\nMaps the data flow for third-party integrations (Shopify, WooCommerce, payment gateways).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Workflow example \u2014 sales order lifecycle<\/b><\/h3>\n\n\n\n\n\n\n\n\n\n\n\n\n
Step<\/b><\/td>\nActor & Action<\/b><\/td>\n<\/tr>\n
1<\/td>\nSales Executive creates quotation<\/td>\n<\/tr>\n
2<\/td>\nCustomer confirms quotation (portal or email)<\/td>\n<\/tr>\n
3<\/td>\nSales Executive converts to Sales Order<\/td>\n<\/tr>\n
4<\/td>\nSystem automatically checks stock availability<\/td>\n<\/tr>\n
5a (stock available)<\/td>\nSystem creates Delivery Order \u2192 Warehouse validates<\/td>\n<\/tr>\n
5b (stock unavailable)<\/td>\nSystem creates backorder, notifies warehouse<\/td>\n<\/tr>\n
6<\/td>\nInvoice generated after delivery confirmation<\/td>\n<\/tr>\n
7<\/td>\nAccounts records payment \u2192 order marked as paid<\/td>\n<\/tr>\n
Exception<\/td>\nIf payment overdue \u2192 block new orders for that customer<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/div>\n
\n

4\ufe0f\u20e3<\/i><\/p>\n

\n

Schema \u2014 Database & Model Structure<\/b><\/span><\/h1>\n

models.Model \u00b7 Many2one \u00b7 One2many \u00b7 ondelete strategy<\/span><\/p>\n<\/div>\n<\/div>\n

What is Schema?<\/b><\/h2>\n

Schema is the blueprint of the data layer. In Odoo, this means Python model class definitions \u2014 which become real PostgreSQL tables via the ORM. Field types, relationships between models, and deletion rules all need to be thought through before writing code.<\/p>\n

_inherit vs _name \u2014 the most important distinction<\/b><\/h3>\n\n\n\n\n\n\n
Keyword<\/b><\/td>\nBehaviour<\/b><\/td>\n<\/tr>\n
_inherit = ‘sale.order’<\/td>\nAdds fields\/methods to an existing model and its table. No new table is created.<\/td>\n<\/tr>\n
_name = ‘commission.history’<\/td>\nCreates a brand new model with its own PostgreSQL table.<\/td>\n<\/tr>\n
Both together<\/td>\nCopies the existing model into a new one (prototype inheritance \u2014 rarely used).<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Relation types<\/b><\/h3>\n\n\n\n\n\n\n
Type<\/b><\/td>\nMeaning & Example<\/b><\/td>\n<\/tr>\n
Many2one<\/td>\nMany records link to one parent. e.g. sale.order \u2192 res.partner (customer).<\/td>\n<\/tr>\n
One2many<\/td>\nOne parent has many children. e.g. sale.order \u2192 sale.order.line (order lines).<\/td>\n<\/tr>\n
Many2many<\/td>\nCross-links between two models. e.g. product.template \u2194 product.tag.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

5\ufe0f\u20e3<\/i><\/p>\n

\n

SQL \u2014 Reporting & Data Queries<\/b><\/span><\/h1>\n

PostgreSQL views \u00b7 JOIN \u00b7 GROUP BY \u00b7 read-only Odoo model<\/span><\/p>\n<\/div>\n<\/div>\n

What is SQL?<\/b><\/h2>\n

While Odoo uses an ORM (Object-Relational Mapper) for most operations, complex reporting often requires raw SQL for performance. The SQL layer is used to build management dashboards by creating PostgreSQL VIEWs and exposing them as read-only Odoo models accessible via pivot and graph views.<\/span><\/p>\n

When to use raw SQL<\/b><\/h3>\n\n\n\n\n\n\n\n
Scenario<\/b><\/td>\nReason<\/b><\/td>\n<\/tr>\n
Cross-module reports<\/td>\nJoin Sales + Accounting + Inventory in a single query \u2014 ORM can’t do this cleanly.<\/td>\n<\/tr>\n
Aggregation at scale<\/td>\nSUM, COUNT, AVG across thousands of records is far faster in native SQL.<\/td>\n<\/tr>\n
Management dashboards<\/td>\nRead-only model backed by a PostgreSQL VIEW for pivot\/graph views.<\/td>\n<\/tr>\n
Performance tuning<\/td>\nBypass ORM overhead for high-volume analytics queries.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/div>\n

Example<\/h2>\n

Let’s\u00a0look at how all\u00a05 layers connect in a real Odoo customization project \u2014 the complete flow from requirement to deployed feature<\/span><\/p>\n

<\/p>\n

Putting It All Together \u2014 Module Structure<\/b><\/h1>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
File \/ Folder<\/b><\/th>\n5S Layer & Purpose<\/b><\/th>\n<\/tr>\n
__manifest__.py<\/td>\nModule metadata \u2014 name, version, depends, data file list<\/td>\n<\/tr>\n
models\/sale_order.py<\/td>\nS2 Pseudo Code + S4 Schema \u2014 extends sale.order with commission fields and computed logic<\/td>\n<\/tr>\n
models\/commission_history.py<\/td>\nS4 Schema \u2014 new commission.history model with its own table<\/td>\n<\/tr>\n
views\/sale_commission_views.xml<\/td>\nS1 Screen \u2014 XML view inheriting sale.order form, adding commission fields<\/td>\n<\/tr>\n
views\/commission_report_views.xml<\/td>\nS5 SQL \u2014 pivot and graph views for the commission analysis report<\/td>\n<\/tr>\n
data\/cron_commission.xml<\/td>\nS3 Script \u2014 scheduled action for monthly commission digest email<\/td>\n<\/tr>\n
data\/automated_action.xml<\/td>\nS3 Script \u2014 event-based trigger (e.g. on order confirmation)<\/td>\n<\/tr>\n
report\/commission_analysis.py<\/td>\nS5 SQL \u2014 read-only Odoo model backed by PostgreSQL view<\/td>\n<\/tr>\n
report\/commission_analysis.sql<\/td>\nS5 SQL \u2014 raw SQL for the PostgreSQL VIEW (optional separate file)<\/td>\n<\/tr>\n
security\/ir.model.access.csv<\/td>\nAccess rights \u2014 which user groups can read\/write each model<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

5S Framework is a technical documentation standard used for\u00a0Odoo Architects and Developers to bridge the gap between functional requirements and […]<\/p>\n","protected":false},"author":9,"featured_media":36341,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[9],"tags":[],"class_list":["post-36340","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product"],"acf":[],"_links":{"self":[{"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/posts\/36340","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/comments?post=36340"}],"version-history":[{"count":0,"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/posts\/36340\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/media\/36341"}],"wp:attachment":[{"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/media?parent=36340"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/categories?post=36340"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tenthplanet.in\/odoo\/wp-json\/wp\/v2\/tags?post=36340"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}