PROCURE/i — Purchasing & Accounts Payable

PROCURE/i is a purchase-to-pay application: a vendor master, purchase-order raising and approval, goods receipt, the classic three-way match (PO vs receipt vs invoice), invoice registration with hold/release, a weekly payment run that captures early-settlement discount, remittance advice, AP ageing, a received-not-invoiced accrual, an expense/AP GL distribution, and an annual vendor spend / 1099-style summary with accrual reversal. It is a classic mixed-language IBM i estate: fixed-form and free-form RPG for the batch posting logic, one SQLRPGLE program for the GL post, one ILE COBOL control report, DDS physical/logical/display/printer files, a SQL table, and CL drivers for setup and the four job cycles. This manual is the reference for the operator who runs the online inquiry screens and the periodic batch cycles, and for the developer maintaining the application. It is grounded entirely in the committed source (ap-app/src/sources.mjs, src/seed.mjs, and the test/ap_build.mjs, ap_daily.mjs, ap_cycles.mjs and ap_interactive.mjs drivers). Everything lives in library PROCURE.

A. Overview & Architecture ↑ top

A.1 What it does

PROCURE/i runs the purchase-to-pay cycle end to end:

• Vendor master & PO raising — vendors carry payment terms as three numbers (VDISCPC%, within VDISCDY days, else net VNETDY), so the payment run computes settlement without a terms-table lookup. Purchase orders are raised with a header (APPOH) and lines (APPOL).
• PO approval sweep — every entered order is re-totalled from its lines and approved, provided its vendor is active; orders at or under 10000.00 take the auto band, over it the manual band. An on-hold vendor's orders are left entered.
• Goods receipt — entered receipts are posted into each PO line's received quantity, capped at the ordered quantity, refused against a cancelled order.
• Three-way match — each entered invoice is checked line-by-line against the PO line it claims to bill: the PO line must exist, invoiced quantity must not exceed received quantity, and the price must equal the PO price to four decimals. A clean invoice is approved for payment; a failing one is held with a reason code and consumes nothing.
• Invoice registration — a matched invoice raises the vendor AP balance by exactly its total, stamps its discount date, and posts a positive AP ledger row.
• Payment run — open invoices due on or before the pay-through date are settled in due-date order, capturing the early-settlement discount when the run date is inside the discount window. One cheque per invoice, a remittance advice, and a negative AP ledger row.
• Month-end — AP ageing snapshot, received-not-invoiced (GRNI) accrual, an expense/AP GL distribution, and an AP control report.
• Year-end — vendor spend analysis with the 1099-style reportable flag, and reversal of the GRNI accruals so they do not carry into the new year.

A.2 The AP ledger is the spine: SUM(LAMT) IS the control balance

The application has no single “business-rules layer” the way a SQL-PL app does; the logic lives in the RPG posting programs. What ties them together is one durable file, APLEDG, that every posting program contributes to. Its design carries the two invariants the whole app is built on:

• The AP control invariant. LAMT is signed: an invoice registration adds the invoice total (positive), a payment subtracts the gross settled (negative). Therefore SUM(LAMT) across the ledger is the accounts-payable control balance. When a vendor is fully invoiced and paid, its ledger rows net to zero — the COBOL report APAPRPT exists to prove exactly this.
• The idempotency invariant. Every ledger key LSEQ is derived from a stable business key in a range disjoint per program (receipts 1000xxxx, invoices 2000xxxx, payments 3000xxxx, accruals 4000xxxx, reversals 5000xxxx). Before posting, each program does a CHAIN(EN) on the key it is about to write; if the row already exists it skips. A re-run therefore regenerates the same key and is refused rather than doubling the posting. This is what makes every cycle safely re-runnable — see F.2.

Two further invariants ride on top: the payment invariant PNET = PGROSS − PDISC on every cheque, and the “discount is income” rule — the vendor balance falls by the full gross settled, never by the net cash, because the captured discount is discount-received income, not a reduction of what was owed.

