In brief ANOR chose not to carry its 'Purchase linked to project' module into recent versions of Odoo, because the native functionality now covers this need without any additional development. Maintaining a module that has become redundant represents a real cost, always passed on to the client. Removing what no longer serves a purpose is a quality decision, not an admission of weakness.
A job, a purchase and a link that gets forgotten
Imagine a site manager ordering supplies in a hurry. He enters the purchase order, sets the quantity and confirms. The relevant project? He'll add it later. Often, 'later' never comes.
The result: the expense exists in Odoo but floats without any assignment. The job margin shown at the end of the month is wrong. And the error only becomes visible at close-off, when it's too late to draw any operational lesson from it.
That is exactly the problem our 'Purchase linked to project' module solved. It allowed a purchase order to be created directly from the project, already linked to its job, with no manual entry required. The risk of forgetting disappeared. Profitability tracking became reliable. This module gave real value.
Why we decided not to carry it forward
With every new version of Odoo, we review our modules one by one. The question is always the same: does this module still deserve to exist in this version?
For 'Purchase linked to project', the answer was no. Odoo had evolved. The native functionality now covers this need satisfactorily, without any additional development. The module we chose not to carry forward is not a failing module: it is a module that had become redundant.
Keeping a redundant module has a real cost. It needs checking with every update, explaining to every new consultant and, above all, maintaining. That work always ends up being paid for by the client. We prefer to retire what no longer serves a purpose rather than keep it out of habit.
Five principles that guide every development
This decision illustrates how we approach all our projects. Five principles apply consistently.
- The business need before the tool. We start by understanding the real need of the organisation. A module only has value if it fills a genuine gap.
- A written specification before any build. Every specific development starts from a precise specification, reviewed and validated with the client. It describes the need in plain language and states what must not be done.
- The Odoo core stays intact. Every addition sits on top of the software and remains reversible. Our clients can update Odoo without concern and can leave us whenever they choose, without being locked in by a development.
- Study before writing. We always start by understanding how Odoo works in the client's version. We have abandoned a well-advanced development because a simple configuration change was enough. The best module is sometimes a well-placed setting.
- Retiring what no longer serves a purpose. A module is not an asset to be preserved. It is an answer to a need. When the need disappears, the answer should disappear with it.
What this means in practice for you
If you are using this module on an earlier version of Odoo, it continues to work normally. Odoo 18 remains supported by the publisher and our teams provide support and maintenance on versions that are currently supported.
When you move to Odoo 18, 19 or 20, your project manager will review the situation with you. He will suggest the simplest solution to meet your need and it is not always a development.
More broadly, when we advise you against developing something, it is because the need does not justify it. An integrator who sold development at every turn would not be serving the interests of its client.
What a lean ERP says about the person who implements it
Think of a restaurant kitchen. What you see in the dining room is the result. What you do not see is the decision not to put a dish on the menu because it would not be up to standard that evening. Restraint is an act of quality, not a limitation.
Our ambition is to replace the management software used by French SMEs with a well-built Odoo. A well-built Odoo is a lean Odoo, in which every addition has a reason to exist. We publish our modules when they bring genuine value. We tell you honestly when it is better to publish nothing at all.
If you have questions about your own developments, about what is better to keep, rewrite or simply remove before an Odoo migration, talk to one of our consultants. Thirty minutes is usually enough to see things clearly.
Book 30 minutes with a consultant
Frequently asked questions
Will my 'Purchase linked to project' module continue to work?
Yes, on your current version of Odoo it continues to work normally. At the time of your migration, your project manager will review the situation with you and identify the simplest solution, which is not necessarily a development.
Why did ANOR decide not to carry this module forward to Odoo 18?
Odoo has evolved and now covers this need natively. Keeping a redundant module generates maintenance and verification costs with every update, which the client ends up paying. We chose to retire it.
How does ANOR decide whether a development is necessary or not?
We start by understanding how Odoo works in the client's version. If a native configuration setting is sufficient, we write no code. A development is only undertaken if the real need cannot be met any other way.
If ANOR advises me against a development, does that mean my need is not legitimate?
No. It means the need can be met in a simpler, more sustainable and less costly way. Organisation consulting is part of our approach, independently of any development.
What happens to my specific developments if I leave ANOR?
The code belongs to you. Our developments sit on top of Odoo and remain reversible. You can migrate, change integrator or update Odoo without being locked in by a development that is out of your hands.