Most Odoo projects start with one question: which standard screen does this process go into? For accounting, invoicing and much of the daily office work, that is the right question, and the standard screens answer it well. For a manufacturer it often leads somewhere less comfortable. Either the process gets bent until it fits the screen, or the screen gets bent until nobody dares to upgrade it.

There is a better way to look at it. Treat Odoo as the place where the business data lives: orders, stock, production, purchases, invoices, payments, people. One clean, open database that the company owns. Then build fast, purpose-made surfaces around it, one for each group of people who work with that data, each doing one job well.

Here is how that works at a mid-sized manufacturer in Central Europe, with dealers in many countries, its own production and a warehouse that ships every day.

One bucket, many surfaces

The picture is simple:

  • In the middle: Odoo, on one PostgreSQL database. It is the system of record. Every order, batch, movement, invoice and payment is written there once, with its history.
  • Around it: a public website, a dealer portal, tablets on the shop floor, a purchasing desk, management dashboards and an AI chat on the website.
  • The rule: no surface keeps its own copy of the truth. Each one reads from Odoo and writes back to Odoo. If the order status changes, it changes everywhere at once.

Odoo does what it is very good at: keeping consistent, linked business records. The surfaces do what standard screens are not built for: giving a dealer, a machine operator or a board member exactly the view they need, in their language, on their device, without a single menu they will never use.

Where the standard approach stopped

Before this, the company had a typical implementation. Modules were installed and configured, the standard screens were switched on and accounting and sales ran in Odoo. What never got finished was the part that makes a manufacturer a manufacturer: bills of materials, workstations and the real flow from a customer's order to a loaded truck. Production planning still lived in spreadsheets and phone calls.

Nobody did anything wrong. It is what the "configure the standard" approach tends to produce: it covers the books well and leaves the shop floor to work around the system. A manufacturer with its own way of making things needs the system to follow the work, not the other way round.

What we built around Odoo

A portal for dealers

Dealers log in on a separate domain and see each of their orders move from production to shipping on a timeline: what is in production, which part is already ready, when it leaves. Delivery documents and invoices are there to download, and a complaint is opened against the exact order it concerns. The portal speaks the dealer's language. Questions like "where is my order?" now answer themselves.

Production that knows the customer

Every manufacturing order belongs to one customer and one delivery. When stock is replenished, the quantity is split correctly between the orders waiting for it, so nothing gets quietly borrowed from someone else's shipment. The warehouse sees which batch goes into which delivery, and what is picked matches the delivery note.

Screens for the shop floor

Tablets at the workstations show people what they need and nothing else. They clock work against the order in front of them, record quality checks and move on. Large buttons, no menus, no training manual. The data lands in Odoo the moment the work happens, not at the end of the week.

A website that reads from Odoo without exposing it

The public website runs on its own fast content system, not on Odoo's website module. Products and data come from Odoo through a narrow gateway that allows only what the website needs. Even a compromised website could not reach the ERP behind it. The site is available in many languages and scores at the top of Google PageSpeed. A product visualiser lets visitors see the product in their own setting, and every request they send becomes a lead in Odoo's CRM, with their choices attached.

Purchasing and payments under control

Supplier invoices from the national e-invoicing system arrive on their own, together with foreign invoices and receipts. Bank statements are imported and matched to invoices. Customers have credit limits, and an order above the limit waits for approval before it goes out. Management can see what is due, what is paid and what is overdue without asking accounting for a report.

Dashboards, labels and an AI chat

Management dashboards show orders, output and the comparison that matters most on a shop floor: time at work against time actually logged on workstations. Pallet labels and shipping documents print from the same records. On the website, an AI chat answers visitors from the company's own content and passes the conversation to a person when it should.

Why this fits a manufacturer

  • Each group gets a screen made for its job. A dealer, a machine operator and a controller look at the same data and see three different things, each useful.
  • One number for everything. Stock, order status and invoices come from one place, so the portal, the dashboard and the warehouse never disagree.
  • Odoo stays close to standard. Because the special work happens around Odoo rather than deep inside it, a version upgrade stays an upgrade. We wrote about what that takes in Odoo 19 to 20: move the system, not just the data.
  • Surfaces can change one at a time. A new portal feature or a redesigned website does not touch production, and the other way round.
  • The data stays yours. Everything lives in an open PostgreSQL database the company owns, exportable in open formats. The tools around it can change. The ownership does not.

Keeping the layers upgrade-safe

Building around Odoo only pays off if it survives the next version. A few principles keep it that way:

  • Thin modules inside Odoo. Add the fields and rules where the record lives, keep them small and never rewrite what Odoo already does.
  • A defined layer between the surfaces and Odoo. Surfaces talk to a narrow, documented interface, not straight to the database tables. When Odoo changes, one place changes.
  • Each surface gets only the access it needs. The website can read products. It cannot read invoices.
  • Open formats in and out. Data that enters or leaves the system does so in formats anyone can read, so no surface becomes a cage.
  • Test as real users. A dealer's view is tested as a dealer, an operator's as an operator, before every change goes live.

When the standard screen is the right answer

Build a surface only where it earns its place. If a standard Odoo screen does the job, use it: most of accounting, invoicing and everyday administration work very well as they are. A custom surface makes sense where many people touch the data every day, where people outside the company need a view of it, or where speed and simplicity on the shop floor decide whether the data gets recorded at all.

FAQ

Is this just heavy customisation under another name?

No. Heavy customisation changes Odoo itself until it can no longer move. Here Odoo stays close to standard and keeps the records. The surfaces sit outside it and use it through a defined interface, so Odoo can be upgraded and each surface can be rebuilt on its own.

Can we start small?

Yes, and you should. Pick the one place where people fight the system the most, often the shop floor or the customer view, build one surface for it and measure the difference. The next one follows when the first has proven itself.

What happens to our data if we stop working with you?

Nothing. It stays in your own Odoo, in an open PostgreSQL database, and can be exported in open formats at any time. The surfaces read and write your data. They never hold it hostage.

If your Odoo holds the data but your people still work around it, talk to us about the surfaces your business is missing. If you run Odoo yourself, Zoxron MCP lets your AI agent install, back up, monitor and upgrade it on your own server, and helps it write the thin modules this approach relies on.