BAZAAR/i — Retail Point of Sale & Merchandise Inventory

BAZAAR/i is a multi-store specialty-retail application: a store and SKU master with a store-level price book, POS basket capture with mixed tender and returns/refunds, nightly stock depletion and sales/tax GL distribution, per-till cash-up and variance reporting, weekly store replenishment and slow/fast-mover ranking, monthly markdown management and department margin analysis, and an annual stocktake, price-book roll and sales archive. It is a classic IBM i mixed-language estate: RPG (fixed-form and free-form) for the batch and online programs, one SQLRPGLE program for the GL distribution, ILE COBOL for the till audit report, DDS for the physical/logical/display/printer files, and CL for the setup and the four job cycles. This manual is the reference for the operator who runs the online screens and the periodic cycles, and for the developer maintaining the application. It is grounded entirely in the committed source (retail-app/src/sources.mjs, src/seed.mjs, and the test/rt_*.mjs drivers).

A. Overview & Architecture ↑ top

A.1 What it does

BAZAAR/i runs the merchandising and till life of a small chain across trading days, weeks, months and the trading year:

• Lane pricing — take the raw quantity/SKU lines the lane captured and re-price each off the store price book (shelf price less any promotion), total each basket, and add the store's own sales tax.
• Stock depletion & GL distribution — deplete store stock line by line for every captured basket, cash up each till against its tender ledger, and distribute the day's sales, tax and cost of sale into a balanced GL.
• Replenishment — weekly, suggest an order for every store/SKU that has fallen to its reorder point, rank each line slow/medium/fast on the week's units, and raise the suggestions onto the store on-order book.
• Markdown & margin — monthly, burn a permanent markdown into the price book for discontinued and slow lines, then summarise sales, cost and margin by store and department and grade each against its target.
• Annual close — variance the counted stocktake against the book and correct it, roll the price book into the new trading year, and archive the year's posted sales with a stock re-valuation.

A.2 Mixed-language architecture: DDS data, RPG/COBOL logic, CL orchestration

Everything runs in library BAZAAR. The application is a conventional IBM i layering, not a two-layer SQL-PL design:

• DDS data layer. 13 physical files hold the master, transaction and log data; 3 logical files provide genuine alternate access paths (SKU-first stock, SKU-first sale lines, store+date sale headers); 3 display files and 1 printer file drive the operator screens and the till report; one table (RTGLDIST) plus an index is created through SQL DDL (RUNSQLSTM) for the GL distribution.
• Program layer. The business rules live in RPG programs (mostly fixed-form C-specs with /free blocks) — pricing, depletion, cash-up, replenishment, markdown, margin, stocktake, roll and archive. One program, RTGLPST, is SQLRPGLE and writes the GL rows with embedded EXEC SQL. One program, RTTLRPT, is ILE COBOL and independently re-proves the till invariant.
• CL orchestration layer. RTSETUP creates every object and compiles every program; the four cycle drivers (RTDAILY, RTWEEK, RTMONTH, RTYEAR) simply CALL the programs in the right order and send a completion message.

The benefit for operations: each cycle is a single CL you submit; each program is a small, single-purpose step that DSPLYs a one-line result you can read back; and the data model's composite (STORE, SKU) keys mean every figure is genuinely per-store — the same SKU can carry a different price, a different promotion and a different book at each store.

A.3 Component & flow

  ONLINE                 DAILY                 WEEKLY / MONTHLY / ANNUAL
  ------                 -----                 -------------------------
  RTMENU (5250)          RTDAILY:              RTWEEK:
    opt 1 -> RTSKUIQ       RTPOSCP  (price)      RTREPLG (suggest+rank)
    opt 2 -> RTTXNIQ       RTPOSPT  (deplete)    RTONORD (raise on-order)
             (subfile)     RTTILLR  (cash-up)  RTMONTH:
                           RTTILPR  (print)      RTMKDNA (markdown)
                           RTGLPST  (GL, SQL)    RTDSUMA (dept margin)
                           RTTLRPT  (COBOL)    RTYEAR:
                                                 RTSTKTA (stocktake var)
                                                 RTPBRLL (price-book roll)
                                                 RTARCH  (archive+revalue)

  MASTER / TXN FILES (library BAZAAR)
    RTSTORE RTDEPT RTSKU RTPRICE RTSTOCK   <-- reference (RTREFLD seeds)
    RTSALE (hdr) RTSLIN (lines) RTTEND (tender)  <-- POS basket
    RTTILL RTGLDIST RTREPL RTMKDN RTSTKTK RTDSUM <-- cycle outputs
    LFs: RTSTKLF (SKU,STORE)  RTSLLF (SKU,TXNO)  RTSALF (STORE,DATE,TXNO)

