Many managers assume that developing an ERP system means bolting on more and more features. In practice, the best implementations are the ones where we're able to slim the system down. The more custom code you have, the more expensive future migrations become, the harder maintenance gets, and the higher the risk that a new team member makes a costly mistake.
Here's a story from my own practice that perfectly illustrates how seemingly harmless code "patches" paralyze warehouse work and quietly generate technical debt.
The symptom: duplicated work and vanishing carts
A client came to me with a problem affecting shipments to the US. Even though they were using a standard carrier integration in Odoo Enterprise, the whole process was riddled with manual, tedious workarounds:
- On the customer side (e-commerce): During checkout, the address was validated in the background, and the buyer then had to pick the "correct, validated" version from a list. A bug in the script, though, could suddenly reset the cart, forcing the customer to reselect all their products.
- On the employee side (warehouse): A big "Validate address" button had been added to the contact record (
res.partner). Before shipping a package, the warehouse worker had to manually click that button, which sent a request to an external service.
From a process-management standpoint, this is a straightforward path to disaster:
Manual work inside an ERP is asking for a mistake. A new employee won't guess that they have to click a hidden button. An experienced employee, in a hurry or near the end of a shift, will simply forget about it. The result? A package shipped to the wrong address on the other side of the world.
The investigation: treating symptoms instead of the cause
The client's original request was simple: "The validation button stopped working, it needs to be fixed."
A quick check showed that the external service used by the button had shut down its old API (it had been deprecated). I could have just rewritten the code against the new REST version and sent an invoice. But something didn't add up — Odoo's own factory carrier module already has built-in address validation. So why did someone bolt on a manual button and an extra check in the cart in the first place?
I started going through the custom modules extending the warehouse delivery logic (stock.picking). That's where I found the root cause.
The mystery, solved in the code:
- A previous developer had written a module extending the warehouse logic, but completely ignored handling the exceptions (API exceptions) returned by the carrier's service.
- When the carrier's API flagged an address problem, the code simply "pretended" nothing happened and swallowed the error.
- Because packages kept going out with bad addresses, instead of fixing that one exception in the code, the previous team kept bolting on "prosthetics": a separate button for the warehouse worker, an external validation service, and extra screens in the shop.
The fix: less code = a smoother business
Instead of writing more lines of code and hooking up a new validation service, I did a thorough refactor:
- Fixed the error handling in the warehouse module (
stock.picking), restoring native communication with the carrier's API. - Removed the artificial validators from the customer form and the e-commerce cart.
- Removed the unnecessary button and the external service integration.
The impact for management and the team:
- Eliminated human error: The warehouse worker doesn't have to remember anything. The system automatically blocks the label and reports an address error when trying to validate the delivery.
- Faster shop checkout: The customer is no longer hassled by address-reload pop-ups, and the cart stopped clearing its contents.
- Easier, cheaper Odoo migrations: Removing several hundred lines of custom code means fewer conflicts when upgrading to a newer Odoo version.
- Lower maintenance cost: Less code means fewer places where anything can break.
The lesson for management
When your team reports that "something needs to be added to the system," make sure they're not actually papering over architectural technical debt. A conscientious engineer doesn't look for excuses to write hundreds of new lines of code — they look for a way to make the process work as simply as possible, with the fewest moving parts.
Does your Odoo system need cleaning up?
A small bug in the code often generates hours of unnecessary manual work in the office and the warehouse.
Book a consultation. We'll audit your Odoo processes and show you how to simplify the system and lower its maintenance cost.