FORGE/i — Manufacturing Resource Planning

FORGE/i is a discrete-manufacturing MRP core: an item master with a multi-level bill of materials, work orders that explode the BOM and allocate components, shop-floor material issue and completion receipt, an accumulating inventory ledger, a weekly MRP regeneration with reorder suggestions and ABC re-ranking, and a monthly close that rolls standard cost up through the BOM, values work-in-process, and posts a balanced feed into the general ledger. It runs on four job cycles — daily, weekly, monthly and annual — each a CL that chains a set of RPG/COBOL programs. This manual is the reference for the operator who runs the online inquiry screens and the periodic cycles, and for the developer maintaining the application. It is grounded entirely in the committed source (mrp-app/src/sources.mjs for library FORGE, src/seed.mjs, and the test/forge_*.mjs drivers).

A. Overview & Architecture ↑ top

A.1 What it does

FORGE/i plans and tracks the manufacture of discrete goods — a pump family built from sub-assemblies and raw parts:

• Item & BOM master. Every part is an item (FGITEM) typed F finished / S sub-assembly / R raw; that letter drives whether MRP explodes the item through its bill of materials (FGBOM) or treats it as a purchase.
• Work-order release. A planned work order is exploded one BOM level into material lines (FGWOMAT), the components are allocated on the item master, and the order flips to released — with a scrap uplift applied per component.
• Shop-floor posting (daily). Material is issued against released orders (relieving on-hand and allocation) and completions are received back into finished stock at standard cost, rolling the order to complete when the full quantity is made. Every movement is journaled to the inventory ledger (FGITRN).
• MRP regeneration (weekly). For every active item, gross requirement is summed from open work-order demand, netted against on-hand less allocation less safety stock, and a replenishment order is suggested; items are re-ranked A/B/C by inventory value and a suggestion report spools.
• Monthly close. Standard cost rolls up through the BOM (sub-assemblies, then finished goods), work-in-process is valued from issued material, and a balanced debit/credit feed is posted to the GL, proved by a COBOL trial balance.
• Annual roll. A physical-inventory count writes variance adjustments and corrects book on-hand, the cost year is re-rolled, and the ledger is archived.

A.2 Single-layer architecture: RPG/DDS over keyed physical files

Honest statement: FORGE/i is a classic RPG-over-DDS application — unlike LOANSVC/i it does not push its business logic down into a DB2 SQL-PL layer. The manufacturing rules (BOM explosion, scrap uplift, netting, cost roll-up) live in the RPG programs themselves, operating directly on keyed physical files. SQL appears in exactly two places, both deliberate:

• The GL feed (FGGLFEED) is an SQL table created by RUNSQLSTM, and the monthly GL-post program FGGLPST is the one SQLRPGLE member — it reads the ledger with native I/O but writes the GL with embedded EXEC SQL INSERT.
• The trial balance (FGGLRPT) is hand-written ILE COBOL reading the ledger's keyed side, proving the month's postings.

Everything else — 12 further RPG programs, 3 display files, 1 printer file, 8 physical files and 2 logical files — is native RPG/DDS. The whole application lives in library FORGE; FGSETUP (CL) creates every object and compiles every program, and the four cycle CLs drive them. The tested jobs run with LIBL = QSYS QGPL FORGE QTEMP and CURLIB = FORGE.

A.3 Component & flow

  ONLINE                 DAILY (FGDAILY)        WEEKLY (FGWEEK)
  ------                 ---------------        ---------------
  FGMENU (5250)          FGWOREL  explode+alloc FGMRPGEN  net demand -> FGMRP
   1 -> FGITEMIQ         FGISSUE  draw material  FGABC     re-rank A/B/C by value
   2 -> FGWOIQ (subfile) FGRECPT  receive done   FGMRPPR   spool suggestion report

  MONTHLY (FGMONTH)                 ANNUAL (FGYEAR)
  -----------------                 ---------------
  FGCSTRL  roll std cost up BOM     FGPHYS   physical-count variance
  FGWIPVL  value work-in-process    FGCSTRL  re-roll cost year
  FGGLPST  post balanced GL feed    FGGLRPT  trial balance
  FGGLRPT  trial balance (COBOL)

                    +----------------------------------------------+
   FGITEM (item+BOM spine) <--reads/updates-- every program        |
     |   FGBOM / FGBOMLF (parent/component access paths)           |
     |   FGWO / FGWOLF <-- FGWOMAT (order material lines)          |
     +-> FGITRN (accumulating inventory ledger: I/R/A/V)  <--------+
         FGMRP (weekly plan rows)   FGCSTH (cost-change history)
         FGGLFEED (SQL GL feed)     FGWKCTR (work centres)