A single trading day flows: the lane writes captured baskets (TXSTAT='C') into RTSALE/RTSLIN/RTTEND → RTDAILY prices them (RTPOSCP), posts them and depletes stock (RTPOSPT, flipping C→P), cashes up the tills (RTTILLR), prints the reconciliation (RTTILPR) and distributes the money to the GL (RTGLPST), and the COBOL audit (RTTLRPT) re-proves the till invariant.

A.4 Object inventory

The full catalogue is 13 PFs + 3 LFs + 3 DSPFs + 1 PRTF + 1 SQL table (with index), driven by 17 RPG programs, 1 ILE COBOL program and 5 CL programs (setup + four cycles). Sections D and F expand each.

B. Online Transactions & Screens ↑ top

B.1 The command/entry line

BAZAAR/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 BAZAAR — the tested jobs run with LIBL = QSYS QGPL BAZAAR QTEMP and CURLIB = BAZAAR. (The cycle CLs also issue their own ADDLIBLE LIB(BAZAAR) defensively.)

The batch cycles take no CALL parameters. Rather than a control table, each individual program derives its own scope from the data or from a compile-time period literal (see the honest note in C.2): the GL post finds the earliest undistributed trading day; the weekly run stamps run number 202632; the monthly summary uses period 202608; the annual roll targets effective date 20270101. Only RTMENU, RTSKUIQ and RTTXNIQ are interactive; every batch program runs to completion and DSPLYs a one-line result.

B.2 The menu & inquiry screens (RTMENU / RTSKUIQ / RTTXNIQ)

Three programs are interactive, driven by three DDS display files:

Main menu — RTMENU / RTMENUD

A plain menu with two options; it CALLs the chosen inquiry program-to-program and returns. MOPT='1' calls RTSKUIQ, MOPT='2' calls RTTXNIQ, any other non-blank value shows Invalid option. F3 (CA03) ends the program.

SKU price / stock inquiry — RTSKUIQ / RTSKUD

A plain (non-subfile) screen. Key a store and a SKU, Enter, and it renders the SKU description and department (from RTSKU), the shelf price and promotion (from the RTPRICE row keyed on both STORE and SKU) and the store stock (from RTSTOCK). Two figures are derived on the screen and stored nowhere: the promotional price (price − half-up(price × promopc / 100)) and the available quantity (onhand − resvqty). A SKU not found, or a real SKU the store does not carry, shows SKU not found at that store. and clears the detail.

The same SKU keyed for ST02 renders the same 12.99 shelf but a 0.00 promotion (so the promo price is the shelf price) and the ST02 book of 30 — proving the screen reads the (STORE, SKU) composite key, not the SKU alone.

Transaction inquiry — RTTXNIQ / RTTXND (subfile)

RTTXNIQ is the app's subfile screen. Key a transaction number, Enter, and it renders the basket header (store, type, net, total from RTSALE) and loads the basket's sale lines into a subfile (DDS record TSFL under control record TCTL, SFLPAG(5) per page, SFLSIZ(20), ROLLUP/ROLLDOWN paging). Each subfile row shows sequence, SKU, quantity, price, discount and net.

B.3 Controls & audit model (no maker–checker; controls are variance + guards)

Honest statement: BAZAAR/i does not model a four-eyes maker–checker / separate-authorization workflow, and it has no user-level audit trail table. There is no "one clerk captures, a supervisor approves" gate, and no *AUDIT-style log of who did what. The control posture the application does have is built into the batch logic:

