Guides / ERP augmentation
Odoo publishes a documented way into your own data, which puts it ahead of most manufacturing systems. That's not usually where it goes wrong. It goes wrong on the question that needs manufacturing, purchasing, inventory and the books at once.
Most of these notes start by explaining why a system won't let you at your own numbers. This one doesn't, because Odoo will. It's one of the more open systems a manufacturer can be running, and that changes what's worth doing about it.
Odoo publishes how to talk to it, and anybody can read that documentation without being a customer first. You can run it for free to try something. There's an enormous community, so when somebody gets stuck on your behalf, the answer usually exists somewhere already.
Compare that with what a lot of manufacturers are sitting on. There are well regarded systems in this trade that publish nothing at all for an outside developer, and one that still has no modern way in and needs a paid certification before the vendor will help. If you're on Odoo, you have something they don't: the door is unlocked. I put the whole comparison in which ERPs let you get your data out, and Odoo comes out near the top of it.
Odoo is modular by design, and that's the strength and the problem in one. Each module does its job well and holds its own piece. The questions you actually want answered don't respect those lines.
The built in reports and pivot views are genuinely capable, and for a single module they're often all you need. The wall shows up at the point where an answer has to cross modules, or cross out of Odoo entirely, and get delivered on a schedule to somebody who isn't going to log in and build it.
Odoo is usually implemented by a partner, and that partner configured it around how your operation worked at the time. That's the right way to do it. What it means later is that the shape of your data is specific to you: fields used for purposes nobody documented, conventions that make sense to the people who set them, a module you paid for and stopped using.
Any generic answer about Odoo is therefore wrong somewhere in your install, and the places it's wrong are exactly the places that matter. Anybody who tells you what your Odoo data looks like without having opened it is guessing.
Nothing moves and nothing gets replaced. Odoo stays your system of record, configured exactly as it is. What gets added sits alongside it and reads.
The connector I've built and run in production is for a different manufacturing ERP, into QuickBooks Online, at a real manufacturer, in daily use. That's the one with real scars on it. The Odoo connector is already built against Odoo's published interface. No operation has run it on live data yet, which is the part that matters.
I'd rather say that plainly than let you find it out later. It also isn't a small distinction, because every serious fault in the connector that is in production only showed up against the customer's real data and was invisible in every test beforehand. A published interface gets you most of the way. The last part is found by pointing it at a real operation.
Which is why the first Odoo operation to run this gets design partner terms. Being first is worth something and I'd rather price it that way than pretend the road is already paved.
A paid Diagnostic first, where I look at your install and the questions you keep chasing by hand, and establish what your data can honestly support. Then a Build quoted up front, so you know the price before it starts, with no hourly billing. I host it and keep it running, with an ongoing care plan covering hosting, monitoring, fixes and adjustments as your operation changes.
One limit worth knowing up front: this reads what your operation actually recorded. If something isn't being captured, or is captured somewhere it doesn't belong, no amount of connecting invents it. Finding that out is usually part of the value, and it's the first thing a Diagnostic settles.
It depends on which pieces you're running and how your install is hosted, which is one of the first things the Diagnostic settles. There's usually a workable route either way, and it's better to establish that early than to assume it.
Not by default. I read, and I don't write back unless you specifically want that, and even then it's a separate and much more careful conversation. Your configuration stays yours, and your partner's work stays intact.
Sometimes it is, and if they'll do it well you should let them. The split I usually see is that partners are set up to change what Odoo does, and this is about assembling answers that sit across Odoo and everything else, delivered on a schedule. If your partner wants to do that, that's a good outcome and I'll say so.
A read layer sitting alongside is far less exposed than changes made inside the system, which is a good reason to keep it outside. Still, anything that reads a system has to be maintained when the system moves, and that's what the care plan is for rather than a surprise invoice.
Related reading. If you're weighing how open your system is against others, that's which ERPs let you get your data out. If you run something self hosted and open source instead, the companion note is ERPNext reporting.
First call's free. About 30 minutes, a straight conversation about how your operation really runs and which numbers you keep chasing, not a demo. If there's something worth building, I'll say so; if there isn't, I'll say that too.