Architecture Notes8 min read

Why Didn't Our Odoo Module Generator Build the Feature We Asked For?

OdoMate Team

Why Didn't Our Odoo Module Generator Build the Feature We Asked For?

We asked OdoMate — our AI Odoo module generator — to add a discount column to Odoo's sales report. It didn't build one, because Odoo 19 already has that column. Building a second copy would have added something that earns nothing and still has to be carried through every upgrade to come.

That is not how these tools usually behave. Ask an AI coding assistant for something and it builds it. Whether the thing needed to exist at all is not a question most of them stop to ask.

The report we asked for

Earlier this summer we generated an Odoo 19 module that applies a discount across a whole order and sends steep discounts to a manager for approval. We wrote up how it compared to an established module from the Apps Store, one with more than 21,000 downloads behind it.

Preparing that comparison, we thought we had found something our module was missing. The other module puts its own discount figures into Odoo's sales report — the screen where you break sales down by salesperson, customer, product or period. Our module, as far as we could see, contained no code that did anything of the sort.

That looked like our own generator had quietly dropped part of what we asked for. So we used OdoMate's enhancement feature — you describe what should change, attach screenshots of what you are looking at, and a new version comes back — and asked it to put the discount figures into the sales report.

The new version arrived. Again, nothing in it did that.

What OdoMate returned instead

So we went through the module's own files, to see what the round had actually changed.

The module had gained an automated check that opens Odoo's own sales report, puts a discounted order through it, and confirms the discount shows up there correctly. Beside it sat a single line of explanation: Odoo provides this measure itself.

Here is that note, exactly as it appears in the module:

def test_sale_report_discount_measure(self):
    # sale.report ships its own 'discount' measure natively (feeding its
    # discount_amount); this pins that it reflects our order-level fan-out.

Out of engineering language: Odoo already provides this figure. This check exists to make sure the discount our module applies shows up in it correctly.

The user guide had changed too, in the same round. It now says, word for word:

Sales Analysis (sale.report) exposes the same Discount % measure for quotations and orders — open Sales → Reporting → Sales, switch to pivot or graph, and add Discount % to see it alongside the standard measures.

You don't have to take our module's word for that. Odoo's own sales report defines Discount % and Discount Amount as standard measures in Odoo 19, in the platform's source code.

So rather than building the feature, it wrote down where to find the one Odoo already provides.

And there was no new reporting code anywhere in the module. Nothing had been half-built or left broken behind the scenes. What the round produced instead of a second copy of an existing report was a stated reason not to build one — and a check proving Odoo's own report works with our module.

We asked for a feature. What we actually needed was to be told the feature was already there.

Why that is unusual

The default behaviour of an AI coding assistant is compliance. You ask, it builds. That is most of what makes them useful, and it is also the failure that is hardest to catch: the code works, the tests pass, nothing about it looks wrong on review. It simply did not need to exist.

There is industry data on what that does to a codebase. GitClear analysed 623 million changed lines of code from 2023 to 2026 and found duplicated blocks of code up 81% over that period — the highest level in their records — while the share of changed lines that reorganise and reuse existing code rather than write new, what GitClear calls moved code, fell from 21% in 2022 to 3.8%.

To be precise about what that does and doesn't say: GitClear measures duplication inside a codebase, not code that duplicates something the platform already provides. It isn't a measurement of what happened to us. But it points the same direction — as these tools spread, more code is being written and less of what already exists is being reused.

What the code you didn't need actually costs

Writing code is the cheap part. Keeping it is the expensive part.

Odoo ships a major release every year, and every line your business owns has to survive each one — read, tested, and fixed wherever the platform moved underneath it. Code that duplicates something Odoo already does earns you nothing and still arrives on that bill, every year, for as long as you run it.

It also makes the pile bigger. Every extra field, screen and rule is one more thing a future Odoo change can collide with, and one more thing the next person has to understand before they can safely touch anything near it.

We watched this happen while writing the earlier comparison: a discount feature built years ago, against an older Odoo, on a report the platform now covers itself — today it no longer runs, and leaves a mislabelled column behind it. That is time doing its work rather than anyone's carelessness, and it is a bill nobody signs up for on purpose.

The part we got wrong

OdoMate's decision was right. The way it reported that decision was not.

Nothing in the summary of that round said a requested feature had been deliberately skipped, or why. The reasoning existed only as a note inside the code, where a business user would never look. We found it by opening the files, which is not a reasonable thing to expect of anyone.

That is a real gap and it is ours. When a generation round decides not to build something, it should say so plainly in its summary, with the reason. It is on the roadmap now, and this article is where it came from.

What this doesn't prove

  • This happened once. We are describing one request, on one module. We are not claiming the generator weighs up the platform before building every time — a single case is an observation, not a feature.

  • The scope is narrow. One discount workflow inside Sales. None of it transfers automatically to complicated accounting rules, or to anything that has to talk to a system outside Odoo.

  • Generated code still needs human review before production. The gap in this very story was found by a person reading files, not by the tool announcing it.

Try it on your own problem

Read the specification and the module it produced, side by side, or the full comparison against the Apps Store module.

Then bring your own requirement. Inspect the module, then request early beta access — we review requests on a rolling basis and onboard in small cohorts.

FAQ

What is an AI Odoo module generator? OdoMate is one. It is a tool you describe a business requirement to in plain language, and it produces a working Odoo module — the code, its automated checks, a user guide written for the people who will use it, and interface translation files — then installs it on a real Odoo system and tests it there. You review the result instead of writing it.

Will an AI build a feature my system already has? It can, and that is the risk worth planning for. A coding assistant treats a request as an instruction rather than as a question worth checking first, so you can get working, tested code for something the platform already gives you — and nothing on review will look wrong, because nothing is. In the case described here OdoMate did the opposite: asked for a discount measure Odoo already provides, it declined to build a second one and recorded why. That is one observation rather than a guarantee — but it is the behaviour worth asking any generator about before you buy.

Does Odoo already report on discounts? Yes. Odoo 19's sales report includes a discount measure as standard — two of them, a percentage and an amount. Open Sales → Reporting → Sales, switch to a pivot or graph, and add it.

Why does unnecessary code in an Odoo module cost money? Because you keep paying for it. Odoo releases a major version every year and everything you own has to be checked and fixed each time. Code that duplicates what Odoo already provides is a recurring cost that buys you nothing.

Can a generated module be changed without starting again? Yes — that is the platform's enhance feature. You describe what should be different and attach screenshots, and the existing module is reworked rather than regenerated from scratch. That is the round described in this article. Every version is kept — both the requirement and the modules generated from it — so you can go back to an earlier one if a round doesn't go the way you wanted.