What the module does

Purchasing and inventory replaces the stock, material-planning and purchasing parts of a manufacturing ERP. The specification names Epicor Kinetic, Plex, NetSuite Manufacturing, Acumatica, SAP Business One, Odoo MRP, Katana, MRPeasy, Fishbowl, ECI JobBOSS2 and E2, and ProShop. Tools such as MRPeasy list the same core: MRP, lot tracking, routings and costing ^[5].

The module keeps an exact stock record by item, lot, serial number, location and status. It plans material with MRP (material requirements planning: working out what to buy or make, and when, from what is needed). It runs sales orders and purchasing through receipt, and it hands the invoice match status to accounting. The general ledger, payment of suppliers, collections and tax stay in the accounting system.

The eleven capabilities

Standards behind it

Every movement is a transaction

The table inv_inventory_transaction is the ledger. One row is one movement of one item (and lot, and serial unit where tracked) from a location and status to another. Nothing else changes a quantity.

• Quantity is always above zero. The direction comes from from_location_id and to_location_id, never from a negative number.
• The ledger refuses edits. A database trigger (a rule the database runs on every change) raises an error on any update or delete of a ledger row, whatever the application does ^[4].
• Rules the database checks. A unique txn_no, allowed values for the type, and a unique key that stops one request from posting twice ^[3].
• Balances are derived. inv_inventory_balance holds the current quantity by item, site, location, lot, serial unit and status. It is the sum of the ledger, kept up to date by the one route that posts.

The fifteen tables

Your agent builds the module's tables from this list in Session 2. Every table also has the standard columns id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. An arrow (→) names the table a column points at; qty is a quantity, money an amount, ts a date and time, json structured data. Where a column lists its values, no other value is allowed. The specification also describes inv_cost_record and inv_demand_forecast, which this course does not build.

The module also listens for events from other modules. This course builds only one of them, qms.hold.placed from the quality module. The others the specification lists (material consumed and lots produced in production, a quote accepted in CRM, a shipment shipped from the warehouse, an engineering change implemented), and its master production schedule, forecast and request-for-quote features, are out of scope here.

Screens and routes

A mistake is a reversal

If a row is wrong, you do not fix it. You post a second row that undoes it: the same item and quantity with from and to swapped, reason REVERSAL, and reversal_of_id pointing at the original. History shows the mistake and its correction, and the balance at any past date can still be reproduced from the ledger.

Lots, serials and statuses

A lot is a quantity made or received together, so it can be traced. A serial unit is one individual item. The balance row also carries a status: available, quarantine, hold, allocated, in_transit, consigned or damaged. Only available stock can be promised to a customer or issued to production.

When the quality module places a hold on a lot, the module receives the event qms.hold.placed and the lot moves to status hold. It stays in the balances, so you can see it, but it is outside the view of available stock and of the available-to-promise answer, so no order can use it. Releasing a hold is a status_change back to available, and it needs the planner.

Parameters per item and site

MRP does not decide by itself how an item is planned. Each item at each site has one row in inv_item_site_plan, and the MRP run reads it. The method and lot-sizing rule come from the CPIM body of knowledge ^[1]. Vendor tools such as MRPeasy and Katana offer the same ideas under their own names, with reorder points and lot traceability ^[2][3].

The course seed has two bought items. A-100 is planned by MRP with a fixed order quantity of 40, safety stock 10 and a lead time of 14 days. B-100 is planned by reorder point, with its min_qty of 30 used as the reorder point, a fixed quantity of 100 and a lead time of 7 days. P-100 is made, and one bill of materials row says it needs 2 of A-100.

Demand

Demand comes from confirmed sales orders, from forecasts by period, and from the orders that consume components. A sales order line also gets an available-to-promise (ATP) answer: how many units can be promised for a date from available stock and scheduled receipts, less what is already committed. Held and quarantined stock is not in that answer.

Gross-to-net, step by step

1. Explode. Turn each demand for a made item into demand for its components using the bill of materials.
2. Gross requirements. List the need for the component by date.
3. Net. Start from available stock and add scheduled receipts (open purchase order lines), firmed planned orders, and released planned orders whose requisition is not yet on an order line. Take away each need in date order. Wherever projected stock would fall below the safety stock, the shortfall is a net requirement.
4. Size. Round the shortfall up with the lot-sizing rule.
5. Offset. Subtract the lead time from the due date to find the release date.
6. Peg. Store, with each planned order, the demands it covers.

The worked run for A-100

Available stock is 50. Another 10 are on hold in a second lot and are left out. One open purchase order brings 20 on 2026-11-09. Safety stock is 10 and the fixed order quantity is 40.

Each shortfall is smaller than the fixed quantity, so each planned buy is the full 40. Then lead-time offsetting counts back 14 days from each due date.

Exception messages

The run also writes messages for the planner in inv_mrp_exception. Each has a type and a status of open, actioned or ignored.

From need to order