A.3 Component & flow

  REFERENCE / ONLINE            BATCH (four CL-driven cycles)
  -----------------            ----------------------------
  APREFLD  (seed data)         DAILY  APDAILY:
  APMENU (5250)                  APPOAPP  re-total + approve POs
    1 -> APVENDIQ  (vendor)      APRCPOST goods-receipt posting  --> APLEDG 'R'
    2 -> APPOIQ    (PO+subfile)  APMATCH  3-way match (hold/approve)
                                 APINVREG invoice registration   --> APLEDG 'I'  (+VBAL)
                                 APHOLDRP hold/release report
                                 APPOCLS  close fully-invoiced POs

                               WEEKLY APWEEK:
                                 APPAYRUN payment run + discount  --> APLEDG 'P'  (-VBAL)
                                 APREMIT  remittance advice (PRTF)

     APVEND  APPOH  APPOL       MONTHLY APMONTH:
       |  APRCPT APINVH APINVL    APAGERP  AP ageing snapshot    --> APAGE
       |  APPAY                   APACCR   GRNI accrual          --> APLEDG 'A'
       v                          APGLPST  expense/AP GL post    --> APGLDIST (SQL)
     APLEDG  <--- every           APAPRPT  AP control report (COBOL, reads APLEDG)
     posting program writes
       |                        ANNUAL APYEAR:
       +--> APAPRPT proves        APSPEND  vendor spend + 1099   --> APSPND
            SUM(LAMT) balances     APREVACC accrual reversal      --> APLEDG 'V'
                                   APAPRPT  AP control report

A single event — say a goods receipt — flows: an entered APRCPT row is read by APRCPOST → its quantity is added into the matching APPOL line (capped at ordered) → a receipt-valued APLEDG row is written under a stable key → the receipt flips to posted. Downstream, an invoice for those goods must pass APMATCH before it can ever reach APPAYRUN.

A.4 Object inventory

The catalogue is 12 PF/LF files, 1 SQL table + 1 index, 3 DSPF, 1 PRTF, 17 RPG programs (one of them SQLRPGLE), 1 ILE COBOL program and 5 CL programs. Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

PROCURE/i has no CICS transaction identifiers. On IBM i each program is reached by name from a 5250 command-entry line (interactive programs) or from a JOBQ / scheduler (batch). Before invoking anything the job's library list must include PROCURE — the tested jobs run with LIBL = QSYS QGPL PROCURE QTEMP and CURLIB = PROCURE. Object creation is done once by the setup CL, which itself does ADDLIBLE LIB(PROCURE).

The batch cycles take no CALL parameters: each is a CL program that simply calls its posting programs in order, so a scheduled submission is a bare CALL of the cycle. The three interactive programs are inquiry-only (see B.2); all posting happens in batch.

B.2 The menu & the two inquiry screens

APMENU — the operator menu (APMENUD)

APMENU presents a two-option menu and routes by program-to-program CALL: option 1 calls APVENDIQ, option 2 calls APPOIQ; any other non-blank option shows Invalid option. on the menu itself. F3 ends the program; each inquiry's F3 returns to the menu.

APVENDIQ — vendor inquiry (APVENDD, plain screen)

A non-subfile screen: key a vendor number, press Enter, and it CHAINs APVEND and renders the master record plus the derived terms. A miss clears the detail fields and shows Vendor not found. rather than leaving stale values on screen. The AP balance shown is the live VBAL the daily cycle posted — not a re-derivation.

APPOIQ — purchase-order inquiry (APPOD, subfile screen)

The app's subfile screen. Key a PO number; the header (APPOH) renders vendor, re-derived order total and status, and a subfile (DDS record PSFL under control PCTL, SFLPAG(5) / SFLSIZ(20), ROLLUP/ROLLDOWN) loads the order's lines showing ordered / received / invoiced quantities and line status. Enquiring a second PO clears and reloads the subfile, so the row count tracks the new order (a one-line PO shows one row); an unknown PO shows Purchase order not found. with an empty subfile.

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

Honest statement: PROCURE/i does not model a true four-eyes maker–checker / separate-authorization workflow. The PO approval sweep APPOAPP approves automatically for any active vendor; the manual band POAPLM='M' that an over-10000.00 order receives is a label recording that it exceeded the auto limit, not a hold-for-a-second-approver gate — the order is approved in the same pass. The screens are inquiry-only and post nothing. The manual documents the control model the application does have, and it is a strong one, enforced in the posting programs:

