Procurement in Muthari OS runs from request to receipt for contractors who fabricate what they install. A purchase request is raised from the zone’s take-off — or by hand, with its own approve/reject step — becomes one purchase order routed through a three-step approval (commercial check, project manager, final approver), and is received in as many deliveries as the supplier makes. Receive 300 of an ordered 500 and the order shows 200 outstanding, the 300 land in stock as a batch under the supplier’s batch number, and the QC engineer is notified. Nobody updates anything, because the receipt is the update.
Zonal requests are created when a take-off is submitted, carrying the stock item identity. A shortfall found at allocation raises a gap request for the missing quantity only. Manual requests have their own approve/reject step, so the queue never holds a state nobody can act on.
Server-minted PO references, a supplier register, currency and VAT, and one set of statuses. Approval routes commercial check → project manager (optional) → final approver, each step written to the order’s own log with who and when. A rejected request cannot become an order; an approved one becomes exactly one.
Every approved order counts as committed cost against the material and subcontract budget. When commitments exceed it, the line goes red — a signal the approver sees on the record, not a block.
Per line: ordered, previously received, receiving now. Over-receipt is refused. Each received line is minted as a stock batch with the supplier’s batch or heat number, the order flips to partially or fully delivered by itself, and incoming QC is queued automatically.
A supplier return records the return note and reopens the outstanding quantity on the order, so the replacement delivery is received against the same PO and the trail stays in one place.
Each received line becomes a batch in the Store and a decision waiting in Quality. Muthari OS is built by contractors in the trade.