The AFTEC Work Order Model
Chapters 8 and 9 of the PRO-III conceptual manuals, read against live MRP-PROD. This is the layer between job costing and the shop floor — and it contains
WIPBMF, the most-changed code in the system.
Work orders come in three planning states
| State | Allocates components? | In MRP netting |
|---|---|---|
| Planned | No | Created, tracked and deleted by MRP itself to cover a net requirement |
| Firm Planned | No | Treated as a scheduled receipt for netting, but exploded into gross requirements as if planned |
| Firm | Yes — posted to the allocation database | A real scheduled receipt |
The firm-planned distinction is easy to miss and matters: “Firm planned orders do NOT generate allocation requirements. Therefore, they do NOT net into component availability.” A firm-planned order looks committed but reserves nothing.
…and three functional types
| Type | Purpose | Live count | Share |
|---|---|---|---|
P Production | Standard production work order | 533,728 | 94.3% |
N Non-assembly | “a part with a standard B.O.M., without the need to allocate/plan components” | 32,062 | 5.7% |
R Rework | “To rework any items that have been received through a work order, or purchase order requiring rework” | 0 | 0% |
The rework work order type has never been used at PSI — not once in 565,850 work orders. That is a
direct corroboration of John Tymes’ account of how a scrapped weldment is handled: rather than rework the
original, Ryan creates a new work order. It also explains why receiving a WO at quantity 0 is the
recurring cause of Cost Differ breaks — the designed path for that situation is a rework WO nobody uses.
Type N is the family the PROJ work order belongs to: a work order with no components, existing to
carry cost. 5,421 of the 32,062 are the job-level PROJ WOs.
System status
Planning and scheduling read one of seven states: Planned (incl. firm planned, and firm planned with unique BOM) · Unreleased · Released · Released/Partial · Complete/Manufacturing (material received complete) · Complete/Accounting (received account information complete) · History/Purged.
Note that manufacturing-complete and accounting-complete are separate states. A work order can be finished
on the floor and still open financially — and the two closes are stamped separately on OPENWO:
| Close | Field | Written by |
|---|---|---|
| Manufacturing | attr 55 MFGVARFPER — manufacturing close variance update fiscal period | CA1785 |
| Accounting | attr 50 CLOSE.UPD.FPER — WIP financial close update fiscal period | CA1776 |
alongside FIN.STAT (attr 11: "" unreleased · 1 released · 2 closed · 3 updated) and a separate
manufacturing-side WOSTAT (attr 19) with WOSTAT.DTE. The gap between the two closes is where WIP
sits. See Shop Floor.
WIPBMF — the snapshot everything hangs off
This is the single most important structure in the manufacturing side, and the manual explains it plainly:
§8.2.5 — “Upon creation of a Firm Work Order… the system creates a Bill of Material associated with the work order. This bill not only provides a list of the materials required, but carries the specific standards for the job, and is the repository for the “actual” data collected during the length of production.”
“A “snapshot” of the standard bill of material is “attached” to the work order… When the bill of material is copied to the work-in-process bill file, it is compressed into a single level regardless of the number of transient assemblies in the original bill.”
Three consequences worth internalising:
- It is a point-in-time copy. Changing the engineering BOM does not change work orders already
released. The WIP BOM is what that job was actually built from — which is why it, not
BMF, is the as-built record. - It is flattened. Transient/phantom assemblies are collapsed on copy, so the WIP BOM is single-level even where the engineering bill is deep.
- Standards and actuals live in the same structure. Budget and outturn are the same rows.
WIPROUTE is the exact parallel for operations — a snapshot of the standard routing carrying set-up, labor
hours, tooling, machines, efficiencies, and then collecting the actuals against them. With one important
exception: “The user need not release or create a standard or work-in-process routing in order to collect
labor history against a work order.” Labor can be booked to a work order with no routing at all —
which is how the PROJ WO absorbs project labor.
Why this is the hottest code in the system
WIPBMF records | 2,515,429 |
WIPROUTE.LINE records | 1,122,867 |
Changes to WIPBMF.REV6/7/8 | ~150, 1999–2026 |
WIPBMF is the join point between engineering, planning, production and costing — every one of those
subsystems reads or writes it. The change audit found it to be the most-modified program
family in the codebase, still being edited in 2026, and three concurrent revisions are live. That is not an
accident of history; it follows from the design.
Allocations
Components are allocated automatically the moment a work order becomes firm, kept in detail tied to work order and parent assembly, time-phased so MRP sees demand where it occurs, decremented as components are issued, adjusted when quantity-per changes, and cleared automatically if still open when the work order is received complete.
There is a second allocation path worth knowing about: stock requests — a demand chargeable to something other than a work order (R&D, engineering, samples) can hold an allocation or reservation. Those live in the same allocation database and appear in the same inquiry.
The three levels of cost detail
§13.4.2.8 sets out a deliberate three-tier structure, and it maps cleanly onto the files:
| Level | Grain | Files |
|---|---|---|
| WIP Summary — the WIP Ledger | User-defined material/labor/cost classes within fiscal period. “Directly supportive of the General Ledger postings” | WIPLEDGER.* |
| WIP Material / Labor Summary | By component or operation, showing Standard vs Actual vs Variance | WIPBMFCOST, WIPROUTE.COST |
| WIP Material and Labor Detail | “the direct audit trail for each material and labor transaction… contains all data and applied rates” | INVHIST, LABORHIST |
The bottom tier records the rate that was actually applied, not just the amount — which is what makes historical variance analysis and re-quoting possible years later.
Labor collection: what’s designed, what PSI uses
| Feature | Design intent | At PSI |
|---|---|---|
| Direct labor overhead | “a value-added percentage of labor. Two pools… Fixed and Variable. Overhead percentages can be assigned for the company by specific cost center” | Fixed only. COCE.VAR.PCT is 0.000 on every cost centre. The variable element is carried on all 3,226 JOBLEDGER.LAB rows — populated, but with zeros |
| Shift differential | A percentage uplift on the direct labor rate, per shift per employee | SHIFT.DEF maintained via CA1722 |
| Overtime premium | Segregated so it can post to a separate expense account rather than direct labor | COCE.OT.PREM.GLNO exists per cost centre |
| In-house sub-contractors | Identify contract staff working on site so their labor is collected and reported separately | — |
| Rework cost | A distinct actual-rework element on the labor ledger | 7 of 3,226 jobs (0.2%) — effectively unused, consistent with zero rework WOs |
| Indirect cost control | A set of indirect operations carried “in a separate set of data elements”, deliberately quarantined: “these indirect costs… DO NOT FLOW OR CONTAMINATE THE ACTUAL COST DATA flowing through to the General Ledger” | 37 of 3,226 jobs (1.1%) — essentially unused |
| Applied-vs-actual overhead readjustment | Net the cost database when applied standard overhead diverges from actual — “usually some minor customization is required” | No evidence of it running |
That quarantine rule is the answer to what JOBLEDGER.LAB attributes 10–13 (IND-LAB-COST, IND-RWK-COST,
IND-FIX-OVHD, IND-VAR-OVHD) are for. They are indirect costs held deliberately outside the G/L-bound
actuals. Anyone summing the labor ledger for a G/L reconciliation must exclude them.
Other direct charges and estimate-to-complete
ODC (§13.4.2.6) posts through vouchering: supply work order or job number, an A/P transaction code
from a user-defined table, fiscal period and amount. That is precisely the JOBLEDGER.AP shape, and PSI’s
codes are TRAVEL, MISC, COMMISSION.
Estimate to complete (§13.4.2.7) — “Open purchase material amounts can be automatically posted to
the material categories as estimate to complete” (that is CA1774A), while labor, outside services and
special purchases are entered as a percent remaining. PSI maintains percent-complete on 67 jobs and none at
work-order level, so this runs at a fraction of its designed coverage.
For the migration
The as-built record is WIPBMF, not BMF. Any historical cost or configuration question about a
delivered machine has to be answered from the work-order snapshot, because the engineering bill has moved on
since. This affects how BOM history is migrated.
Labor without a routing is normal here, not an exception — it is how project engineering time is booked. A BC design that requires a routing to book time will not fit.
Manufacturing-complete and accounting-complete are separate. The gap between them is where WIP sits, and
it is managed by FIN.STAT and WIP.CLOSE.
Exclude indirect elements from any G/L tie-out. They are designed to be outside it.
Related: Design Intent vs Practice · Change Audit · AFTEC Job Costing & WIP · Inventory & Work Orders · WBASE · SFBASE