• Cash variance is reported, never absorbed. The cash-up (RTTILLR) accumulates the expected tender by type off RTTEND, compares declared cash to expected, writes the difference to VARCASH, and sets TLSTAT='V' when it is non-zero — the till is visibly out of balance rather than quietly balanced. The declared over/short is never rolled into TLSALES or EXPCASH.
• The till invariant is asserted and independently re-proved. The cash-up enforces EXPCASH + EXPCARD + EXPVOUC = TLSALES (the tender ledger must foot to the day's posted totals); the ILE COBOL RTTLRPT re-reads RTTILL and re-proves it, counting any out-of-balance till rather than hiding it.
• The GL foots. The distribution (RTGLPST) writes balanced DR/CR pairs (cash vs revenue+tax, and cost-of-sale vs merchandise stock) so the whole batch's debits equal its credits.
• Oversell floors at zero and is counted. Depletion (RTPOSPT) will not drive a book quantity negative: a sale larger than on-hand floors the book at zero and accumulates the shortfall (WOVERS) so the day reports the oversell rather than carrying a silent negative.
• Status & key gating. Every step keys off a stable status/business key so it processes a row exactly once: baskets flip C→P then P→A; cash-up, replenishment, markdown, summary, stocktake, roll and archive each have an idempotency guard (section F.3) that refuses to process an already-processed row.

In sum, the control model is variance reporting + balancing invariants + idempotency guards, enforced in the batch programs, rather than a segregation-of-duties approval workflow or a user-audit trail.

C. Batch Jobs & the Periodic Cycle ↑ top

BAZAAR/i's processing runs as four periodic cycles, each a CL that CALLs its programs in a fixed order: a daily cycle (price, deplete, cash-up, print, GL, audit), a weekly cycle (replenishment + raise on-order), a monthly cycle (markdown + department margin) and an annual cycle (stocktake, price-book roll, archive). All four take no CALL parameters. This is the SBMJOB idiom — a scheduled submission is a bare CALL:

-- one-time build, then seed the reference data
CALL PGM(BAZAAR/RTSETUP)
CALL PGM(BAZAAR/RTREFLD)

-- then submit a (parameterless) cycle
SBMJOB CMD(CALL PGM(BAZAAR/RTDAILY)) JOB(RTDAILY)

C.1 Full batch program set

RTREFLD (seed) and RTSKUXR (chain-wide SKU cross-reference demo) are on-demand utilities, not part of any cycle.

C.2 Daily / weekly / monthly / annual detail

Daily — RTDAILY

Runs RTPOSCP→RTPOSPT→RTTILLR→RTTILPR→RTGLPST→RTTLRPT. Pricing is per line: gross = qty × price, disc = half-up(gross × promopc / 100), net = gross − disc; the header sums the line nets, then tax = half-up(net × store taxpc / 100) and total = net + tax. A return carries negative quantities, so every figure comes out negative through the same arithmetic — no separate refund path.

Expected DSPLY (rt_daily oracle: ST01 tax 8.25%, three baskets):
  RTPOSCP PRICED=3 SKIP=0
  RTPOSPT POSTED=3 LINES=4 SKIP=0    stock 50-3+1=48, 8-1=7, 100-2=98
  RTTILLR TILLS=1 SKIP=0 VAR=200     200.00 float left in drawer, TLSTAT='V'
  RTGLPST BATCH=20260801 ROWS=5      DR cash 54.38 = CR sale 50.23 + tax 4.15; COS pair 30.50

Weekly — RTWEEK

Runs RTREPLG then RTONORD, under run number 202632. For each active store/SKU: available = onhand − resvqty; when available ≤ REORDP, suggest REORDQ − available − onorder floored at zero, and set the message OR (order) or OS (out of stock, when available ≤ 0). The mover rank off the week's posted units is F (≥10), M (≥3) else S. Discontinued SKUs are skipped. RTONORD then adds each suggestion to ONORDER and flips RPMSG to RD (raised).

Expected DSPLY (rt_cycles oracle: 9 stock rows, 1 discontinued):
  RTREPLG RUN=202632 SUGGESTED=3 SKIP=1  8 planned, 3 need ordering (53, 9, 84 units)
  RTONORD RAISED=3 SKIP=...              ST01 plates on-order 53, ST02 coffee 84

Monthly — RTMONTH

Runs RTMKDNA then RTDSUMA, over period 202608. Markdown ladder: discontinued SKUs take 30%, class-C slow lines take 15%, everything else nothing; new = half-up(old × (100 − pc) / 100), logged with a before image and burned into the price book. The department summary accumulates posted sale lines by (store, dept): margin = sales − cost, margin% = half-up(margin × 100 / sales) (zero sales → 0), graded P when margin% ≥ the department target else F.

Expected DSPLY (rt_cycles oracle):
  RTMKDNA MARKED=1 SKIP=...    sea salt 4.40 -> half-up(3.08) = 3.08, reason 'D'
  RTDSUMA PER=202608 ROWS=6    2 stores x 3 depts; ST02/APP 49.96% misses 50% -> F

Annual — RTYEAR

Runs RTSTKTA→RTPBRLL→RTARCH. Stocktake varies the counted quantity against the book (CTVAR = count − book), records it and corrects the book to the count. The roll moves every price row to effective 20270101, clears PROMOPC/PRMKDN, and closes (PRSTAT='X') the price rows of discontinued SKUs. The archive flips posted baskets to TXSTAT='A' and re-values each stock row at SKU cost (SKVAL = onhand × cost).

Expected DSPLY (rt_cycles oracle: counts seeded short/over):
  RTSTKTA COUNTED=2 SKIP=0 VAR=-2   ST01 45 vs 48 = -3 (shrinkage); ST02 19 vs 18 = +1
  RTPBRLL ROLLED=9 CLOSED=1 SKIP=0  all 9 rows to 20270101; 1 discontinued closed
  RTARCH ARCHIVED=5 VALUED=9 SKIP=0 ST01 jumpers 45 x 6.50 = 292.50 valuation

C.3 Ordering & dependencies

• Within DAILY the order is fixed. Price before post (RTPOSPT depletes off the lines RTPOSCP priced); post before cash-up and GL (both read TXSTAT='P'); cash-up before the printed report and before the COBOL audit (both read RTTILL).
• DAILY before WEEKLY / MONTHLY. The mover ranking, replenishment "sold" figures and the department margin all read posted (P) sale lines, so the day's trade must be posted first. Markdown reads the price book but the margin summary needs the posted trade.
• WEEKLY / MONTHLY before ANNUAL. The annual archive flips posted baskets to A; run it last so the weekly and monthly reads (which look for P) have already happened. Within ANNUAL the order is stocktake → roll → archive (correct the book, then roll the price book, then archive and re-value on the corrected book).
• Setup & seed run once. RTSETUP then RTREFLD precede all cycles.

D. Data Files (data dictionary) ↑ top

All files are in library BAZAAR, grounded in src/sources.mjs. Money is packed decimal (P); dates are stored as zoned 8S 0 in YYYYMMDD form (or YYYYMM/YYYYWW periods); tax and margin percentages are packed 5P 2 (e.g. 8.25) so a rate survives exactly.

RTSTORE — Store master (K STORE, UNIQUE)

RTDEPT — Department master (K DEPT, UNIQUE)

RTSKU — SKU / merchandise master (K SKU, UNIQUE)

RTPRICE — Store-level price book (K STORE, K SKU, UNIQUE)

RTSTOCK — Store stock (K STORE, K SKU, UNIQUE)

RTSALE / RTSLIN / RTTEND — POS basket

RTTILL — Till reconciliation (K STORE, K TLDATE, K TILL, UNIQUE)

RTGLDIST — GL distribution (SQL table, PK GDSEQ; index on GDACCT,GDDRCR)

RTREPL — Replenishment suggestions (K RUNNO, K STORE, K SKU, UNIQUE)

RTMKDN — Markdown log (K MKSEQ, UNIQUE)

RTSTKTK — Stocktake counts (K CTSEQ, UNIQUE)

RTDSUM — Department sales summary (K DSPER, K STORE, K DEPT, UNIQUE)

Logical files (alternate access paths)

• RTSTKLF over RTSTOCK, keyed K SKU, K STORE — the SKU-first "where is this line selling?" path; a partial keyed READE on a SKU walks every store carrying it (exercised by RTSKUXR).
• RTSLLF over RTSLIN, keyed K SKU, K TXNO — sales-by-SKU across the chain.
• RTSALF over RTSALE, keyed K STORE, K TXDATE, K TXNO — the store-day path the cash-up reads so a store's day is a keyed partial read, not a whole-file scan.

Seeded reference data (RTREFLD)

2 stores (ST01 tax 8.25% float 200.00; ST02 tax 6.00% float 150.00), 3 departments (APP 50% / HOM 40% / GRO 20%), 6 SKUs across them (one discontinued: SK000302), 9 price-book rows (ST01 runs a 10% jumper promotion; every other price equals the SKU retail so the promo arithmetic is the only variable), and 9 opening store-stock rows.

E. Operations Runbook ↑ top

E.1 Day-in-the-life

1. Confirm the job's library list includes BAZAAR and that the reference data is seeded (once: RTSETUP then RTREFLD).
2. Confirm the lane has written the day's captured baskets (TXSTAT='C') into RTSALE / RTSLIN / RTTEND.
3. Submit the daily cycle: SBMJOB CMD(CALL PGM(BAZAAR/RTDAILY)).
4. Post-check the daily run (see below), then handle inquiries via CALL BAZAAR/RTMENU.
5. If today is a weekly replenishment day, submit RTWEEK and review the RTREPL suggestions and the on-order raises.

Post-checks after the daily cycle (reconciling figures — the same ones the rt_daily volume driver checks against an independent JS oracle):

• Pricing — RTPOSCP PRICED= equals the captured basket count; each basket header foots to its own line nets; the promotion is half-up (3.897 → 3.90, not truncated).
• Stock depletion — RTPOSPT POSTED=/LINES= reconcile; a sale of 3 and a return of 1 net to −2 on the book (50 → 48); depletion is store-scoped; no store/SKU carries a negative on-hand (oversell floored and counted).
• Till invariant — EXPCASH + EXPCARD + EXPVOUC = TLSALES for each till (e.g. 33.16 + 21.22 + 0.00 = 54.38); the same footing holds against the raw RTTEND vs posted TXTOTAL. Any declared over/short shows as VARCASH with TLSTAT='V', never absorbed.
• GL balance — RTGLPST ROWS=5 per trading store; the sale block foots (cash = revenue + tax) and the whole batch balances (DR total = CR total, e.g. 84.88 = 84.88).
• COBOL audit — RTTLRPT re-proves TENDER = SALES and counts OUTOFBAL tills.

E.2 Period-end close

1. Confirm the month's daily cycles have all posted (every basket for the period is P).
2. Submit RTMONTH. Confirm RTMKDNA MARKED= and RTDSUMA ROWS=, then reconcile:

SELECT DSPER, STORE, DEPT, DSSALES, DSCOST, DSMARG, DSMGPC, DSGRADE
  FROM BAZAAR.RTDSUM WHERE DSPER = 202608;

• Summary foots — SUM(DSSALES) over the department rows equals SUM(TXNET) over posted baskets (e.g. 42.32 + 19.60 − 11.69 + 155.88 + 29.00 = 235.11).
• Margin grading is exact — e.g. ST02 apparel 49.96% is a 0.04-point miss of the 50% target and grades F; a department that traded nothing summarises to zero and grades F (it is not omitted).
• Markdown — the before image (OLDPRC) and new price (NEWPRC) are logged in RTMKDN and the shelf price in RTPRICE is updated (e.g. 4.40 → 3.08, PRMKDN 30).

For the annual close, load the physical counts into RTSTKTK (CTSTAT='O') then submit RTYEAR; reconcile the stocktake net variance, confirm all price rows carry the new effective date (20270101) with promotions/markdowns cleared and the discontinued row closed (PRSTAT='X'), and confirm every posted basket is archived (TXSTAT='A') with each stock row valued at cost.

E.3 Failure & re-run rules

Each program DSPLYs its result. Every cycle in BAZAAR/i is re-runnable — the rt_daily and rt_cycles drivers run each cycle two and three times and prove the books do not move. The guards are status flips and stable business keys:

F. Developer Reference ↑ top

Implementation detail from src/sources.mjs. All objects are in library BAZAAR. The RPG is written column-exact fixed-form (the C()/D() helpers emit C- and D-specs) with /free blocks for the arithmetic.

F.1 Arithmetic conventions

• Half-up rounding. Every derived money figure rounds half-up via %dech(v : len : 2) — line discount, tax, markdown, margin percent. The tests assert the real rounding (3.897 → 3.90, 5.10840 → 5.11, 49.961 → 49.96).
• Signed quantities. A return line carries a negative LNQTY, so gross/disc/net/tax and stock movement all flow through the same code negative — no separate refund path, and a return puts stock back with the same subtraction that a sale takes it out.
• Per-store everything. Price, promotion, tax rate and book are all keyed to the store; the same SKU can be 12.99 with a 10% promo and taxed 8.25% at ST01, and 12.99 with no promo taxed 6.00% at ST02.

F.2 Access paths & the LFs

The three logical files are genuine alternate access paths, not decoration. RTSKUXR demonstrates it: it opens RTSTKLF (keyed SKU-first) and does a partial keyed READE on the SKU alone — a read sequence the physical file (STORE-first) cannot do without a full scan. The build oracle: 9 stock rows over 6 SKUs, SK000101 carried by both stores, 268 total units (RTSKUXR SKUS=6 ROWS=9 MULTI=2 UNITS=268). Because chains move the file cursor, the batch programs use explicit KLISTs and re-CHAIN the header/line after each lookup (documented inline as "re-CHAIN ... the cursor moved").

F.3 Idempotency guards

F.4 The SQLRPGLE GL post (RTGLPST)

RTGLPST is the one SQLRPGLE program. It selects the batch date and the current max sequence with EXEC SQL SELECT ... INTO, accumulates each store's posted day (net, tax, total, cost of sale) with RPG file reads, and inserts balanced rows with free-form embedded SQL:

-- batch = earliest posted day not yet distributed
exec sql select coalesce(min(TXDATE),0) into :wbatch
  from BAZAAR.RTSALE where TXSTAT='P'
    and TXDATE not in (select distinct GDBATCH from BAZAAR.RTGLDIST);

-- one balanced insert per GL leg
exec sql insert into BAZAAR.RTGLDIST
  values (:wseq,:wbatch,:wst,:wacct,:wdc,:wamt,:wref,:wbatch);

Accounts: DR 1010-CASH = TXTOTAL, CR 4010-SALE = TXNET, CR 2200-TAX = TXTAX; DR 5010-COS / CR 1400-STK = Σ(line cost × qty). A disjoint 10-sequence block per store keeps a later trading day from colliding on the primary key.

F.5 DSPLY result-line table

Every program ends with a single DSPLY the operator (and the tests) read back. Section C.1 lists the format of each; a healthy daily cycle reads:

RTPOSCP PRICED=3 SKIP=0
RTPOSPT POSTED=3 LINES=4 SKIP=0
RTTILLR TILLS=1 SKIP=0 VAR=200
RTTILPR TILLS=1 VARIANCE=200
RTGLPST BATCH=20260801 ROWS=5
RTTLRPT TILLS 1.00 / TENDER 54.38 / SALES 54.38 / VARIANCE 200.00 / OUTOFBAL 1.00

G. Glossary ↑ top

Basket (transaction)

One POS sale or return: a header (RTSALE) plus its lines (RTSLIN) and tenders (RTTEND). Captured 'C', posted 'P', voided 'V', archived 'A'.

Cash-up / till reconciliation

Reconciling a till's declared cash to the expected tender for the day (RTTILLR), reporting any variance (VARCASH) rather than absorbing it.

Cost of sale (COS)

The SKU cost of what was sold (line cost × quantity), distributed DR 5010-COS / CR 1400-STK.

DSPLY

The RPG/COBOL operation that writes a one-line message; every BAZAAR/i program ends with a result DSPLY the operator reads back (section F.5).

GL distribution

Turning a day's posted trade into balanced debit/credit rows in the GL table (RTGLPST / RTGLDIST).

Half-up rounding

Rounding to the cent with .005 going up (via %dech). Applied to every derived money figure.

Idempotent / re-runnable

Safe to run again with no further effect. Every BAZAAR/i cycle is, guarded by status flips or stable business keys (section F.3).

Logical file (LF)

An alternate keyed access path over a physical file. RTSTKLF/RTSLLF give SKU-first paths; RTSALF gives a store+date path.

Markdown

A permanent shelf-price reduction burned into the price book (RTMKDNA / RTMKDN): discontinued 30%, class-C slow 15%.

Mover rank

A slow/medium/fast classification of a line by the week's units sold: F ≥ 10, M ≥ 3, else S.

Price book

The effective price (and promotion) for a SKU at a store (RTPRICE, keyed STORE+SKU). What POS charges, as distinct from the chain list price on the SKU master.

Replenishment suggestion

A weekly order proposal when available stock falls to the reorder point: order up to REORDQ less available less on-order (RTREPLG), raised onto the on-order book by RTONORD.

SBMJOB

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

Subfile

A 5250 display construct listing many rows on one screen (DDS SFL/SFLCTL). RTTXNIQ's basket-line list is a subfile.

Till invariant

EXPCASH + EXPCARD + EXPVOUC = TLSALES — the tender ledger must foot to the day's posted totals; asserted by RTTILLR and re-proved by the COBOL RTTLRPT.