Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Plan ERP procurement and inventory around decisions and evidence

An ERP procurement and inventory project should make every purchasing and stock decision traceable: who requested an item, who approved it, what was received, which stock state changed, and how the system reconciles with the shelf and the ledger. Define those states, owners and reconciliation points before choosing modules or replacing screens.

Submit a project Explore legacy modernization

Reviewed by Huy Nguyen (David), CEO · Updated 15 Oct 2026 · 9 min read

star

OutsourcingVN is operated by Netbase JSC, so this guide supports a buying conversation we may join. 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.

What this guide covers

What should you trace before choosing modules?

Choose a common stocked item and trace it from demand to receipt, issue or consumption. Include everyone who touches it: requester, approver, purchaser, warehouse, finance, planner and the field or production team. Then trace the awkward cases: a late delivery, a substitution, a damaged receipt, an urgent issue, a return, a count adjustment and an invoice that does not match the receipt.

Write the business event and the system event separately. "Goods received" may mean a delivery reached the dock, someone checked it, a quantity was posted, a quality review passed or finance accepted the invoice. Design is safer when those states have names instead of sharing one status.

The manufacturing and field service industry page explains why stock, work and service records have to meet, the ERP and back-office operations workflow maps the common workflow shapes, e-commerce and ERP integration specifies the sync contract where a storefront sits in front of the ERP, and Odoo versus a custom build frames the platform choice where configuration might cover the workflow. Once Odoo is the chosen platform, Odoo implementation for retail chains sequences a multi-store rollout, and the WooCommerce and Odoo integration guide specifies the pairing where the storefront runs on WooCommerce.

Which stock states, owners and reconciliation points must you define?

Area Decision to define Evidence to retain
Demand Who creates a request, and when is it valid? Requester, need date, item description and reason
Approval Which spend or stock decisions need approval? Rule used, approver, decision and any delegated authority
Supplier commitment When does an inquiry become an order? Supplier, agreed scope, expected receipt and change history
Receipt What proves the quantity and condition received? Receipt record, exception, receiver and linked order line
Stock state Which quantities are available, reserved, in inspection or unavailable? State transition, location and responsible operation
Issue or consumption When may stock leave, and which job owns it? Issuing event, destination, user and reversal route
Reconciliation How are count, system and finance differences resolved? Difference reason, adjustment approver and close evidence

Never publish a single "available" number without its definition. A planner, the warehouse and finance often need different views of the same item, and they must still reconcile. Decide what each view means and who may adjust it; that decision matters more than any dashboard layout.

What ERP integration work has Netbase done?

  • Odoo consultancy and customization with a local partner. The client list above includes an industrial-park purchasing centre, trading and distribution companies and manufacturers, the operations where procurement and stock rules carry the most weight. See the Odoo implementations record.
  • ERP modules and e-commerce integration. Netbase's ERP consultancy and development experience covers modules including finance and accounting, inventory, sales orders, HR and recruiting, CRM, project planning, e-commerce integration and reporting, and e-commerce integration with ERP by API synchronisation of product catalogues, inventory, orders and customer data.
  • Upgrades from older systems. The same experience includes a Vtiger CRM to ERP upgrade covering customer experience management, sales orders, workforce administration, support tickets, product management, resource allocation and budget planning, and Redmine to ERP development.
  • A multi-year cloud ERP engagement. Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS for a US client (not named); phase 1 (2020-2023, agency SMEs) covers CRM, real-time messaging, HR, knowledge base, custom fields and workflows, work and project management and API integrations. See the cloud ERP record.

Worked example: one maintenance part from request to reconciliation

A plant technician requests six replacement pump seals for a line due for service. The request is valid because it names the asset and need date; the maintenance supervisor approves it under the stocked-spares rule. Purchasing converts it to an order with one supplier and an expected receipt date. Five seals arrive and one is cracked. The receiver posts four to "available", one to "in inspection" and records a short delivery of one. Quality rejects the cracked seal and it moves to "return to supplier", which opens a return and a credit request. The supplier invoices for six; finance holds the invoice because only four accepted units match the order line. The supplier ships the missing seal and a replacement, both are received against the same line, and finance releases the invoice for six accepted units. The month-end count agrees with the system, and the adjustment log is empty because every difference had a named state and owner.

