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.

Between those steps sit the spreadsheet holding the numbers people act on, the mailbox holding the approvals, and the report rebuilt every Monday.

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, with its own release cycle; or the supplier's systems. Each is an interface with an owner on both sides, not a module. Drawing that line early stops the project becoming a rewrite of the company.

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.

What a delivery would contain

These modules describe what a project can build, not a delivered record; the proof section states what has been delivered.

• 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 only proven 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. The old system is switched off only after the last dependency on it is moved.

Netbase runs this in Agile increments with weekly reviews, remote-first from Hanoi, with one delivery lead accountable. AI tools are used in delivery under human review, and a named engineer owns every change that ships. Governance is on the project delivery page, contracting shapes on the engagement models page.

How success is measured

Pick measures before the build and take a baseline: receipts entered on the day goods arrive; invoices matched without a person touching them; the age of the exception queue; days to close the period; stock accuracy against a physical count; and shadow spreadsheets in use.

Netbase publishes no measured business result for another client's workflow, so nothing here is a benchmark. Your own baseline is the only comparison that means anything; how evidence is labelled is on the methodology page.

Where this holds, and where it does not

The flow holds across manufacturing, distribution, retail and services, because 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, so the same matching applies to timesheets and subcontractor bills.

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 a project is 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 would meet the need and only reporting is missing.

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 sit on the services page, where you ask for a quotation.

The delivery evidence behind this page is one record. Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS platform for a client that is not named. Its first phase, from 2020 to 2023, covered CRM, real-time messaging, HR, a knowledge base, custom fields and configurable workflows, work and project management, and API integrations, on a stack that includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS. A later retail phase, covering point of sale, inventory, purchasing and vendor management, was planned work when that profile was written; it is not presented as delivered, and nothing here rests on it. That record describes what one project contained. It is not a standing offer, not a package, and not a commitment to the same scope, stack or schedule.

Two neighbouring workflows are written up the same way: marketplace and classifieds operations when supply comes from third parties, and customer support automation when the queue is inbound.

Services behind this solution