Routing
Routing carries more PSI-specific engineering than any other area of AFTEC.
CA1740— standard routing maintenance — is the third most-rewritten program in the entire codebase, PSI added a nine-field extension to 359,845 routing lines, and built a custom dispatch pipeline on top. Meanwhile the vendor’s own routing cost file is empty.
The structure
Routing exists three times over, each as a head / line / note trio:
| Purpose | Live records | |
|---|---|---|
SROUTE.HEAD / .LINE / .NOTE | Standard routing — the engineering master for a part | 152,290 / 257,084 / 21,711 |
WIPROUTE.HEAD / .LINE / .NOTE | WIP routing — the per-work-order snapshot | 560,009 / 1,122,867 / 109,185 |
ALTROUTE.HEAD / .LINE | Alternate routing — an alternative process for the same part | 176 / 316 |
WIPROUTE.COST | Costs against the WIP routing | 1,126,270 |
OPERATION | The operation code table | 375 |
WOCE / WOCE.1287 | Work centres | 84 / 106 |
Same pattern as the bill of material: “a snapshot of the standard routing is attached to the work order as the Work-in-Process routing” (§8.2.9), carrying set-up, labor hours, tooling, machines, re-set-up and efficiencies — then collecting the actuals against them. See The Work Order Model.
Alternate routings are essentially unused — 176 headers against 152,290 standard routings.
Where the customisation is
CA1740 — the third most-rewritten program in AFTEC
PBSBASE/CA1740, internally titled ROUTE.EM, “allows entry and maintenance of the (SROUTE…) files”.
Against the vendor baseline: +592 / −273 real code lines, 774 → 1,104. Only I.0001 (inventory) and
E0052 (bill of material) were rewritten harder.
CA1746 — WIP Routing Entry and Maintenance, already carrying a 1989 note “MOD BY MW FOR PROJECT
PLANNING” — is close behind, along with CA1740.2, CA1743.2 and CA1746.2. Seventeen routing-related
programs carry PSI code changes.
WIPROUTE.LINE.1287 — nine fields added to every routing line
The .1287 suffix marks a PSI extension file. This one holds 359,845 records — roughly a third of all
WIP routing lines:
| Attr | Field | What it adds |
|---|---|---|
| 1 | CRIT.DIM | Critical dimension flag — quality |
| 2 | F/L INSP | First / last article inspection |
| 3 | OP.STAT / OP.PROG | Operation status and progress |
| 4 | LINE.NOTES | Per-operation notes |
| 5 | PPRI.LN | Part-level priority |
| 6 | GPRI.LN | Global priority |
| 7 | OS.VEND.NO | Outside vendor, on the operation |
| 8 | OS.DUE.DATE | Outside due date, on the operation |
| 9 | SU.CODE | Set-up code |
Three distinct capabilities bolted onto the vendor’s routing line: quality control (critical dimension, first/last inspection), live operation tracking (status, progress, priorities), and outside-processing scheduling.
That last one is a real departure. The vendor design routes outside processing through purchasing — “define an outside operation on a Purchase Order along with the Work Order, Cost Center, Work Center and operation” (§13.4.2.5). PSI put the vendor and the due date on the routing line itself, so the shop floor can see and schedule it without going to the PO.
UPD.WIPROUTE.LINE — a custom dispatch pipeline
Written by JPT in 2014, changed 17 times through 2025. Its own header:
“COPY DATA FROM WIPROUTE.LINE AND WIPROUTE.LINE.1287 TO WORK.WIPLINE.1287 FOR THE DISPATCH LIST.”
The change log reads as a decade of shop-floor requirements: operator status per line (2014), queue / wait /
move time overrides (2015), stock destination derived from the first work unit in ITEMMANF (2016),
#JOB records for raw material feeding assembly (2019), then automating those with looping, then excluding
drywall from them.
This is PSI’s dispatch list, not AFTEC’s. The vendor ships SF3210 and friends; what the floor actually
sees is assembled here by merging the vendor routing with PSI’s extension.
VB_BOMNOTROUTED / NOTROUTED.1287 — routing coverage control
A PSI-built control (JPT, 2000) that finds bill-of-material lines with no routing, in three revisions,
still being changed in 2026. NOTROUTED.1287 holds 112 live rows keyed by date, net quantity and project.
It exists because an unrouted component is invisible to shop-floor scheduling and collects no labor —
a gap the vendor system does not police.
What the vendor shipped and PSI does not use
| Live records | ||
|---|---|---|
ROUTECOST | 0 | The routing cost file. CA1787 maintains it, CA1786 rolls costs into it, CA1788 lists it — all against an empty file |
ALTROUTE.LINE.1287 | 0 | The PSI extension on alternate routings |
ALTROUTE.HEAD / .LINE | 176 / 316 | Alternate routings, against 152,290 standard ones |
SROUTE.LINE.1287 | 257 | The extension is on WIP routing lines, not standard ones |
The ROUTECOST finding fits the pattern established in
Design Intent vs Practice: the standards-and-variance apparatus is dormant across the
board. Routing costs roll up through CA1770 into ITEMCA for the last-cost model instead.
That the extension file is on WIP routing lines and barely present on standard ones is the tell: PSI’s investment is in tracking work as it happens, not in maintaining a richer engineering master.
For the migration
Routing is where the custom requirements live. A migration that maps the vendor’s routing model one-for-one will lose nine fields per operation, the dispatch pipeline, and the unrouted-BOM control — none of which appear in the vendor documentation, because PSI wrote them.
Outside processing is scheduled from the routing line here, not only from the PO. Vendor and due date at operation level need somewhere to live in BC.
Quality flags ride on the routing. Critical dimension and first/last-article inspection are operation attributes at PSI, which is a natural fit for BC routing lines but has to be deliberately carried.
Don’t migrate ROUTECOST or alternate routings without checking whether anyone wants them — one is
empty, the other has 176 rows against 152,290 standard routings.
Related: The Work Order Model · Design Intent vs Practice · Change Audit · SFBASE · CABASE