How should the first release be scoped?

  1. Select one process boundary

    For example: approved requests for stocked maintenance items at the central warehouse, through receipting and discrepancy review.

  2. Inventory the source systems

    List the spreadsheets, ERP, warehouse, finance, field-service and supplier data that touch the path, with an owner for each interface.

  3. Clean a small representative dataset

    Use real item structures, units, locations, suppliers and open transactions to expose mapping and policy gaps early.

  4. Define the reconciliation event

    Decide which report or count proves the new flow agrees with the controlled source at cutover and after exceptions.

  5. Test reversals and outages

    Demonstrate a correction, a cancelled order, a returned receipt, an unavailable integration and the manual fallback.

For every integration, record direction, trigger, identifiers, error queue, retry rule and owner. If those are unknown, discovery makes them an output rather than an assumption. The Legacy Application Modernization service is the route when an existing back-office system must be assessed, changed or transitioned.

Diagram of an ERP first-release pipeline in one process boundary: source systems, a small clean dataset, the reconciliation event and reversal tests lead to a reconciliation check at cutover, with a manual fallback back (opens the full-size diagram in a new tab)
Diagram of an ERP first-release pipeline in one process boundary

What goes wrong, and who acts?

  • Units of measure differ between systems

    Early signal
    Counts disagree by pack size
    Who acts
    Item master owner fixes conversions
  • Duplicate item or supplier records migrate

    Early signal
    Two codes for the same part
    Who acts
    Data owner merges before cutover
  • Old and new systems both accept transactions

    Early signal
    Stock differs after the parallel period
    Who acts
    Cutover lead names the controlling record
  • Adjustments hide receiving errors

    Early signal
    Frequent unexplained adjustments
    Who acts
    Finance approver requires a reason code
  • Configuration changes without an owner

    Early signal
    Reports change meaning between months
    Who acts
    System administrator runs change control
  • An integration fails silently

    Early signal
    Orders missing from accounting
    Who acts
    Integration owner monitors the error queue

Which questions should you ask an ERP supplier?

  • Which stock states will the system distinguish?

    Named states with the transitions between them

  • How are receipt discrepancies handled?

    Partial receipt, inspection, return and invoice hold paths

  • Which data migrates, and which stays readable elsewhere?

    A decision per data class, with owners

  • How does each integration fail and recover?

    Error queue, retry rule, reconciliation report and owner

  • Who can change items, units and approval rules after go-live?

    Named administrators and a change route

  • What ERP work have you done that resembles ours?

    Specific records, the partner model if any, and the gaps

  • What will acceptance prove?

    Normal and exception paths, reconciliation and administrator control

Plan the next step for your project

Common questions

Only if the operation can define and test that whole boundary. A controlled first process, such as requests through receipting for one location, reduces risk while the organisation learns what must change next, and it produces reconciliation evidence before a wider rollout.

Move what the new process needs, and keep read access to what must stay auditable. Decide by data class and business use: open orders and current balances usually move, while closed transactions can stay readable in the old system or an archive.

Yes, if the handoff between ordered, received and available stock has an explicit owner and a reconciliation point. Without that, purchasing and the warehouse keep separate versions of the truth and month-end adjustments absorb the difference.

Netbase's Odoo consultancy and customization in Vietnam was done working with a local Odoo implementation partner. A proposal for your project states the roles, the partner if one is involved, and who holds each responsibility.

It should prove that authorised users complete normal and exception paths, that records reconcile at the agreed point, and that administrators can operate the stated controls, including changing a rule and reversing a transaction.

How this guide is sourced

Every statement about Netbase on this page maps to a registered claim backed by attested company facts, listed under Sources, in the wording the register approves. The pump-seal example is hypothetical.

The limits, stated once: the Odoo and ERP records describe scope and publish no client names, partner name or results, and the cloud ERP retail phase 2 was planned work when the profile was written and is not presented as delivered. The methodology explains how records are reviewed.

Prepare a first procurement and stock brief

Bring process maps, representative data, approval rules, reports, integrations and recent exceptions to a scoping session, and let purchasing, warehouse, finance and operations challenge the definitions. The print order and fulfilment guide helps where orders consume stock, the marketplace matching and quotation guide where a selection starts outside the ERP, the business workflow transformation guide where the problem spans several workflows, and the B2B ordering portals solution where the open question is account catalogues, terms and approval rather than the ERP record itself. The solutions overview and guides index list the rest. Submit a project with the first controlled process you want to improve: OutsourcingVN is Netbase's own outsourcing-services platform, and a person will assess whether discovery, modernisation or a bounded implementation comes first.

Legacy application modernization, one bounded capability at a time Legacy application modernization, one bounded capability at a time

The code is assessed first, then one bounded capability moves at a time, with a way back.

Learn More
line

Tell us what you want to build or automate.

Submit a project