Odoo developer at Niyu Labs. Custom modules, data warehouse connectors and AI built into Odoo 16–19. I build the parts of your ERP that don't ship in the box.
@dstrausser83 The duplicates are rarely in the name. They are in the references: same part, three suppliers, three codes, nobody sure which one you stock.
Cheapest first pass is last stock move date against last quote date. What has one and not the other is the list to clean.
@jdegoes Once the agent is the client, the product surface stops being the GUI and becomes the scope: which models it sees, which fields are off limits, how many rows leave per call, who asked what and when.
Nobody demos that part. Procurement asks about little else.
@SoftwareFarm The part that bites after setup is replenishment. Most reorder rules are per-warehouse, so a shortage in one raises a PO while the stock sits in another.
Resupply routes fix it, but only if someone sets them. The default is buy.
@geminatecs The test that settles it early: can it be done with configuration and a server action before anyone writes a module.
Most of what gets custom-built already exists in stock/ or account/, below where the docs stop. Reading the source beats scoping the spec.
A compute field missing its api.depends decorator computes once, caches, and serves stale values for the rest of the request.
No error. No warning. Just a number that is quietly wrong.
Hardest class of Odoo bug to find, and the fix is one line.
@geminatecs It usually gets answered with a symptom.
"Reporting is slow" is a symptom. "Month end takes four days because finance won't publish until ops confirms stock" is a problem. It names who is blocked, by what, and for how long.
Only the second can be checked later.
@nirajkvinit Riskiest one we gate: creating a PO from a demand figure the agent computed itself.
The confirm dialog isn't the gate. The gate is upstream. The read is scoped and logged, so the approver sees which records produced the number.
Untraceable numbers can't be approved.
@dstrausser83 The buyer-side version of that test: ask to see the demo on a restore of your own database.
Most only hold together on the vendor's seeded data. Custom fields, half-filled records and twelve years of history are what break it.
Gary is the symptom, not the cause.
Signs ERP reporting is broken:
finance keeps a shadow spreadsheet,
no number leaves the building without checking with ops,
the monthly pack takes four days.
None of these are Odoo problems. Each one is a question nobody modelled.
@geminatecs The documentation that pays off at upgrade time is the why, not the what.
The code is readable. What is lost is whether an override was a deliberate business rule or a workaround for a bug fixed three versions ago.
One line then saves a week of archaeology later.
@anirudhmain The gap is smaller than it feels. The deploy is not what bites.
-u on a populated database behaves nothing like a fresh one: renamed fields with no migration script, constraints that fail on existing rows, no rollback but the backup.
Rehearse on a restore of prod.
@SitaramSolution Worth making the review evidence-based.
Most audits list the customizations. The useful pass is which are still used: last write date on the custom models, and how many records have the custom fields filled at all.
A lot of Studio fields come back empty.
@DinoJVidiliCons The constraint is usually underneath the model.
If margin runs on a standard cost revalued monthly, a tariff change is invisible until the next revaluation. The scenario is modelling last month's cost base.
Landed cost booked at receipt is what makes it honest.
Every ERP integration becomes a conversation about idempotency.
The export ran twice. The webhook fired late. The scheduler overlapped itself.
Each job gets an external key, a retry ceiling, a next attempt time.
Design for it on day one or rediscover it in production.
@geminatecs The features that stick removed a step someone was already doing by hand.
Anything that adds a step gets routed around. Quietly. The spreadsheet comes back and nobody files a ticket about it.
Adoption shows up in what people stopped doing, not in the training log.
@SitaramSolution Product-level margin is the right cut. The trap is timing.
Landed cost often posts after the sale is booked, and credit notes land later still. A SKU can read profitable all month and change at close.
Worth knowing if it values at cost on the invoice date, or cost today.
@Envertis_ Data mapping is the right thing to lead with.
The code is usually a day. What eats the timeline is the undocumented layer: Studio changes nobody wrote down, custom fields with no target, reports built on models that no longer exist.
Audit that before you quote it.
Odoo said coverage was normal.
net_available counts virtual supply. Subtract what's already reserved against open orders and the real cover is two days, not nine.
Both numbers were already in the database. This is an LLM reading them together, read-only, over MCP.
sudo() is not "make the permission error go away."
It runs as superuser. Access rights and record rules both gone.
Call it in a method a portal user can reach and you haven't fixed a bug, you've shipped a data leak.
@surekhatech The step after detection is the one most setups skip.
A failed check at receiving is a fact about that transfer. It only pays for itself once it's also a fact about the supplier, scored against every other PO they've sent.
Otherwise you catch the same defect for three years.