Custom ERP development: define the first operational release

SECTION 01

Draw the boundary between new and existing systems

Write down which system owns products, suppliers, purchase orders, stock movements, invoices, and payments. If two systems retain copies, define which one may change each field and how the other learns about the change. A shared screen does not remove the need for clear record ownership.

Keep financial posting, tax handling, and payment authorization in the approved existing process unless their replacement has been separately assessed. Your finance owner should confirm what the operational application may submit and what requires review.

SECTION 02

Illustrative example: purchasing for a small distributor

Imagine a distributor whose staff request stock through spreadsheets. A first custom ERP module could collect purchase requests, apply approval rules, create approved purchase records, and record deliveries. The accounting tool remains responsible for supplier bills and payment.

Suppose a purchase order requests ten cartons but the first delivery contains six. The application should record a partial receipt, keep four outstanding, and distinguish a carton from an individual unit. If one carton is damaged, staff need a correction or return process rather than editing the original receipt without a trace.

This is a planning example, not a delivery claim. It shows why a small number of modules can still require detailed rules. The agency needs to know how your staff handle exceptions before it can estimate a reliable first release.

SECTION 03

Define transactions and corrections before dashboards

For each record, specify its states and the actions allowed in each state. An approved purchase should not behave like a draft. Decide what happens when the supplier, price, or quantity changes after approval and whether the change needs another review.

Existing ERP documentation can help you identify standard behaviors to compare. Odoo's documentation, for example, distinguishes replenishment methods and purchasing controls based on ordered or received quantities. These are references for process questions, not a claim that Catapult implements Odoo or that your workflow must match it.

SECTION 04

Use phase boundaries that leave the business able to work

A useful first phase contains a complete transaction, not unfinished pieces of every module. Purchasing staff should be able to submit, approve, receive, and reconcile the agreed scenario before the team starts a separate sales or planning module.

Identify temporary handoffs between phases. An approved export to accounting may be an acceptable starting point if someone owns it, can identify rejected rows, and can prove an export was not processed twice. Calling a spreadsheet export an automated integration would hide that operational responsibility.

Agree the reports needed to close the loop: outstanding quantities, unresolved discrepancies, and records awaiting transfer. Define the same dates, units, and statuses across reports so the numbers can be explained.

SECTION 05

Accept the release with real transaction evidence

Use anonymized examples from ordinary and difficult days. Check permissions for requesters, approvers, receiving staff, and administrators. Demonstrate repeated submissions, cancelled orders, partial receipts, and an unavailable external system. Agree how support staff discover and correct failed work.

Before launch, reconcile opening records and decide when the old process stops accepting changes. Preserve a recoverable export and document the fallback procedure. The business owner should sign off the operational totals; a successful software build is not evidence that the imported stock is correct.

For an agency quote, separate discovery, module development, data preparation, integration, training, and support. That comparison is more useful than treating every ERP project as the same product with a different price.

SECTION 06

Frequently asked questions