A purchasing officer enters a supplier reference once. Sales and finance see it on the same record and can trace the order through to the invoice. The owner receives an alert only when a case falls outside the agreed rule. That is the outcome worth customising for, and a new field sitting apart from the rest of the cycle does not deliver it. The route there starts with choosing the right layer: existing configuration, a Studio field and view, a scoped custom module, or an integration with an outside system.
ToDoOps works with Saudi businesses on needs analysis, Odoo application setup, agreed development, data migration, training and support by agreement. We start from the process you want to improve, not from the tool.
Which layer delivers your outcome?
- Configuration: options, permissions, routes, price rules and documents already in the applications. Usually the shortest path, and it still needs documentation and testing.
- Studio: new fields and adjusted views to match how your team works.
- A custom module: behaviour that configuration and Studio do not cover, with specifications, tests and maintenance.
- An integration: orders and statuses exchanged with another platform, with record ownership and error handling.
Take a real transaction and note where the standard path breaks. Run it with the account of the person who owns the step, including the exception that triggered the request. If configuration works, you have the smallest commitment.
What does Studio add, and what stays outside it?
Studio can add a new field, add an existing field to a view, change field properties and remove a field from a view (Odoo 19.0). The data a field stores is separate from the widget that presents it. A supplier-reference field stores and displays the reference. Preventing duplicates, importing, enforcing approval or linking accounting is separate behaviour that is designed and tested on its own.
On plans, our review on 27 October 2026 showed Studio included in the Custom plan and not in Standard, with Odoo.sh hosting priced separately. We check the plan before shaping a proposal.
Studio customisations can be exported and imported into a database on the same Odoo version with the same apps. Underlying app dependencies are not added to the package automatically. The export settings can include selected model data when required (Odoo 19.0). A reviewed change package is therefore transferable, provided the target is checked first.
When do you need a custom module?
When the behaviour needs logic beyond configuration and Studio, such as a multi-document approval rule or a specialised calculation. Hosting matters here. Odoo Online is not compatible with non-standard apps, so server-side modules are assessed against Odoo.sh or an appropriately managed on-premise or other supported deployment (Odoo 19.0). This does not stop Studio customisation on Online.
A custom module extends standard code, and its source may need adapting when standard fields, views or methods change. So we agree upgrade responsibility at the start and rehearse on upgraded data before production. Installing on an empty database alone is not enough (Odoo 19.0). A maintained inventory of changes keeps the investment useful through every upgrade.
How do three layers work in one requirement?
A business needs three things:
- Record the customer’s purchase-order reference. That is a field.
- Show it on an agreed document. That is a view or report change, as the document requires.
- Exchange the order and its status with a separate platform. That is an integration, with field mapping, error handling and a named owner for each record.
The value shows when an order passes from sales to stock to invoice. You can see that connection in Try Odoo interactively, a guided simulation with fictional data for a sales and stock flow. It introduces the workflow; your exact configuration is then scoped and tested.
An integration also has a life cycle. We define which system owns each customer, item and order, how the latest version is recognised, and how rejections, outages and cancellations are handled. Credentials are managed securely and errors have an owner.
Is the change worth building? An example with assumed numbers
Suppose a tested change removes two minutes from a repeated step across 15 transactions a day, over 240 working days a year. Capacity released = 15 × 2 × 240 ÷ 60 = 120 hours a year. These are assumed inputs, not observed ToDoOps or customer performance.
The hours become a financial saving when they remove paid overtime or external work, or when the released capacity produces a demonstrable contribution. We do not put a cash value on all time. The example helps you decide whether a useful change deserves estimating and testing. It is not a quoted result. For a wider view of implementation budget and time, the optional calculators for Odoo implementation cost and savings are available, and you do not need them before contacting us.
From idea to handover
We keep the sequence simple: scope the change, work on an example that represents your transactions, demonstrate the result, have users accept it, then deliver written handover documentation. Contractually we agree who owns your data and how it is exported, who holds the source and change documentation, and how they pass to another team if needed. Licences vary by module, so each is stated in the agreement.
NIST SP 800-218 (Version 1.1, final February 2022) recommends secure development practices and gives buyers and suppliers a common vocabulary (NIST). We use it to agree review, testing and maintenance responsibilities early. The testing guide helps turn a request into clear acceptance cases.
Frequently asked questions
Should I always start with Studio because it is easiest?
Start with standard configuration, then Studio for fields and views. Use a custom module when the behaviour goes beyond both.
Can I move Studio changes to another environment?
Yes, through export and import between databases on the same version and apps. We review the package and its dependencies and test in the target before accepting it.
What should I prepare before asking for an estimate?
A real transaction, who performs each step, the result you want changed and the hardest exception. That lets configuration, Studio, development and integration be compared on one basis.
References
- Odoo 19.0 Documentation: Studio – Fields and widgets; Studio – Models, modules and apps; Administration – Hosting; Developer – Upgrade a customized database. The version reference for Studio capabilities, hosting boundaries and upgrade testing.
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. Final version, February 2022. A general framework giving buyers and suppliers a shared vocabulary for secure development.
Next step
The right customisation can be small and still have a large effect when it is tied to an outcome you care about. Get to know the ToDoOps Odoo solution, browse the Odoo apps and the sectors on our industries page, or try the calculators for a quick estimate. If you have a transaction you want to improve, contact ToDoOps to talk through your current process and the result you want.