• The three-way match is the real control gate. APMATCH is what stops bad money going out: an invoice that over-bills a receipt (Q), varies on price (P), or names a non-existent PO line (N) is set ISTAT='H' and consumes no PO quantity. Only a clean invoice reaches ISTAT='O', and only an 'O' invoice is ever picked up by the payment run — a held invoice is verifiably never paid.
• Two-pass matching. APMATCH tests every invoice line first, consuming nothing; only if the whole invoice passes does a second pass consume the PO quantities. A partial failure cannot half-consume an order.
• Receipt bounding & cancelled-order refusal. APRCPOST caps a delivery at the ordered quantity (a supplier over-delivery is trimmed, not absorbed) and refuses a delivery against a PO already at POSTAT='X', leaving the line untouched and the receipt un-posted.
• The AP ledger audit trail (APLEDG). Every posting — receipt, invoice, payment, accrual, reversal — writes a signed, keyed, memo'd ledger row. The ledger is a complete, reconstructable history, and SUM(LAMT) across it is the AP control balance the COBOL report re-proves.
• Idempotency guards. Every posting program refuses to post a second time for the same business key (F.2), so a re-run of any cycle cannot double a balance, cut a second cheque, or double an accrual.

In sum, the control posture is match-gating + receipt-bounding + a signed audit ledger + hard idempotency, all enforced in the posting programs, rather than a segregation-of-duties approval workflow.

C. Batch Jobs & the Periodic Cycle ↑ top

PROCURE/i runs as four CL-driven cycles: a daily purchase-to-pay cycle, a weekly payment cycle, a monthly close and an annual roll. Each CL simply ADDLIBLEs PROCURE and calls its posting programs in a fixed order, then sends a completion message. No cycle takes parameters (see the B.1 note on how dates are set).

-- one-time build, then load reference data
CALL PROCURE/APSETUP
CALL PROCURE/APREFLD

-- then submit a (parameterless) cycle
SBMJOB CMD(CALL PGM(PROCURE/APDAILY)) JOB(APDAILY)

C.1 Full batch program set

C.2 Daily / weekly / monthly / annual detail

Daily — APDAILY (APPOAPP → APRCPOST → APMATCH → APINVREG → APHOLDRP → APPOCLS)

The purchase-to-pay chain. Approve orders, post receipts, match invoices, register the clean ones, report the held ones, close finished orders. Worked against the seeded reference data plus the receipts and invoices the tests plant, the expected results are hand-derivable:

