Modules
A module is an operational capability — a kind of record that does something, moves stock, and progresses through a lifecycle. Where master data is the set of stable nouns, modules are the verbs: placing a purchase order, producing finished goods, shipping a sale.
The defining idea of the Pharus architecture is that each module is independent. Each one has its own lifecycle and its own well-defined effect on inventory. You can adopt a module on its own, and you can combine modules in different ways depending on how your business runs — that's what the Pipelines section is about.
Orders
The order modules each represent a commitment that plays out over time.
| Module | In one line |
|---|---|
| Purchase Orders | Buy materials or finished goods from a vendor |
| Work Orders | Send materials out for contract assembly and get products back |
| Production Orders | Subcontract full manufacturing of a product |
| Sales Orders | Commit to ship products to a customer |
| Sales Receipts | Record a direct-to-consumer sale in fractional cases |
| Sales Returns | Bring product back from a completed sale and restock it |
Inventory
The inventory modules are the running record of stock.
| Module | In one line |
|---|---|
| Materials Inventory | The ledger of raw-material stock |
| Finished Goods Inventory | The ledger of product stock |
| Inventory Transfers | Move stock between locations |
| Conversions | Repack finished goods across levels or packaging |
Inventory ledger events
Every order module ultimately writes to one or both inventory ledgers. Rather than flipping a single stock number, each movement is appended as a ledger entry, and the current position is derived by summing those entries. The vocabulary is shared across modules and is identical on both ledgers: seven events cover everything either one can do.
This is the single canonical list of every event the two ledgers can hold. Each forward
event has a matching REVERSE_ form that backs it out (how a cancelled order or a
corrected mistake is undone), and the two order-closing figures carry a SETTLE_ form
that trues an order's open position to zero when it closes. ADJUST and DISPOSE are the
manual events and have no reverse; to undo one, post its opposite.
| Event | Reverses with | Settles with | Meaning |
|---|---|---|---|
| ORDER | REVERSE_ORDER | SETTLE_ORDER | Placed on an order, expected in but not yet received |
| RECEIVE | REVERSE_RECEIVE | (none) | Arrived into a location: bought, produced, or transferred in |
| DEMAND | REVERSE_DEMAND | (none) | Wanted by a sales order, or by a job that consumes it |
| ALLOCATE | REVERSE_ALLOCATE | SETTLE_ALLOCATE | Set aside for a specific order or job |
| CONSUME | REVERSE_CONSUME | (none) | Left a location: shipped, used up by a job, or transferred out |
| ADJUST | (none) | (none) | Manual count correction, up or down |
| DISPOSE | (none) | (none) | Manual reduction (loss, scrap, write-off) |
The vocabulary describes what happened to stock, never who did it; that is what the entry's source is for. A RECEIVE might be a vendor delivery, a production run coming back, or a transfer arriving, and the entry's source and reference say which. That is also why a transfer needs no event of its own: it is an ordinary CONSUME at the location it leaves and an ordinary RECEIVE at the one it reaches, tied together by the transfer's code.
The SETTLE_ rows are system-written when an order closes at Received and removed if it
reopens: SETTLE_ORDER trues on-order to zero (ORDER - RECEIVE - SETTLE_ORDER) and
SETTLE_ALLOCATE trues a job's allocated stock to zero
(ALLOCATE - CONSUME - SETTLE_ALLOCATE). Each carries the signed gap, so the one entry
closes the figure whether the order came up short or over. The
inventory pages explain how these events sum into
on-hand, on-order, demand, and allocated positions.
Everything here is reachable through the REST API and the MCP server.