A single event — say a daily material issue — flows: FGISSUE reads each open FGWOMAT line → CHAINs the component in FGITEM, relieving ONHAND and ALLOC → writes one FGITRN issue row under a stable ledger key → flips the line to issued. No control table gates the run; idempotency comes from the ledger key (section F.3), so a re-submitted cycle re-derives the same key and is refused rather than double-posting.

A.4 Object inventory

The full catalogue is 8 PFs + 2 LFs + 1 SQL table, 3 DSPFs + 1 PRTF, 14 RPG programs (13 RPGLE + 1 SQLRPGLE), 1 COBOL program and 5 CL programs, all in library FORGE. Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

FORGE/i has no CICS transaction identifiers and no menu-driven transid switch. On IBM i, each program is reached by name from a 5250 command-entry line (or a JOBQ/scheduler for the batch cycles). The operator equivalent of "type a transid and Enter" is "type a CALL command and Enter". Before invoking anything, the job's library list must include FORGE.

Every batch program takes no CALL parameters. There is no LOANSVC-style control table: processing dates are compiled constants in the source (for example the daily issue posts TDT = 20260801, MRP stamps RUNNO = 202631, the monthly GL batch is 202608). A scheduled submission is therefore a bare CALL. Only FGMENU, FGITEMIQ and FGWOIQ are interactive; the batch programs run to completion and DSPLY a one-line result.

B.2 The menu & inquiry screens

FORGE/i ships three interactive programs. FGMENU is the entry point; it CALLs the two inquiries program-to-program and returns to the menu when they exit.

Key 1 or 2 and Enter; FGMENU CALLs FGITEMIQ or FGWOIQ. Any other non-blank option shows Invalid option. on the menu itself. F3 ends the program.

Item inquiry (FGITEMIQ / FGITEMD)

A plain (non-subfile) screen. Key an item number, press Enter; the program CHAINs FGITEM and renders the master record plus a derived available-to-promise figure (ONHAND − ALLOC). A miss shows Item not found. and clears the detail rather than leaving stale values.

The available figure is genuinely derived, not stored: with two released orders drawing 10 + 10 units of the housing, 100 on-hand − 20 allocated renders as 80.00. The packed 11P4 standard cost renders at full precision (42.5000).

Work-order inquiry (FGWOIQ / FGWOD)

The app's subfile screen (DDS record WSFL under control record WCTL, SFLPAG(5) per page, SFLSIZ(20), ROLLUP/ROLLDOWN paging). Key a work order, Enter; the header (item, ordered, completed) renders and the order's material lines load into the subfile.

B.3 Controls & audit workflow (no four-eyes maker–checker)

Honest statement: FORGE/i does not model a true four-eyes maker–checker / separate-authorization workflow, and the online screens are read-only inquiries — neither FGITEMIQ nor FGWOIQ updates a file. All state change happens in the batch cycles. The manual documents the control model the application does have:

• The inventory ledger (FGITRN). Every posted movement — material issue (I), completion receipt (R), physical-count adjustment (A), cost revalue (V) — is journaled with the item, signed quantity, extended cost, a work-order or source reference and a memo. This is the durable, reconstructable audit trail; the cycles test verifies every ledger key is unique across all four cycles.
• Cost-change history (FGCSTH). Every standard-cost change from the monthly roll-up writes a row carrying the before and after cost, so a cost movement is fully auditable and the annual run has a year-over-year reference.
• Status gating. Programs gate by object state: FGWOREL skips any WO not Planned; FGISSUE skips a line not Open; FGRECPT processes only Released/in-Work orders; FGMRPGEN plans only Active items; FGPHYS counts only active class-A items.
• Idempotency by stable ledger key. Each posting program derives its ledger key from a stable business key (WO + line, WO + receipt event, item sequence). A re-run re-derives the same key, finds the row already present, and skips — so a resubmitted cycle never double-posts. This is the integrity guard in place of a control table.
• Balanced GL & independent proof. The monthly FGGLPST posts matched debit/credit pairs (raw→WIP on issue, WIP→FG on receipt), and the COBOL FGGLRPT re-reads the ledger to prove the totals — a second, independent read of the same data.

