Odoo Customization
Odoo ships a new version every year. Work built the quick way has to be rebuilt every time, which is why so many businesses sit stranded on an old release.
Why It Matters
Everything we build goes into one versioned module that extends the standard models through inheritance.
Plenty of requests turn out to be a setting, an automated action or a maintained app somebody has already published.
We look at the process behind the request, not just the screen you want changed.
Configuration, existing app or custom module, with a fixed price and date.
Work goes into your custom module, versioned, reviewed and documented.
You try it on a staging database with your own data before production.
We release, record the change and watch it through the first full cycle.
All your changes in a single versioned module, so standard and custom never blur together.
We extend standard models rather than editing them, which is what keeps upgrades routine.
Nothing reaches production until it has run on a copy of your live database.
Each change records what it does and why, so the next developer is not guessing.
A backup before every release and a tested route back if something is wrong.
The module lives in a repository you own, so you are never tied to one vendor.
If a setting or an existing app solves it, we say so. Less custom work is a simpler system.
We write Python and XML against the Odoo ORM, not just click through Studio.
Our customers move up versions without rebuilding their customizations each year.
Every request is quoted before work starts, so the invoice holds no surprises.
We take on existing databases, review what is there and make them supportable again.
Custom fields and new models, form, list and kanban views, automated and server actions, approval rules, QWeb report layouts, dashboards, access rights and record rules, and complete custom modules written in Python and XML on the Odoo framework.
Not when it is built as a proper module. We keep everything in a versioned custom module that inherits from standard models rather than editing them, so an upgrade means testing and adjusting your module against the new release instead of rebuilding it. Changes made directly to core files are what make upgrades painful.
Studio is good for straightforward field and view changes, and it is quick, but it is Enterprise only and its output is harder to review, version and migrate. We use Studio where the change is simple and a proper module once there is business logic involved, and we tell you which route we are taking and why.
Often, and it is usually cheaper. We check whether a maintained third-party module already covers the requirement, then review its code quality and version support before recommending it. A badly maintained app becomes your problem at the next upgrade, so we do look before suggesting one.
It depends on the requirement. A custom field or a report layout is small. A module with its own models, workflow and integrations is a project. We scope each request and give a fixed price and date before any development starts.
Yes. The module sits in your repository and on your database, with documentation. You can maintain it in-house or hand it to another partner at any time.
Related
The other services in this section, and related pages from TCB Infotech.
No commitment. A straight answer on what your change really needs.
