Inventory and Production Management for an ERP System

This ERP system case study follows one part from supplier receipt to the unit built from it, keeping purchasing and stock in step.

The inventory record follows each component from receipt into the assembly that uses it. Its quantities and serial numbers travel with it. Batches and item history stay connected as stock moves, splits or returns to the shelf.

A build does not have to finish in one go. Completed units can take their own records while the rest of the batch stays in progress.

The challenge

Two receipts can update one purchase-order line at the same moment, and a build and a sales order can compete for the same stock. A quantity shown earlier on a screen cannot settle those requests. The checks have to run at the point where stock actually changes on the record.

What we built

Parts, supplier records and bills of materials make up the reference data that purchasing and production both draw on. Build orders allocate components to create the output items. Before a build closes, completion checks that the required part tests are on record.

For partial completion, the system splits the batch. Finished items keep their links to the components they used, while the rest of the batch holds its own stock state. Records for movement, installation and return carry that history past the build itself. Labels, barcodes and mapped imports support the physical handling work that happens around the build.

Protect quantities during receipt and allocation

Receipts lock a purchase-order line before reading the received quantity. The database then adds to the stored total rather than overwriting it with a stale application value. It reads the current figure before it writes the new one. Build allocation does the same for a build, locking its record before competing requests apply.

Completion can compare allocations against a snapshot sent with the request. Items whose quantities have moved since then are skipped. That guarded path stops the same stock from being consumed twice on an old snapshot.

Keep availability separate from history

Available stock has to clear two tests before it can be used anywhere. It needs an eligible quantity and status. It cannot already be assigned to other work or installed. It also cannot be consumed or still sitting inside an open build, and reservations live in the build and sales-order allocations.

Completion links components to the output item. A split then creates a second item that carries its own history. The API publishes the order and build transitions it permits, so interfaces can offer actions under the same business rules.

Plugins can extend validation, labelling and equipment integration where a site needs it. They run with server-level access, so they call for administration by a party the organisation already trusts. Each installation serves a single organisation. Separate customer environments need their own instances. Financial accounting stays outside the inventory side of the ERP system.

Project success

Staff can trace a finished unit back to its components, including one completed ahead of the rest of its batch. Protected receipt and allocation paths govern every quantity change. The item history then shows what was received, where it moved and what it became, instead of leaving only a final count.

Technology stack

Backend

Python, Django, Django REST Framework

Frontend

React, Mantine

Supported databases

PostgreSQL, MySQL, SQLite

Background processing

django-q2, optional Redis

Reports and tracing

WeasyPrint, OpenTelemetry