A need becomes a requisition (inv_purchase_requisition): an internal request to buy, which may come from a person or from a released planned order. Its statuses are draft, submitted, approved, rejected and converted. Once approved, the buyer converts it to a purchase order.

The buyer does not type the price. inv_supplier_item holds each supplier's price, minimum order quantity (MOQ), lead time and a preferred flag, and the order takes supplier, price and lead time from the preferred row. The seed has Supplier One selling B-100 at 2.5000 with a minimum of 20 and a lead time of 7 days. Currency is a text code, such as the ISO 4217 codes ^[6]. The total is computed on the server, never taken from a browser.

Approval by threshold

Each business sets its own approval amount; the course gives none. At or under it, an order needs one approval step. Over it, two steps by two different approvers. When the buyer submits, the module creates the pending approval rows and the order becomes pending_approval. Each approver confirms their password and an e-signature is stored with a hash of the order header and lines, so any later change to the order is detectable. The last signature is kept on the order as approved_signature_id.

Keep the duties apart

Where SOX applies, approving and receiving an order must be different people. The same idea runs through security guidance as separation of duties: no one person can complete a sensitive process alone ^[1]. The module writes it as rules in the Role and Exposure Matrix.

Receiving

A goods receipt (inv_goods_receipt) is booked against one order line. The route creates the lot, inserts the receipt, posts a po_receipt to the ledger with the unit cost from the line, raises qty_received and moves the order to partially_received or received. It refuses a receipt that would take the line above the quantity ordered.

• Lot capture. Every receipt of a lot-tracked item names a lot, so the stock can be traced to the delivery.
• Inspection routing. If inspection_required is true, the goods arrive in status quarantine. The planner releases them with a status_change once they pass.
• Return to vendor. The receiver posts a vendor_return with a reason code through the receiving route. It takes stock out and lowers qty_received. It is a new transaction, not an edit of the receipt.

Invoice match hand-off

The supplier's invoice is compared with what was ordered and what was received. A two-way match compares order and invoice. A three-way match adds the receipt, so you pay only for goods that arrived. The result is stored in inv_invoice_match as pending, matched, price_variance, qty_variance or rejected.

Documents that cross the fence

Orders, acknowledgements, ship notices and invoices travel between businesses as standard documents. In ANSI X12 they are 850 (purchase order), 855 (purchase order acknowledgement), 856 (ship notice, also called an ASN) and 810 (invoice) ^[2]. OAGIS business object documents ^[4] and UBL 2.x ^[3] cover the same ground in XML. Inventory tools in this class tie purchasing, receiving and stock together in the same way ^[5]. The module sends nothing to suppliers by itself: the buyer sends the order the way the business already does and sets the status.

Costing

Each stock movement carries a unit cost, and the specification provides for inv_cost_record, which would hold an item's cost by type and date, split into material, labor, overhead and outside processing. The specification provides for three methods; the six sessions of this course record the unit cost on each movement and do not build cost records, forecasts or the journal export. The stock balances can be rebuilt at any time by a database view over the ledger ^[3]. IAS 2 and US GAAP ASC 330 govern how inventory is measured, and your accountant owns the choice of method; the module records the unit cost it is given and does not choose the method ^[1].

Cost roll-up works up the bill of materials: a made item's cost is its components plus labor, overhead and outside processing. Activity-based costing and alignment with GAAP are core CivOps work, so the specification's inv_cost_record and journal export follow those design bases. In this course the hand-off to accounting is a CSV file of invoice match status and amounts, not the journal export. Turns, forecast error and stock-out measures are standard planning measures ^[2][4].

Five measures

Move in: the opening balance

Nothing in the old tool has to stay alive for its history. You load three things: the item planning parameters, the open purchase and sales orders, and the stock. Stock goes in as one dated opening transaction per item, lot and location, an adjustment with reason OPENING, posted through the same route as every other movement and never written into a balance directly. A counted quantity is better than the old tool's number.

The loader runs as a dry run first: it prints counts and every row it cannot match and writes nothing until it is run with --apply. The key of each opening row (item, lot, location) is its client reference, so running the loader twice leaves the stock the same.

opening row key   = item + lot + location
run the loader    -> 1 adjustment per key, reason OPENING, at the cut-off time
run it again      -> the key is already used, nothing is added
new value         = old value + (counted - old quantity) x unit cost

Reconcile before you trust it

Compare quantity and value with the old tool's stock valuation report for the same date. For each item, the new value must equal the old value plus the counted difference times the unit cost, and the totals must agree. A difference that cannot be explained is an error to find, not a rounding to accept. Do the same for open orders: the count of lines and the value still to receive.

Run the old tool and the module side by side for at least one week, with the same people entering the same movements in both. At cutover, take a final export and set the old tool read-only. Close the loader by removing its row from the matrix and showing that an insert through it is now refused. Cancel only once the new way works, and write the saving as arithmetic from your own invoices.