Expected DSPLY (reference data + the day's receipts/invoices):
  APPOAPP APPROVED=3 SKIP=1     3 active-vendor POs; V00004 on hold -> skipped
  APRCPOST POSTED=4 SKIP=0      four receipts posted to the right (PO,line)
  APMATCH MATCHED=1 HELD=3      1 clean (O); 3 held Q/P/N
  APINVREG REGISTERED=1         only the matched invoice registers; VBAL +2250.00
  APHOLDRP HELD=3 ... AMT=20137.50
  APPOCLS CLOSED=0              PO000001 line 3 never invoiced -> stays open

Weekly — APWEEK (APPAYRUN → APREMIT)

APPAYRUN walks the due-date logical APINVLF and settles every 'O' invoice due on or before the pay-through date. If the run date is on or before the invoice discount date it captures VDISCPC% of the total, else it pays gross. One APPAY cheque per invoice with PNET = PGROSS − PDISC; the vendor balance falls by the full gross.

Expected DSPLY (2 open invoices; 1 held is skipped):
  APPAYRUN PAID=2 GROSS=3450.00 DISC=24.00
                               1200.00 paid inside 2/10 window -> 24.00 discount, 1176.00 cash
                               2250.00 past its window -> gross, 0.00 discount
  APREMIT LINES=2 CASH=3426.00 total net cash = 1176.00 + 2250.00

Monthly — APMONTH (APAGERP → APACCR → APGLPST → APAPRPT)

Age the unpaid invoices, accrue received-not-invoiced goods, post the GL distribution, and prove the control balance. Ageing buckets by whole days past due using exact civil-days arithmetic (F.3); the GRNI accrual is (RCVQTY−INVQTY)×POPRICE per PO line; the GL post writes balanced DR/CR pairs and posts only the movement since the last close.

Expected DSPLY / GL (as of 20260831, period 202608):
  APAGERP RUN=202608 VENDORS=4     the one open (held) 600.00 invoice ages to the 1-30 bucket
  APACCR  ACCRUED=2 AMT=18360.00   360.00 (120x3) + 18000.00 (1x18000)
  APGLPST PER=202608 ROWS=...      5100-EXP DR 21810.00; 1010-CSH CR 3426.00; 4900-DSC CR 24.00; 2100-AP both sides 3450.00
  APAPRPT CONTROL ...              COBOL re-proves SUM(LAMT)

Annual — APYEAR (APSPEND → APREVACC → APAPRPT)

Summarise each vendor's year from the ledger (gross invoiced, discount taken, net cash, invoice count, 1099 flag), then reverse the GRNI accruals so they do not double-count into the new year.

Expected DSPLY (year 2026):
  APSPEND YEAR=2026 VENDORS=4 R1099=1  V00001 gross 3450.00 / disc 24.00 / net 3426.00; V00003 flagged
  APREVACC REVERSED=2 AMT=18360.00     two 'V' rows totalling -18360.00; accrual nets to 0

C.3 Ordering & dependencies

• Within the daily cycle the order is fixed and load-bearing: approve → post receipts → match → register → (report) → close. Registration must not run before the match (only 'O' invoices register), and the match relies on receipts already posted (it tests invoiced-plus-new against RCVQTY).
• DAILY before WEEKLY. Only registration raises the vendor balance and sets an invoice 'O'; the payment run pays only 'O' invoices, so the day's registration must precede the week's payment run.
• DAILY/WEEKLY before MONTHLY. Ageing and the GRNI accrual must see the fully matched, registered and paid state; the GL post reads the ledger those cycles wrote.
• MONTHLY before ANNUAL. The accrual reversal reverses the 'A' rows the monthly accrual wrote; the spend analysis reads the whole year's ledger. Run the annual roll last.
• Every cycle is safely re-runnable in place (F.2) — re-running never doubles a posting. The weekly payment run's guard is the single most important one: an invoice is never paid twice.

D. Data Files (data dictionary) ↑ top

All files are in library PROCURE, grounded in src/sources.mjs. Dates are stored as signed 8S0 integers in YYYYMMDD form (or YYYYMM / YYYY for periods); money is packed decimal; unit prices are 11P4 (four decimals); the discount percent is 5P2.

APVEND — Vendor master (key VENDNO)

Seeded: V00001 ACME 2/10 N30; V00002 BOREAL net 30 (no discount); V00003 CALDER 1/15 N45 (1099); V00004 DELTA net 60 (on hold).

APPOH — Purchase-order header (key PONO)

APPOL — Purchase-order lines (composite key PONO, POLINE)

APPOLLF is a non-unique logical over these lines keyed by ITEMNO then PONO — “which orders is this part on?” as a keyed read rather than a scan.

APRCPT — Goods receipts (key RCPTNO)

APINVH — Invoice header (key INVNO)

APINVLF is a logical over the invoices keyed by DUEDT then INVNO, record format APINVDR (renamed so the payment run can open both this LF for the due-date read and the base APINVH for the keyed write-back).

APINVL — Invoice lines (composite key INVNO, ILINE)

APPAY — Payment header (key PAYNO)

APLEDG — AP ledger (key LSEQ) — the audit spine

APAGE — AP ageing snapshot (composite key AGRUN, VENDNO)

APSPND — Vendor spend analysis (composite key SPYR, VENDNO)

APGLDIST — Expense/AP GL distribution (SQL table, PK GLSEQ)

Index APGLDACC is over (ACCT, DRCR).

Relationships

• APPOH.VENDNO → APVEND.VENDNO; APPOL.PONO → APPOH.PONO (composite line key PONO+POLINE).
• APRCPT.(PONO,RLINE) → APPOL.(PONO,POLINE); APINVL.IPOLINE → the PO line the invoice bills.
• APINVH.VENDNO/PONO → APVEND/APPOH; APPAY.PAYNO derived from the invoice number.
• APLEDG.VENDNO references the vendor; keys are business-derived (no per-row FK) — SUM(LAMT) is the control total.
• APAGE/APSPND are period-keyed aggregate logs; APGLDIST is fed by the ledger.

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. First time only: CALL PROCURE/APSETUP (build objects & compile), then CALL PROCURE/APREFLD (load reference vendors/POs/lines). Confirm the setup-complete banner and APREFLD VENDORS=4 POS=4 POLINES=7.
2. Enter the day's goods receipts into APRCPT (RSTAT='E') and invoices into APINVH/APINVL (ISTAT='E'), by whatever data-entry path your site uses.
3. Submit the daily cycle: SBMJOB CMD(CALL PGM(PROCURE/APDAILY)).
4. Post-check the daily run (below).
5. On a payment day, submit APWEEK; check PAID=/GROSS=/DISC= and the remittance CASH=, and confirm the spooled advice.
6. Answer vendor/PO questions interactively with CALL PROCURE/APMENU (inquiry-only).

Pre-checks: confirm the job's library list includes PROCURE; confirm the entered receipts/invoices carry 'E' status so the posting programs pick them up.

Post-checks after the daily cycle:

• APPOAPP approved only active-vendor orders; an on-hold vendor's orders stay 'E'.
• APRCPOST POSTED= equals the entered receipts; CAPPED= flags any over-delivery that was trimmed; a cancelled-PO delivery shows as skipped and un-posted.
• APMATCH MATCHED=/HELD= reconcile; each held invoice shows the right IHOLDCD (Q/P/N) and consumed no PO quantity.
• APINVREG: each registered invoice raised its vendor's VBAL by exactly the invoice total; held invoices did not move any balance. One positive ledger row per invoice.
• The ledger did not grow on a re-run and every LSEQ is unique.

E.2 Period close

1. Weekly: run every due payment run so open invoices are settled before the month is aged and posted.
2. Month-end: submit APMONTH. Confirm APAGERP wrote one row per vendor, APACCR accrued the received-not-invoiced lines, and APGLPST posted balanced DR/CR rows for the period.
3. Year-end: submit APYEAR. Confirm the spend analysis and that every accrual was reversed (the accrual class nets to zero).
4. Review and reconcile (below).

Reconciling figures (the same ones the volume/battle suites check against hand-derived oracles):

• AP control balance — SUM(LAMT) over APLEDG equals the sum of open vendor VBALs. A fully invoiced-and-paid vendor nets to 0.00 (invoices +3450.00, payments −3450.00). APAPRPT re-proves this and prints INVOICED / PAID / DISCOUNT / CONTROL / ROWS.
• Payment invariant — every APPAY row satisfies PNET = PGROSS − PDISC; total cash sent = SUM(PNET).
• Discount is income — the vendor balance fell by the full gross, and the captured discount appears as a 4900-DSC credit in the GL, not as a smaller balance relief.
• GL balances — in APGLDIST, SUM(AMT) WHERE DRCR='D' equals SUM(AMT) WHERE DRCR='C'; expense (5100-EXP) = invoices + accrual; cash (1010-CSH) = net cash; AP (2100-AP) is posted on both sides for the gross.
• Ageing — each unpaid invoice lands in the bucket matching whole days past due at the as-of date; a fully paid vendor ages to 0.00.
• Accrual reversal — the 'V' rows equal and oppose the 'A' rows, so SUM(LAMT) WHERE LTYPE IN ('A','V') is 0.00.

-- reconcile the AP control balance and the GL balance
STRSQL
  SELECT LTYPE, SUM(LAMT) FROM PROCURE.APLEDG GROUP BY LTYPE;
  SELECT DRCR, SUM(AMT)  FROM PROCURE.APGLDIST GROUP BY DRCR;

E.3 Failure & re-run rules

Each program DSPLYs a result line naming its counts (F.5). The overriding rule is that every posting program is idempotent by a stable ledger/status key, so a partial or repeated run is safe.

F. Developer Reference ↑ top

The program surface, from ap-app/src/sources.mjs. RPG programs are built column-exact fixed-form C/D specs interleaved with /free blocks (the same helper convention as ibmi/samples.js). All objects are in library PROCURE.

F.1 Program surface

APREFLD — reference seeder (RPG)

Writes 4 vendors, 4 POs and 7 PO lines with hand-computable extended values, so every downstream oracle is derivable from this one program. POs seed with POTOT=0; the approval sweep re-derives the total.

APPOAPP — PO approval sweep (RPG, daily)

For each POSTAT='E' order: CHAINs the vendor (skip unless VSTAT='A'), re-derives POTOT from the lines (Σ POQTY×POPRICE, excluding cancelled lines), sets band A/M at the 10000.00 threshold, flips to 'A'. Idempotent by status.

APRCPOST — goods-receipt posting (RPG, daily)

Composite KLIST CHAIN on (PONO,RLINE). Caps the delivery at the ordered quantity, refuses a delivery against a cancelled PO, adds into RCVQTY, flips the line to R when fully received, writes a ledger 'R' row, flips the receipt to P. Idempotent by key 10000000+receipt digits.

APMATCH — three-way match (RPG, daily)

Two passes: pass 1 tests every invoice line (PO line exists? qty within receipt? price = PO price?), consuming nothing; a failure sets the hold code (N/Q/P), holds the invoice and returns. Only a clean invoice runs pass 2, consuming INVQTY and approving to 'O'. Idempotent (only 'E' considered).

APINVREG — invoice registration (RPG, daily)

For each 'O' invoice not yet on the ledger: raises VBAL/VYTD by the total, computes the discount date by exact civil-days arithmetic (F.3), writes a positive ledger 'I' row, stamps DISCDT. Idempotent by key 20000000+invoice.

APHOLDRP — hold/release report (RPG, daily)

Counts held invoices split by hold code and totals their value. Read-only report.

APPOCLS — PO close (RPG, daily)

Closes an A/R order whose every line is 'I'; leaves it if any line is still open. Idempotent by status.

APPAYRUN — payment run (RPG, weekly)

Walks APINVLF in due-date order; pays each 'O' invoice due by the pay-through date. Captures VDISCPC% if the run date is on or before the discount date. Writes one APPAY cheque (PNET=PGROSS−PDISC), relieves VBAL by the full gross, writes a negative ledger 'P' row. Idempotent by key 30000000+invoice.

APREMIT — remittance advice (RPG, weekly)

Prints one vendor block per payment to the APREMP PRTF with page overflow (OFLIND(*IN90)) and a cash total. Printer fields are R-prefixed to avoid a namespace collision with the APPAY record format.

APAGERP — AP ageing (RPG, monthly)

Buckets every unpaid (O/H) invoice by whole days past due at the as-of date (exact civil-days) into current/1-30/31-60/61+. One row per vendor. Idempotent by composite (AGRUN,VENDNO). Named APAGERP so it does not collide with the APAGE file.

APACCR — GRNI accrual (RPG, monthly)

For each PO line with RCVQTY>INVQTY: accrues the difference at PO price as a ledger 'A' row. Idempotent by key 40000000+PO digits×10+line.

APGLPST — expense/AP GL post (SQLRPGLE, monthly)

Accumulates the ledger by class, then posts only the movement since the last close (reads back what each group already contributed) as balanced DR/CR rows into APGLDIST. Continues GLSEQ; counts only SQLCOD=0 inserts.

APSPEND — vendor spend + 1099 (RPG, annual)

Per vendor from the ledger: gross invoiced + count ('I'), discount + net cash ('P'), and the carried 1099 flag. One row per (year,vendor). Idempotent by composite key.

APREVACC — accrual reversal (RPG, annual)

Reverses each 'A' row with an equal-and-opposite 'V' row at key (accrual key + 10000000). Collects the accruals in one pass and writes only into the disjoint 50000000+ range so the new rows are not read back. Idempotent by that key.

APVENDIQ / APPOIQ / APMENU — interactive (RPG)

Vendor CHAIN inquiry; PO header + line subfile (clear/reload discipline); menu with option routing by program CALL. Inquiry-only.

APAPRPT — AP control report (ILE COBOL)

Sequentially reads APLEDG, accumulating INVOICED, PAID, DISCOUNT and the CONTROL total (SUM(LG-AMT)), and DISPLAYs them — the independent proof that the ledger balances.

F.2 The ledger-key idempotency scheme

Every posting program derives its LSEQ from a stable business key in a disjoint range, and guards each post with a CHAIN(EN) that skips when the row already exists. This is what makes each cycle re-runnable in place.

The composite-key report files (APAGE, APSPND) use the same idea with a KLIST guard on their period+vendor key instead of a synthetic LSEQ.

F.3 Date arithmetic

The engine's %DATE builtin works on ISO text, not on an 8S0 YYYYMMDD number, so PROCURE/i does its own exact civil-days conversion (Howard Hinnant days_from_civil / civil_from_days) in DSER (date→serial) and DADD (serial→date) subroutines. This matters in two places: APINVREG adds the discount days to the invoice date to compute DISCDT (a plain integer add of 10 to 20260825 would produce the non-existent 20260835, corrupting the payment run's discount test), and APAGERP measures whole days past due. Both are exact for every Gregorian date with no 30-day-month approximation.