In sum, the control posture is an accumulating ledger + cost history + status/state gating + key-based idempotency + a balanced, independently-proved GL, rather than a segregation-of-duties approval workflow.

C. Batch Jobs & the Periodic Cycle ↑ top

FORGE/i's processing runs as four periodic cycles, each a CL program that chains a fixed set of RPG/COBOL programs and ends with a completion banner. All programs take no CALL parameters and read no control table — a scheduled/JOBQ submission is a bare CALL of the cycle CL.

-- submit the (parameterless) daily cycle
SBMJOB CMD(CALL PGM(FORGE/FGDAILY)) JOB(FGDAILY)
-- or run interactively
CALL FORGE/FGWEEK

C.1 Full batch program set

The cycle CLs chain these: FGDAILY = FGWOREL → FGISSUE → FGRECPT; FGWEEK = FGMRPGEN → FGABC → FGMRPPR; FGMONTH = FGCSTRL → FGWIPVL → FGGLPST → FGGLRPT; FGYEAR = FGPHYS → FGCSTRL → FGGLRPT.

C.2 Daily / weekly / monthly / annual detail

Daily — FGDAILY

FGWOREL reads planned orders, and for each explodes one BOM level into FGWOMAT (a sub-assembly is a material line, not a second-level explosion), applying the scrap uplift reqqty = qtyper × woqty × (1 + scrappc/100); it allocates each component on FGITEM and flips the WO to released. FGISSUE then draws every open line, relieving on-hand and allocation and posting a negative-quantity issue transaction. FGRECPT receives the increment of completions since the last receipt (WOCOMP − WORCVD) into finished stock, rolling the order to C when WOCOMP + WOSCRAP ≥ WOQTY, else leaving it W.

Expected DSPLY (a 10-unit WO for FG100001, 4-line BOM, 6 then 4 received):
  FGWOREL RELEASED=1 SKIP=0     explode + allocate
  FGISSUE ISSUED=4 SKIP=0       4 material lines drawn
  FGRECPT RECEIVED=1 SKIP=0     this run's completion increment

