What Odoo cannot do,
we build alongside
Odoo covers a lot, but no company fits the standard a hundred per cent. Where it pinches we make a module, as a clean extension and not as an intervention in the core.
How we build custom work
Three rules we hold to, even when it would be quicker without them.
As a separate module
Never a change in the Odoo core or in a community module. Everything sits in a module of its own with its own name, which you can switch off.
Upgradeable
We follow Odoo's own conventions, so a version upgrade does not turn into a rebuild. Custom work that blocks upgrades is a postponed problem.
With documentation and tests
Every module gets a functional description and tests. Even if we are ever gone, someone else can carry on with it.
What we are asked for most
Six kinds of custom work that keep coming back, each with an example from practice. Client names we leave out.
A link to an outside party
Orders, stock levels or statuses moving back and forth automatically with a supplier, carrier or marketplace. With error handling and a log, so you can see what went wrong.
From practiceReading orders that arrive as XML on an SFTP server straight in as sales orders. And at an electronics client: pulling product specifications and current purchase prices from suppliers such as Mouser, DigiKey and Octopart.
Reporting Odoo does not have
An overview built exactly the way your management wants to see it. As a report inside Odoo, or as an export that is ready automatically every month.
From practiceA stock movement analysis with a PDF report, and a forecast anchored on the actual stock position rather than on everything still open, with the backlog shown separately.
A process step that is missing
An approval round, an extra status, a check that has to happen before something leaves the building. Built in where people already work.
From practiceOn outgoing deliveries, first pick the loading dock and have the driver sign on screen. The delivery only moves on once packaging and carrier both check out.
Webshop functionality to measure
Tiered prices per customer, closed parts of the shop, a configurator for assembled products. Everything that makes your sales process your own.
From practiceTicking several open invoices in the customer portal and paying them in one transaction instead of one by one. And a booking wizard with time slots for appointments.
Financial custom work
A deviating VAT treatment, an invoice layout the accountant does accept, or a cost price calculation that matches the way you manufacture.
From practicePutting the right bank account on the invoice automatically based on the currency. And an invoice layout where prepayments run through the totals and BIC/SWIFT sits with the account number.
Automating manual work
The action someone performs every morning and nobody enjoys. Usually the cheapest module we ever build.
From practiceA nightly job that confirms draft sales orders, posts the matching invoices and notifies the people involved. And importing bills of material from a spreadsheet, creating the products that do not exist yet.
Two examples in close-up
What happens when you look further than “we will connect an API”. Two modules we built, and the part of each that was hard.
Purchase prices live from a components database
- Problem
- Purchase prices in Odoo are out of date the moment they are entered. For electronic components the price changes weekly, and the tiers differ per supplier.
- Built
- An integration with the Nexar/Octopart API that pulls the current supplier prices per product, price tiers included, and writes them onto the product's supplier lines.
- Manufacturer names never match exactly between two systems. That is what the alias table is for: spelling variants of the same manufacturer point at one record.
- Every synchronisation writes a log line: what was updated, what was skipped and why. Without that you have no idea what went wrong across 4,000 products.
- Price tiers got a model of their own, so a buyer can see and correct them without the next synchronisation overwriting that.
Over 3,700 lines of Python, with tests of its own.
A warehouse that rearranges itself
- Problem
- Fast movers sit at the back of the warehouse because that is where they once landed. Pickers walk half their day back and forth, and nobody gets round to rearranging it.
- Built
- An ABC analysis that ranks products by picking frequency and then assigns them to the cheapest locations, counted in walking distance, per row, level and zone.
- The result is written out as ordinary Odoo putaway rules. That keeps the standard logic in charge and leaves you free of our module: switch it off and the warehouse carries on.
- The warehouse geometry (rows, levels, zones) is modelled separately, so one metre on the ground floor weighs differently from one metre on the fourth rack.
- The calculation sits under tests, geometry included. With something like this you want to be able to show a rearrangement is right before anyone moves thousands of pallets.
Over 3,000 lines of Python, with tests on the geometry and the layout.
Built with the platform of Smart AI Bizz
Our custom work does not start on a blank page. Sister company Smart AI Bizz develops the technology we build it with, and we put that to work in every project.
A knowledge base holding the whole source
Over 167,000 indexed fragments from Odoo: code fragments, field definitions and domain patterns. Before we use a field, we know whether it exists and what it does.
A generator for the routine work
Models, views, security files and manifest come out following Odoo's own conventions. Our hours go to the logic that actually matters.
And after that, plain review
Nothing reaches a client environment unseen. Every module is checked, tested and functionally described; the generator does not skip that step.
First check whether it is really needed
The cheapest custom work is the custom work we do not build. Before we program anything we look at whether it can be done with the standard: with a different setup, an automated action or a setting you did not know about.
Only when that genuinely does not work do we write code. That saves you money now and maintenance later.
- Standard first: if configuration can do it, that is what we do.
- Then configuration: automated actions, server actions, report templates.
- Only then code: and then properly, with tests and documentation.
- Always yours: the source of your custom work is yours, not a black box.
Curious what your Odoo project would cost?
An hour of introduction costs nothing and always yields something: at the very least an honest picture of what is and is not possible. If the project lends itself to it, you get a proposal with a single figure underneath.