The task's Bill of Resources plans what a project consumes. Issue that material from stock against the task through the shared store engine, and the planned BOR becomes real consumption and actual cost. What's short raises a project purchase requisition for Fast Purchase, and every project reads live Fast Inventory stock. Plan, issue, PR and cost are one continuous chain on the same tables — no export file, no middleware, no reconciliation.
Once a task's Bill of Resources is planned from the Resource master, it drives two handoffs against live stock. Material that's in stock is issued from the store against the task, turning the plan into actual consumption and cost. Material that's short raises a project purchase requisition for Fast Purchase. Both are ordinary platform documents on the same tables — nothing is re-keyed.
Because Fast Project Management, Fast Inventory and Fast Purchase share one platform, each step writes to the same tables the next step reads. There is no import, no reconciliation and no drift between what was planned, what gets issued and what gets bought.
Every link below is a native table-level connection on the shared platform — the task BOR, store issues, project PRs, stock and the Item & Resource master are the same records read from every module, not files passed between separate systems.
A task's Bill of Resources plans what it will consume, at the Resource master rate. As work proceeds, that material is issued from stock against the task through the shared store engine — moving real stock in Fast Inventory and booking the actual quantity and cost to the task. The quantity, item and rate the planner set carry through to the site without anyone typing them again.
A project is only as reliable as the stock it plans against. Each project reads live Fast Inventory stock on hand plus reorder parameters, and compares the task BOR against it: Shortfall = BOR quantity − Stock on Hand − Open Project PO. Whatever is still short raises a project purchase requisition for Fast Purchase. See the stock ledger at Fast Inventory.
When project management, inventory and purchasing are three systems, the gaps between them are where errors live — a BOR exported, a store issue re-typed, a stock figure that no longer matches, a PO nobody nets against. On the shared platform there is no gap: the Item and Resource master a task BOR draws from, the stock it issues against and the party master are the same records every module reads. What the plan commits is exactly what the store issues and what procurement buys.
Material planned in the task BOR is issued from stock against that task through the shared store engine, moving real stock and booking actual cost.
Task shortfalls become project purchase requisitions (ProjectPRPending) consumed by Fast Purchase through PR to PO to GRN.
Every project reads live Fast Inventory stock and reorder parameters, comparing the BOR against stock on hand and open project POs.
As material is issued and consumption recorded, the planned Bill of Resources turns into actual consumption and budget, comparable against the estimate.
The shortfall list watches project demand against free stock and reorder points, proposing a project purchase requisition per item short.
The Item and Resource master, stock and party master are the same records Inventory and Purchase use — no interface, no reconciliation.
In a 30-minute demo we'll take a task through its Bill of Resources, a live-stock store issue and a project purchase requisition — one continuous chain, no re-keying.