F.4 DDS & engine accommodations

• Subfile conditioning columns (APPOD). The DDS parser reads the three condition slots from a specific 0-based offset and takes the N-flag from the first byte. The indicators (N31 SFLDSP/SFLDSPCTL, 31 SFLCLR, 90 SFLEND) are laid out at the exact offset so they parse as 31/90, not a truncated 3/9. Written one column further right, SFLCLR would never fire and the subfile would silently keep the previous enquiry's rows — a bug that only shows on a second enquiry, which is why ap_build.mjs pins the parsed conditions at build time.
• APINVLF record-format rename (APINVDR). The payment run opens the due-date logical for the READ and the base APINVH for the keyed write-back; two files in one program may not share a record-format name, so the LF's format is renamed.
• APREMP R-prefixed fields. The printer file shares the program's field namespace with the APPAY record format, which already owns PGROSS/PDISC/PNET/PCNT; the PRTF fields are R-prefixed to avoid a compile-time collision.
• Re-CHAIN after cross-file reads. Several posting programs read a second/third file inside a subroutine, which moves the cursor; they re-CHAIN the record they were on before updating it (e.g. APPOAPP re-CHAINs the header after walking the lines and vendor).

F.5 DSPLY result-line table

G. Glossary ↑ top

Approval band (POAPLM)

