AFTEC Design Intent vs Practice
Recovered 2026-08-10 from
AftecPro3Master1–3.pdf— 160 scanned pages, OCR’d with Tesseract. These are the conceptual manuals, distinct from the per-module program references: 18 chapters explaining what PRO-III was designed to do and why. Copyright Aftec Prop Inc., 1983, Florham Park NJ.
The per-module manuals tell you what each program does. These tell you what the system was for. Read against live record counts, they also reveal how much of the designed apparatus PSI never adopted — which is the single most useful thing here for the ERP migration.
These pages were nearly lost
All three volumes are image scans; text extraction yielded ~50 bytes. Worse, 35 of the 160 pages were scanned sideways or upside down and OCR’d to pure gibberish on the first pass. Orientation had to be detected per page and the images rotated before re-running. If you re-do this, check orientation first.
The system as its designers described it
| Ch | Module | Ch | Module |
|---|---|---|---|
| 1 | Software overview & database design | 10 | Master Planning |
| 2 | Estimating | 11 | Material Requirements Planning |
| 3 | Order Entry / Invoicing / Sales Analysis | 12 | Project Budgeting and Control |
| 4 | Inventory | 13 | Cost Accounting |
| 5 | Bill of Material | 14 | Job Cost Ledger |
| 6 | Configuration Control | 15 | Accounts Payable |
| 7 | Purchase Order | 16 | Accounts Receivable |
| 8 | Work-in-Process | 17 | General Ledger |
| 9 | Shop Floor | 18 | GL Financial Statement Generator |
PRO-III-MASTER is described as “a fully on-line, interactive closed loop MRP-II system with integrated financial accounting, cost accounting, and order control” — bucketless planning, infinite horizon, multi-company, comprehensive time-stamped audit trails. Volume 3 is the diagram appendix.
Job costing, in the vendor’s own words
This settles a question that took three rounds to get right on the job costing page.
§13.5.1 — “The user simply defines a Job, contract, or project in the job master file and identifies which work orders are for that particular job number. All data and costs still flow through the Work-In-Process system, but, in addition, also accumulates in the Job Cost data/base under the proper job number.”
“In addition” — dual posting, stated by the designers. Not a roll-up. That is the fourth independent
confirmation, after John Tymes’ correction, the absence of callers for ACT.CA1778, and the GL7013C
program title.
§13.5.3.1 — “If the user has defined budgets (standards) for the detail work orders that make up a Job, they may ‘roll up’ that information into the Job Budget fields… the user simply executes the Work-In-Process/Job budget roll up program.”
The roll-up exists, and it is explicitly for budgets and standards — which is exactly the CA1777 /
CA1778 path PSI never adopted.
§13.5.1 — “This Job Cost data/base will balance with the General Ledger totals for the corresponding entries.”
This one matters operationally. The job ledger balancing to the G/L is a design guarantee, not an
aspiration — so a non-zero COST.DIFF in SO Manager is a defect by definition, not an expected rounding
artifact. It is why GL7013C exists at all:
§13.6.3 — “In order to balance the Job Cost data/base to the General Ledger, Journal entries will allow the user to post against a specific Job.”
The seven WIP G/L accounts
§13.6.2 — every work order carries seven G/L account numbers, defaulted from the Product Category Account Master and overridable per work order:
W.I.P. Material · W.I.P. Material Overheads · W.I.P. Direct Labor · W.I.P. Fixed Overheads ·
W.I.P. Variable Overheads · W.I.P. Outside Processing (material) · W.I.P. Outside Processing Overheads
That is a one-to-one match with the cost elements in WIPLEDGER.STR / JOBLEDGER.STR. The cost-stream
file is the G/L account structure, held per work order per fiscal period.
The G/L interface is switchable, three ways
§13.6.1 — the interface is not all-or-nothing. Software switches choose which interface points are
active, and for each, the level of control: manual posting, post a journal entry with detail, or
direct detail posting to General Ledger. Those switches live in SYBASE company standards — worth
reading before assuming how any given cost element reaches the ledger.
The user designs the cost sheet
§13.5.4.1 — costing categories are user-defined, not fixed. A 10-character alphanumeric cost transaction code per area (material, labor, outside, A/P) lets the user “design the cost categories of a customized JOB COST SHEET”, presented across the standard columns: Period to Date · Year to Date · Job to Date · Estimate to Complete · Budget/Standard · Variance.
That is what PSI’s CA classes (M1, M9, M1.V) and A/P transaction types (TRAVEL, MISC,
COMMISSION) actually are — not a fixed chart, but a customer-designed reporting structure. Any BC design
has to carry PSI’s specific set, not a generic one.
What PSI actually uses
Live record counts, 2026-08-10. This is the part worth taking to the migration.
Live and load-bearing
| File | Records | |
|---|---|---|
WIPLEDGER.STR | 523,470 | WO cost stream — the largest costing file in the system |
WO.VARHIST | 39,680 | Work order variance history |
JOBLEDGER.STR | 2,614 | Job cost stream |
JOBLEDGER.SGA | 1,976 | SG&A burden by period |
JOB.PCT.COMP | 67 | Percent complete, a minority of jobs |
Documented in detail, holds zero records
| Subsystem | Files | Designed to do |
|---|---|---|
| Job Cost Ledger (Ch 14) | JCL.COST.CENTERS | A true subsidiary ledger with up to 999 user-defined job financial-statement formats, cost-of-sales reporting by job, this-year-vs-last-year, labor-grade detail within cost centre |
| Cost Accounting budgets | CA.BUDGET.HEAD / .LAB / .MAT / .ODC / .OUT / .JOBSUM | The entire budget-vs-actual apparatus |
| Detail financial control | JOB.DET.FC, WIP.DET.FC | Job and WO financial control status (PB4520 / PB4521) |
| Consignment | WIPLEDGER.CON, JOBLEDGER.CON | Consignment value issued |
| Estimating ledger | ESTLEDGER | Estimate-to-actual carry-through |
| WO percent complete | WO.PCT.COMP | WO-level ETC (the job-level equivalent has 67 rows) |
| WIP financial relief | WIP.RELIEF | The relief half of the release/relief/close cycle |
| WBS / cost accounts | COST.ACCOUNT | 141 rows, but see below — none of them is a cost account |
Correction —
COST.ACCOUNTis not "lightly used", it is orphanedAn earlier version of this page listed
COST.ACCOUNT(141 rows) under live. That was wrong. All 141 records have a key ending in!— no cost-account number at all — with attributes 1–6 empty (0 have a description, 0 have a status, 1 has a WBS) and work-order numbers sitting in attribute 7.That exact shape is what the vendor’s own repair utility was written to destroy.
FIX.COST.ACCOUNT(Rick Murphy, 1990): “DELETES COST.ACCOUNT RECORDS THAT HAVE A NULL COST ACCOUNT NUMBER IN THE KEY, DELETES ATTR 7 FOR ALL OTHERS.” Every record in PSI’s file is the precise pattern that program removes. The WBS / cost-account module is not partially adopted — it holds 141 orphans and zero real cost accounts.
Chapter 14 is the striking one. PRO-III ships a complete job-cost subsidiary ledger and financial
statement generator — “for the first time, the user can have up-to-the-minute actual cost performance in
the format and detail chosen”, explicitly pitched at collecting progress payments. PSI has never put a
record in it. What PSI built instead is JOB.IP.1287 and the SO Manager Job Cost tab: a daily snapshot and
a reconciliation, written in-house in 2017.
Chapter 12 — Project Budgeting and Control
The WBS module was designed to give a project manager real control: budgets by Project/WBS/Cost Account, a baseline budget with multiple on-line revisions, planned-versus-released-versus-actual, and — the part PSI might actually want — the ability to close or restrict charges at four levels independently: project/job, cost account, work order, and specific charge type, with an on-line supervisory override under password.
None of it is in use. The control files (JOB.DET.FC, WIP.DET.FC) are empty and COST.ACCOUNT holds
only orphans. Charge control at PSI is whatever JOBMASTER.DATE.CLOSE and FIN.STAT enforce.
Why so much is dormant
A consistent pattern: PSI runs actuals, not standards. Budgets, standards, financial release, relief, and the variance-against-standard machinery are all part of one designed workflow, and PSI adopted none of it. The parts that are live are the parts that record what actually happened.
The DoD lineage explains much of the rest. §13.5.2 points at PRO-III-DOD for C/SCSC reporting and
progress payments, and Chapter 14 is flagged as a DOD supplement feature. The WBS, cost accounts, MIL-STD
labor reports and Type I coverage reporting in CABASE are all government-contracting apparatus that PSI
inherited with the package and largely does not need.
For the Business Central migration
Do not rebuild the dormant two-thirds. Six subsystems here are documented in detail and hold no data. Anyone scoping from the manuals — or from a module inventory — will over-scope badly. Scope from record counts.
Do carry the cost transaction codes. They are customer-designed, and PSI’s specific set is the reporting structure finance actually uses.
The G/L balance is a design guarantee. The job ledger is specified to balance to the general ledger.
Whatever replaces it needs the same guarantee and the same daily variance check — see
AFTEC Job Costing & WIP for how COST.DIFF works today and what breaks it.
Seven WIP account buckets, not one. Material, material overhead, direct labor, fixed overhead, variable overhead, outside, outside overhead — defaulted by product category, overridable per work order. BC’s posting-group model needs to reach the same granularity.
Still unmined
The OCR’d text is at AftecPro3Master1–3.txt (~397,000 characters) alongside the module manuals. Chapters
worth a proper read that this page only samples:
- Ch 8 Work-in-Process and Ch 9 Shop Floor — the design intent behind
WIPBMF, the hottest code in the system (see the change audit). - Ch 12 Project Budgeting and Control — the WBS / cost-account model, most of which is dormant but which
the
PROJwork order andCOST.ACCOUNTstill lean on. - Ch 13.4.2.4 — labor collection in detail: shift differential, overtime premium, in-house subcontractors, payroll interface, readjustment for applied overheads, indirect cost control.
- Ch 1.2 — the relational/first-normal-form database rationale, which explains why the multivalue design looks the way it does. Pairs with Reading UniBasic.
Related: AFTEC Module Reference · Change Audit · AFTEC Job Costing & WIP