PSI Knowledge Base

Product Master & Bill of Material — where PSI replaced AFTEC

4 min readEdit this page

Product Master & Bill of Material

I.0001 and E0052 are the two most-rewritten programs in AFTEC. One of them is not a modification at all — PSI threw the vendor’s version away and wrote its own, and that replacement is where PSI’s Group Technology model lives.

I.0001 — PSI replaced the part master screen outright

The most-diverged program in the codebase: 922 → 1,236 lines, +1,028 / −748. It is not a heavily-patched vendor program. PSI says so in the header:

“THIS PROGRAM REPLACES THE AFTEC VERSION. Many of the fields that were defaulted to in the AFTEC version no longer appear to the users at all. Additional fields such as routing suggestions and manufacturers part number have been added.”

“WRITTEN BY CFS 8/29/95”

The vendor original (0001, Randall Downer, 1981) is Product Master File Entry and Maintenance — the single most fundamental data-entry screen in the ERP. PSI rewrote it in 1995 and then revised it through 2001.

It is where the GT code model is enforced

The replacement introduced PSI’s Group Technology structure, and the code is explicit about it:

GET.GT.CODE:
  PRINT "ENTER AN ENGINEERING CROSS-REFERENCE, 'PRODUCT' OR 'PHYS.'"
  INPUT GT.CODE
...
GT.CODE = ITEMMANFREC<9>

with a save-routine rule recorded in the revision log:

“CFS 9/27/95 — ADDED TO THE SAVE ROUTINE TO ADD THE PROD/PHYS. POINTERS IF THE GT.CODE IS ‘PRODUCT’ AND THE MRP IS ‘D’” “CFS 3/28/96 — NOW ALLOW PRODUCT PHYSICALS TO BE ABLE TO CHANGE THEIR GT CODE”

Live, on ITEMMANF attribute 9:

Count
ITEMMANF records424,682
GT code set278,878 (66%)
GT code = PRODUCT22,410
GT code = PHYS.20,627
Everything elseengineering cross-references

This matters for the migration. The PRODUCT ↔ PHYS. linkage that the BOM structure and PRODUCT.1287 map both describe is not an AFTEC feature. It is PSI’s, it was introduced in a 1995 screen rewrite, and it is enforced at data-entry time by a program, not by the schema. Nothing stops a record created by any other route from violating it — which is the likely origin of the small set of genuine link defects found in the fleet audit.

See also GT codes in the LDS methodology and the terminology glossary.

E0052 — the bill of material, and a methodology correction

Correction

An earlier version of the change audit called this out as “the vendor shipped a 16-line stub and PSI wrote 1,461 lines”. That was wrong, and the cause is worth recording because it affects how the divergence numbers should be read.

The vendor’s AFTEC/E0052 is a 17-line dispatcher:

CALL FLAGSUB("BOM", BOMFLAG)
IF BOMFLAG = "Y" THEN CHAIN "E0052.DOD" ELSE CHAIN "E0052.COMM"

At some point the vendor refactored BOM maintenance into a dispatcher plus two variants — E0052.COMM (866 lines, commercial) and E0052.DOD (736 lines, government). PSI’s tree kept the pre-refactor monolithic program and grew it to 1,461 lines. Its own header still carries the original 1985 date and a revision log running from 1989.

So the real comparison is 866 → 1,461 lines against the commercial variant, and even that understates the divergence: line-level similarity to either vendor variant is only about 0.24. The BOM maintenance program is still one of the most heavily customised in the system — just not in the way the raw number suggested.

What this means for the divergence figures generally

The change audit matches vendor to running program by name. Where the vendor later split or renamed a program, that comparison is meaningless. Sweeping the 397 code-changed programs:

  • 59 have a suspicious size ratio (PSI more than 2.5× the vendor, or a vendor file under 60 lines)
  • 20 of those have a vendor file that is a small CHAIN dispatcher

Most are small driver PROCs where the delta is a few dozen lines and does not move the totals. E0052 is the one case that distorted a headline. The aggregate — 397 programs, +22,357 / −15,793 lines — is overstated by roughly 8% because of the two E0052 entries; the shape of the finding is unchanged.

Reading the two together

Both programs are master-data entry screens, and both are among the most rewritten in the system. That is not a coincidence. The vendor’s data model is generic; PSI’s is not — GT codes, product/physical pairing, routing suggestions, manufacturer part numbers. Where a package cannot express your model, the entry screen is where you bolt it on.

The consequence for BC is direct: a meaningful part of PSI’s data model is implemented as validation logic inside two green-screen programs. It is not in the schema, not in the dictionary, and not in the vendor documentation. Migrating the data without migrating those rules moves the records and loses the model.

Related: Routing — the same pattern, at greater scale · Change Audit · Design Intent vs Practice · PRODUCT BOM Structure · EBASE · IBASE

Graph View

Backlinks