The label recording how a PO was approved: A auto (at or under 10000.00), M manual band (over it). It is descriptive — PROCURE/i approves both in one sweep; there is no second-approver hold.

AP control balance

SUM(LAMT) over the AP ledger — the running accounts-payable liability. Invoices add, payments subtract; the COBOL report APAPRPT re-proves it.

Discount is income

An early-settlement discount reduces the cash sent, not the obligation: the vendor balance falls by the full gross and the captured discount posts as discount-received (4900-DSC) income.

GRNI accrual (received-not-invoiced)

Goods received but not yet billed: (RCVQTY−INVQTY)×POPRICE per PO line, accrued at month-end (APACCR) and reversed at year-end (APREVACC).

Hold code (IHOLDCD)

Why the three-way match rejected an invoice: Q quantity over receipt, P price variance, N no matching PO line. A held invoice consumes nothing and is never paid.

Idempotent

Safe to run again with the same result. Every PROCURE/i posting program is idempotent by a stable ledger/status key, so re-running a cycle never doubles a posting (F.2).

Ledger (APLEDG)

The durable, signed, keyed audit trail every posting program contributes to; the app's spine and the source of the control balance.

Payment invariant

PNET = PGROSS − PDISC on every cheque — the discount is exactly the gap between gross owed and net cash.

SBMJOB

Submit Job — queues a program to run as a batch job, e.g. SBMJOB CMD(CALL PGM(PROCURE/APDAILY)).

SQLRPGLE / EXEC SQL

RPG with embedded SQL. Only APGLPST uses it here, to read/write the APGLDIST GL table; the rest of the app is native record-level I/O.

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). APPOIQ's order-line list is a subfile; it is cleared and reloaded on each enquiry.

Terms (2/10 net 30)

Payment terms carried as three vendor numbers — discount percent (VDISCPC), discount days (VDISCDY), net days (VNETDY) — so the payment run computes settlement without a terms-table lookup.

Three-way match

Reconciling a supplier invoice against the purchase order and the goods receipt (quantity within receipt, price equal to PO price, PO line exists) before it is approved for payment (APMATCH). PROCURE/i's real payment-control gate.