Worked example (the daily test's oracle): a WO for 10×FG100001 explodes to housing 10.0000, shaft 10.2000 (10 × 1.02 scrap), sub-assembly 10.0000, seal 20.0000 (2 per unit). Issuing the housing takes on-hand 100→90 and allocation 10→0, and posts an I row of -10 qty / -425.00 cost (10 × 42.50).

Weekly — FGWEEK

FGMRPGEN plans every active item: WAVAIL = ONHAND − ALLOC − SAFETY, gross requirement = sum of every open (MSTAT='O') work-order material line for that component, NETREQ = max(0, GROSS − WAVAIL), suggested order = net; the message code is OR (order), or SS if on-hand less allocation is already below safety stock. FGABC re-ranks by ONHAND × STDCOST (≥2000→A, ≥500→B, else C). FGMRPPR spools the suggestion report.

Expected DSPLY (7 active items planned; ABC re-rank):
  FGMRPGEN RUN=202631 PLANNED=7 SKIP=0
  FGABC A=n B=n C=n
  FGMRPPR LINES=n               one line per suggested order

Monthly — FGMONTH

FGCSTRL rolls standard cost bottom-up in two passes — pass 1 costs sub-assemblies (ITYPE='S') from their components, pass 2 costs finished goods (ITYPE='F') from theirs (now including the freshly-costed sub-assemblies), writing an FGCSTH row (reason R) for each change. FGWIPVL values each R/W order at the standard cost of the material issued against it. FGGLPST sums the ledger by type and posts balanced pairs into FGGLFEED; FGGLRPT (COBOL) reads the ledger and prints the trial balance.

Expected cost roll-up (from the seeded BOM & raw costs):
  SA200001 = 25.0000 + 6.2500                       = 31.2500
  FG100001 = 42.5000 + 19.1250(shaft@2% scrap)
           + 31.2500(sub-assembly) + 12.5000(2 seals)= 105.3750
  FG100002 = 85.0000(2 housings) + 18.7500          = 103.7500

The GL posts 1310-RAW credit / 1320-WIP debit for issues and 1320-WIP credit / 1330-FG debit for receipts, so WIP appears on both sides and SUM(DR) = SUM(CR). Both FGCSTRL and FGGLRPT also run in the annual cycle.

Annual — FGYEAR

FGPHYS applies the run's deterministic physical-count convention — active class-A items count 2 units short (shrinkage), everything else clean — writing an A adjustment transaction (TQTY=-2) and correcting book on-hand to the counted quantity. FGCSTRL re-rolls the cost year; FGGLRPT reprints the trial balance.

Expected DSPLY:
  FGPHYS ADJUSTED=n             class-A items adjusted (-2 each)

C.3 Ordering & dependencies

• Within the daily chain the order is fixed: release (explode + allocate) before issue (draw the allocated material) before receipt. FGISSUE cannot draw lines that FGWOREL has not created.
• Daily before weekly. MRP's gross requirement comes from open (MSTAT='O') work-order material lines — those are created by FGWOREL and consumed (set to I) by FGISSUE. Run the shop-floor cycle first so demand and stock are current before regenerating MRP.
• Daily/weekly before the monthly close. WIP valuation costs issued material and the GL post sums the ledger; both must reflect the month's completed shop-floor activity. Run the month's dailies, then the close last.
• Within the monthly chain: cost roll-up before WIP valuation (WIP values at the fresh standard cost), and GL post before the trial balance (which proves what was posted).
• Annual after the final monthly close: the physical count corrects the year's book on-hand, then the cost year is re-rolled.

D. Data Files (data dictionary) ↑ top

All files are in library FORGE, grounded in the DDS/SQL in sources.mjs. Dates are stored as signed numeric in YYYYMMDD form. STDCOST is packed 11P4 (four decimals — a cost rolls through several BOM levels and rounding at 2dp per level loses cents); BOM quantities are packed 9P4.

FGITEM — Item master (key ITEMNO, UNIQUE)

FGBOM — Bill of materials (key PARENT, BSEQ, UNIQUE)

FGBOMLF is a logical file over FGBOM keyed on COMPNO — the where-used access path ("what does this part go into?"), non-unique by design (one component feeds many parents).

FGWO — Work-order header (key WONO, UNIQUE)

FGWOLF is a logical file over FGWO keyed on WOSTAT then WONO — the status access path for a posting run to read only released/in-work orders.

FGWOMAT — Work-order material lines (key WONO, MSEQ, UNIQUE)

FGITRN — Inventory transaction ledger (key TRNSEQ, UNIQUE)

The disjoint key ranges (F.3): issues 10000000+, receipts 20000000+, adjustments 40000000+, revalues 60000000+ — so keys from different programs never collide and every one is regenerable from its source event.

FGMRP — MRP planning results (key RUNNO, ITEMNO, UNIQUE)

FGCSTH — Cost-change history (key CSEQ, UNIQUE)

FGWKCTR — Work-centre master (key WCNO, UNIQUE)

FGGLFEED — GL feed (SQL table, PK GLSEQ)

Index FGGLFACC on (ACCT, DRCR) supports the by-account roll-back the post reads before continuing.

Seeded reference data (FGREFLD)

The reference load writes 7 items (2 finished, 1 sub-assembly, 4 raw), 8 BOM lines and 2 work centres:

BOM: FG100001 → RM300001×1, RM300002×1 (2% scrap), SA200001×1, RM300004×2; SA200001 → RM300003×1, RM300004×1; FG100002 → RM300001×2, RM300002×1.

Relationships

• FGBOM.PARENT and FGBOM.COMPNO → FGITEM.ITEMNO (the BOM references items both ways; FGBOMLF is the component-side access path).
• FGWO.ITEMNO → FGITEM.ITEMNO; FGWOMAT.WONO → FGWO.WONO; FGWOMAT.COMPNO → FGITEM.ITEMNO.
• FGITRN.ITEMNO → FGITEM.ITEMNO (the ledger references the item); FGITRN.TREF carries the work-order source.
• FGMRP.ITEMNO / FGCSTH.ITEMNO → FGITEM.ITEMNO.
• Access paths are DDS keys, not declared referential constraints — FORGE/i enforces integrity in RPG logic, not the catalogue.

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. First-time only: build the application — CALL FORGE/FGSETUP, then load reference data with CALL FORGE/FGREFLD.
2. Confirm the job's library list includes FORGE (LIBL = QSYS QGPL FORGE QTEMP).
3. Enter planned work orders into FGWO (WOSTAT='P').
4. Submit the daily shop-floor cycle: SBMJOB CMD(CALL PGM(FORGE/FGDAILY)).
5. Post-check the daily run (below).
6. Review inventory and orders on the read-only screens: CALL FORGE/FGMENU (option 1 item inquiry, option 2 work-order subfile).

Post-checks after the daily cycle:

• FGWOREL RELEASED= equals the planned orders you entered; each produced one FGWOMAT line per active BOM line, and the components' ALLOC rose (on-hand unchanged).
• FGISSUE ISSUED= equals the open material lines; each drew stock (on-hand and allocation both fell) and wrote one negative I ledger row.
• FGRECPT RECEIVED= equals the orders with new completions; finished on-hand rose by the increment since the last receipt, and a fully-made order rolled to WOSTAT='C'.
• The daily-complete banner appears; a re-submitted cycle leaves on-hand unchanged (idempotent).

E.2 The MRP run & month-end close

Weekly MRP run:

1. Ensure the week's daily cycles have run (open demand and stock are current).
2. Submit FGWEEK. Confirm FGMRPGEN RUN=202631 PLANNED= equals the active-item count and FGMRPPR LINES= equals the number of suggested orders.
3. Review the plan — e.g. list the shortages:

SELECT ITEMNO, GROSSRQ, NETREQ, SUGQTY, MSGCD
  FROM FORGE/FGMRP WHERE RUNNO = 202631 AND SUGQTY > 0;

Month-end close:

1. Confirm every business day's daily cycle for the month has run.
2. Submit FGMONTH. Confirm the FGCSTRL COSTED=, FGWIPVL WIP=, FGGLPST ROWS= and the COBOL FGGLRPT totals all appear, ending with the month-close banner.
3. Review and reconcile the GL feed (below).

E.3 Reconciling figures & re-run rules

Reconciling figures (the same ones the cycles simulation checks against a hand-derived oracle):

• BOM explosion — a WO for n of a parent requires, per component, QTYPER × n × (1 + SCRAPPC/100); e.g. 10×FG100001 needs shaft 10.2000.
• Cost roll-up — SA200001 = 31.2500; FG100001 = 105.3750; FG100002 = 103.7500 (F.2). Each change leaves an FGCSTH before/after row.
• Issue ledger vs GL — the GL debit total equals the absolute issue-cost total in FGITRN across all months posted; and SUM(DR) = SUM(CR):

SELECT SUM(AMT) FROM FORGE.FGGLFEED WHERE DRCR = 'D';
SELECT SUM(AMT) FROM FORGE.FGGLFEED WHERE DRCR = 'C';   -- must match, non-zero
SELECT ACCT, DRCR, SUM(AMT) FROM FORGE.FGGLFEED GROUP BY ACCT, DRCR;

F. Developer Reference ↑ top

The complete program surface, from sources.mjs. All objects are in library FORGE. RPG is written column-exact fixed-form C/D specs with /free blocks; the helpers C(...) and D(...) at the top of the source emit the exact column positions.

F.1 Programs

FGREFLD (RPGLE)

Seeds items, BOM lines and work centres by write-ing hard-coded records; DSPLYs a load summary.

FGWOREL (RPGLE)

Reads FGWO; for each planned order, explodes one BOM level into FGWOMAT with the scrap uplift, allocates each component on FGITEM, then re-CHAINs the WO and flips it to R. Skips non-planned orders.

FGISSUE (RPGLE)

Reads FGWOMAT; for each open line, checks the (WO,line) ledger key, relieves ONHAND/ALLOC (allocation floored at 0), writes a negative I ledger row, sets MSTAT=I.

FGRECPT (RPGLE)

Reads FGWO; posts the completion increment (WOCOMP−WORCVD) under a per-receipt-event key (WO×100 + slot), adds to ONHAND at standard, advances WORCVD, rolls WOSTAT to C or W.

FGMRPGEN (RPGLE)

Reads FGITEM; for each active item sums open-WO demand (nested read of FGWOMAT), nets against available, writes an FGMRP row keyed (RUNNO, ITEMNO). A KLIST of both key fields drives the idempotency CHAIN.

FGABC (RPGLE)

Reads FGITEM; sets ABCCLS from ONHAND×STDCOST value bands (≥2000 A / ≥500 B / else C).

FGCSTRL (RPGLE)

Two-pass bottom-up roll-up (S then F): for each item, sums component STDCOST×QTYPER (scrap-uplifted) one BOM level down, updates STDCOST if changed, writes an FGCSTH before/after row.

FGWIPVL (RPGLE)

Reads FGWO; for each R/W order sums ISSQTY×STDCOST over its material lines into WOCOST.

FGGLPST (SQLRPGLE)

Reads FGITRN natively, accumulates issue/receipt cost, then posts balanced DR/CR pairs into FGGLFEED via EXEC SQL INSERT, continuing GLSEQ from MAX() and posting only the movement since the last close (F.5).

FGGLRPT (COBOL)

Sequentially reads the FGITRN keyed side, totals issues/receipts by type, DISPLAYs the trial balance.

FGMRPPR (RPGLE)

Reads FGMRP; for each suggested order (SUGQTY>0) writes a detail line to the FGMRPP printer file, handling page overflow (OFLIND(*IN90)).

FGPHYS (RPGLE)

Reads FGITEM; for active class-A items writes an A variance adjustment (deterministic −2 count) under an item-sequence key and corrects ONHAND.

FGITEMIQ / FGWOIQ / FGMENU (RPGLE)

The interactive item inquiry, work-order subfile inquiry, and menu router (section B.2).

F.2 The BOM explosion & cost roll-up

Explosion (FGWOREL) walks FGBOM for the WO's parent, one level only, and for each active line computes reqqty = qtyper × woqty, then if scrappc > 0 uplifts by reqqty × scrappc / 100. A sub-assembly appears as a material line on the parent's order — the explosion is deliberately single-level; the sub-assembly's own components are planned/made through its own work order.

Roll-up (FGCSTRL) is the bottom-up complement, in two passes so a finished good picks up its sub-assembly's freshly-computed cost:

SA200001 = RM300003(25.0000)x1 + RM300004(6.2500)x1              = 31.2500
FG100001 = RM300001(42.5000)x1
         + RM300002(18.7500)x1 @2% scrap = 19.1250
         + SA200001(31.2500)x1
         + RM300004(6.2500)x2 = 12.5000                         = 105.3750
FG100002 = RM300001(42.5000)x2 = 85.0000 + RM300002(18.7500)x1  = 103.7500

The four-decimal STDCOST (11P4) is what keeps the scrap-uplifted shaft cost (19.1250) exact through the roll-up rather than losing cents at each level.

F.3 The ledger key discipline (idempotency without a control table)

FORGE/i has no LOANSVC-style control row. Instead every posting program derives its FGITRN key from a stable business key, so a re-run regenerates the same key and the CHAIN guard refuses a duplicate. The ranges are disjoint so keys from different programs never collide:

The guard idiom is CHAIN(EN) on the derived key with an error/found indicator, then skip if present. FGMRPGEN uses the same discipline in FGMRP but over a composite key (RUNNO, ITEMNO) via a KLIST — the source notes that chaining on RUNNO alone would match the first row of the run and wrongly skip every later item.

F.4 Embedded-SQL & the GL feed

SQL is confined to the GL. FGGLFEED is created by RUNSQLSTM (COMMIT(*NONE)) from the FGGLFD/FGGLFC members. FGGLPST reads the ledger with native RPG I/O but posts with embedded SQL:

• SELECT ... INTO — continue the sequence and the running per-account totals: select coalesce(max(GLSEQ),0) into :wseq from FORGE.FGGLFEED;
• INSERT in a subroutine — exec sql insert into FORGE.FGGLFEED values (:wseq, :wbatch, :wacct, :wdc, :wamt, :wref, 20260831);
• SQLCOD checked after every insert — only a successful (0) insert increments the posted-row count; a refused insert is not counted (the F.5 fix).

The postings are matched pairs: on issues, credit 1310-RAW / debit 1320-WIP; on receipts, credit 1320-WIP / debit 1330-FG — so WIP is posted on both sides and the batch balances.

F.5 Two bugs the volume simulation found

Both are documented as fixes directly in the source, and both are regression-guarded by test/forge_daily.mjs / forge_cycles.mjs:

Incremental completion reporting (FGRECPT)

WOCOMP is cumulative. The original per-WO ledger key meant the first receipt permanently blocked every later one: a shop floor reporting 4 today and 6 more tomorrow silently lost the 6 — never added to on-hand, never ledgered. The key is now per receipt event (WO×100 + receipt slot) and each posting credits only WOCOMP−WORCVD, so every increment posts exactly once. Test: 6 then 4 takes on-hand 18→22 with two ledger rows.

The GL freezing across months (FGGLPST)

The post originally restarted GLSEQ at 1 every run and re-totalled from scratch, so month 2 collided with month 1 on FGGLFEED's primary key. The inserts were correctly refused — but SQLCOD was never checked, so the job reported success while the GL silently stopped tracking the inventory ledger, permanently. The fix continues GLSEQ from MAX(), posts only the movement since the last close (net of the per-account running totals), and counts a row only when SQLCOD = 0. Test: a second month-end posts the new activity and the GL debit total still equals the issue ledger exactly.

G. Glossary ↑ top

ABC classification

Ranking items by inventory value into A (high), B, C bands so attention and count effort focus where the money is. FORGE/i re-ranks weekly (FGABC) by ONHAND×STDCOST.

Allocation

Reserving on-hand stock to a released work order without yet removing it. Held in FGITEM.ALLOC; MRP nets against it, and issue relieves it.

Available-to-promise

On-hand less allocation — the free stock. Derived on the item inquiry screen, not stored.

BOM — Bill of Materials

The parent→component structure (FGBOM) with a per-unit quantity, telling MRP and the roll-up what a part is made of. Explosion walks it downward; where-used (FGBOMLF) walks it upward.

Explosion

Expanding a parent's order into its component requirements via the BOM. FORGE/i explodes one level per work order.

Gross / net requirement

Gross = total demand for a component from open work orders; net = gross less available stock (on-hand − allocation − safety). A positive net drives a suggested order.

Idempotent

Safe to run again with the same result. In FORGE/i, achieved by deriving each ledger/plan key from a stable business key so a re-run is refused rather than double-posting.

Ledger (inventory transaction ledger, FGITRN)

The accumulating, unique-keyed audit trail of every stock movement (issue I / receipt R / adjustment A / revalue V), with signed quantity, extended cost and a source reference.

MRP — Manufacturing/Material Requirements Planning

Computing what to make or buy and when, by netting demand against supply. FORGE/i regenerates MRP weekly (FGMRPGEN) into FGMRP.

Safety stock

A buffer quantity MRP treats as unavailable, so a suggestion fires before stock actually runs out. Held in FGITEM.SAFETY; the seal kit (safety 30, on-hand 8) is FORGE/i's worked shortage.

SBMJOB

Submit Job — the IBM i command that queues a program as a batch job, e.g. SBMJOB CMD(CALL PGM(FORGE/FGDAILY)).

Scrap uplift

Increasing a component's required quantity by a scrap percentage so enough is issued to yield good units: reqqty × (1 + SCRAPPC/100).

SQLRPGLE / EXEC SQL

RPG with embedded SQL. In FORGE/i only FGGLPST uses it — native I/O over the ledger, EXEC SQL INSERT into the SQL GL feed.

Standard cost / roll-up

A fixed unit cost per item; the roll-up (FGCSTRL) recomputes each parent's cost bottom-up from its components, stored to four decimals (11P4) to survive multi-level rounding.

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). FGWOIQ's material-line list is a subfile, cleared and reloaded after each enquiry.

WIP — Work In Process

Value tied up in released, not-yet-complete orders. Valued monthly (FGWIPVL) from issued material, and the GL account (1320-WIP) posted on both issue and receipt.

Work order (WO)

An order to manufacture a quantity of an item (FGWO), moving planned → released → in-work → complete, consuming its material lines (FGWOMAT).