ERP and back-office operations, mapped before anything is built

How the work runs today

Follow one order from demand to ledger. Demand arrives as a customer order, a forecast or a reorder rule. Someone checks availability, often by asking a colleague. A purchase order is raised in the system, or by email when the system is slow. Goods are received, sometimes days after they physically arrived. An invoice is matched by hand against the order and the receipt. Finance closes the period and finds the differences.

None of this is new thinking. It is hard because it changes who decides what.

What the system owns, and what it does not

A project of this kind owns the operational record of items, suppliers, orders, receipts and movements, the rules that govern them, the exception queues and the reporting on top.

It does not own the general ledger, statutory filing or payroll, which stay in the finance system of record; warehouse automation and device firmware, which stay with their vendors; the commerce front end; or the supplier's systems. Each is an interface with an owner on both sides, not a module.

Data and integration

The integration list is the real scope. For each connection, know who owns it, which way data moves, how often, and what happens when it fails.

• Finance system. Postings out, master data in, under the strictest reconciliation requirement on the list.
• Commerce or order intake. Orders and availability both ways, with an agreed definition of what available means.
• Suppliers and logistics. Purchase orders, confirmations and delivery notes, often by file transfer or portal rather than an API.
• Identity. One directory for accounts and roles, so access ends when someone leaves.

Two questions decide the timeline more than these: how much history must migrate, and how bad the master data is. Both are measurable in days, and both belong before a fixed scope.

Where does AI do the work in this workflow?

Two steps benefit from a model instead of a person starting from zero: scanning master data for likely duplicates — the same supplier under three names — and reading the old system's rules and code to draft a first-pass description of behaviour nobody wrote down. Netbase works with commercial and open-source AI models chosen per project. Neither step merges a record or signs off a migration on its own; a named person checks every suggestion first.

What a delivery would contain

• Master data: items, suppliers, locations and units, with ownership and a de-duplication pass.
• Procure-to-receive: requisition, approval rules, purchase order, receipt and tolerance matching.
• Inventory movements: counts, transfers and adjustments, with their audit trail.
• An exception workbench with queues, owners and ageing.
• Operational reporting, plus an export the finance system accepts, and integration adapters with retry, dead-letter handling and an alert that reaches a person.
• Role-based access with multi-factor authentication on admin accounts, plus secure code review.

Rollout

Run one location or product family first, in parallel with the existing process, through a full period close. The change is proven only once a month has closed on it.

A workable sequence: assessment and data profiling; master data clean-up while the build runs; a pilot in parallel; a rehearsed cutover with a tested rollback; then extension site by site.

Governance is on the project delivery page, contracting shapes on the engagement models page.

How is success measured?

Pick measures before the build and take a baseline: receipts entered the day goods arrive; invoices matched untouched; the age of the exception queue; days to close the period; stock accuracy against a physical count; and shadow spreadsheets in use. Your own baseline is the only comparison that matters; evidence labelling is on the methodology page.

Where this holds, and where it does not

The flow holds across manufacturing, distribution, retail and services: all four raise demand, commit supply, record a movement and reconcile it. What changes is the middle: manufacturing adds work orders and bills of material; distribution adds lot and serial tracking; retail adds store-level replenishment and returns; services replaces stock with time. The plant-floor version is worked through in the ERP procurement and inventory guide and on the manufacturing and field service page.

It does not hold where the operation is regulated at item level, such as pharmaceutical dispensing or controlled goods. There compliance rules drive the design, and this flow is the wrong start.

When is a project the wrong answer?

Stop before scoping if the process is undocumented and nobody will own writing it down; if no one can approve a change to master data ownership; if the real problem is commercial, such as supplier lead times; or if a standard configuration meets the need and only reporting is missing. The business workflow transformation guide separates rules, configuration and bounded AI steps; an AI Workflow Blueprint settles it for one workflow.

Services and delivered proof

Most of this work is modernization, not a new product, so the commercial path is Legacy Application Modernization: assess first, then migrate one bounded capability at a time with parity evidence and a rollback. When the target is a new operational product, Custom Product Engineering is the route. Both are listed on the services page.

Working with a local Odoo implementation partner, Netbase has consulted on and customized Odoo in Vietnam for retail store chains, a food and beverage franchise chain, manufacturers, trading and distribution companies, a warranty service network, an industrial-park purchasing centre, an energy-sector project time and cost system, a university institute and a postal-service helpdesk; these clients are not named. The Odoo ERP implementations record sets out that scope.

Since 2020 Netbase has also worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS platform for an unnamed client. The cloud ERP record sets out its scope: a first phase, 2020 to 2023, covering CRM, real-time messaging, HR, a knowledge base, custom fields and configurable workflows, work and project management, and API integrations, plus a later retail phase (point of sale, inventory, purchasing and vendor management) that was planned work when written. Wider experience covers e-commerce and ERP integration, a Vtiger CRM to ERP upgrade and Redmine to ERP development.

Four neighbouring workflows: order and payment operations when the money side drifts, document and approval workflows for paper invoices and approvals, marketplace and classifieds operations when supply comes from third parties, and customer support automation when the queue is inbound.

Services behind this solution

Sources

• Odoo, Bill of materials, Odoo 17.0 documentation
• Odoo, Lot numbers, Odoo 17.0 documentation