User
The user model is the authentication entity of the whole system. Every person — the ghost superuser, managers, unit heads, store keepers, employees — is a user. It carries roles (with an org/unit scope), features (fine-grained permission flags), and membership in organizations and units.
File
The file model stores metadata about an uploaded file — its name, MIME type, size, and a coarse type bucket (image / video / docs / other). The actual bytes are served from the static uploads folder (/uploads, see staticPath in the entry point); the file document is the reference that relations point at.
Tag
tag is the simplest model in the app — a lightweight label (name + color) used to classify products. It has no relations of its own, but products hold a tags relation to it, so the tag gets a products back-reference injected by the relation engine.
Organization
organization is the tenant — a hospital, clinic, or chain. It supports a self-referencing parent tree (organizations can nest), and almost everything else hangs off it: units belong to it, purchase orders are raised in it, budget lines and tenders are scoped to it.
Unit
unit is a department or warehouse inside an organization. Every unit belongs to exactly one organization (required), can have a head user and a parent unit (a tree), and is the scope object for step approvals and inventory ownership — approval steps assign units, and stores are owned by units.
Product
product is an item in the procurement catalog — the thing a purchase order buys. It collapses a full category hierarchy into a single self-referencing parent relation, carries a price, an active flag, and optional tags.
Store
store is a physical storage place — a warehouse or a shelf. Inventory is tracked per store, and stores belong to a unit (typically the Warehouse-type unit that owns them).
Inventory
inventory tracks the stock level of one product in one store. A unique compound index on (store, "product._id") guarantees exactly one record per store+product pair. Records are created and updated by the inventoryManager utility (addStock, removeStock, transferStock), not directly by the acts.
StockMovement
stockMovement is the audit ledger of every inventory change. It's a read-only model in practice — records are written by the inventoryManager utility whenever a store's quantity changes. Each entry captures the signed quantity, the balanceBefore / balanceAfter, a reason, and an optional reference to the triggering document (e.g. a purchase order).
Process
process is a workflow configuration — it defines how purchase orders flow through approval steps. Its lifecycle is Draft → Active → Archived; only an Active process can govern purchase orders. A process has ordered steps (see the processStep model) and belongs to one organization.
ProcessStep
processStep is one step inside a process workflow. Each step has a stepType (Approval, Review, Notification, Action, Delivery, Receipt, Payment), an order number, and assignee groups with AND/OR logic: the step's groupsOperator combines groups, while each group's internal operator combines its unitIds.
PurchaseOrder
purchaseOrder is the core procurement document. It's created as a Draft, submitted to begin the workflow (Pending), and flows through step approvals (InProgress → Approved/Rejected → Completed/Cancelled). It carries an embedded history[] of every performed action and, on submit, encumbers budget against a budgetLine.
StepApproval
stepApproval records one unit's decision on one step of one purchase order. It's created automatically when an order reaches a step (for every assignee unit), and submitDecision processes a unit's vote, evaluates the step via evaluateStepStatus(), and auto-advances the order — or marks it rejected/completed.
BudgetLine
budgetLine is a budget allocation that purchase orders draw against. The lifecycle: PO submit creates an encumbrance (reserves funds), PO finalize converts the encumbrance to spend, and PO cancel releases it. remainingBudget is kept in sync by the workflow acts — the model itself just stores the numbers.
Tender
tender is a public procurement auction for a purchase order. It collects offers from suppliers in an embedded offers array, and when awarded, the winning offer's price becomes the order's committed amount.