Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

C12 — Recovered Requirements Catalogue

Diagram coverage

Customer maintenance and lookup

REQ-CUST-01 — Customer creation. The Customer function shall allow an operator to enter a customer number, first and last names, company, two address lines, city, state, ZIP code, and phone. In the Java implementation, D4_Cust.input_cust() collects these values and inserts a row into customer; after a non-interrupted insert it obtains the generated identifier and displays it. The corresponding 4GL input_cust() flow uses INPUT BY NAME, assigns the generated number from SQLCA.SQLERRD[2], and reports the result. The Java and 4GL implementations are related evidence, but equivalence between them is not independently established. E0007 E0009

REQ-CUST-02 — Repeated customer entry. The customer module shall support both one-customer entry and repeated “many-add” entry. A repeated-entry session shall return to the beginning of the form after each completed customer and shall provide an interrupt or menu-return path without inserting the unfinished record. The available evidence documents this behavior in the 4GL source and reports corresponding One-add and Many-add commands in D4_Cust.java. E0007 E0009

REQ-CUST-03 — Customer search. Customer lookup shall accept query-by-example criteria. Documented criteria include literal values, ranges separated by :, lists separated by |, relational operators, and ? or * wildcards. The Java customer browse orders results by last name and offers Next, Previous, First, Last, Select, and Quit actions; the 4GL query uses CONSTRUCT and a cursor over customer. The query parser and its escaping guarantees are not fully evidenced, so the security and exact syntax of generated predicates remain questions for C05 and C08. E0007 E0009 E0012

REQ-CUST-04 — Customer update. An operator shall not update a customer until a current customer has been selected. When a selected customer is edited and the input is completed, the matching customer row shall be updated. If input is interrupted, the existing row shall be reloaded and the update shall be reported as aborted rather than committed. This behavior is directly described for D4_Cust.update_customer(); the complete implementation contract remains conditional because one analysis notes that the separate D4_Cust.java artifact was locally unavailable in another source range. E0009 E0012

REQ-CUST-05 — Customer deletion. Deletion shall require a selected customer and explicit confirmation matching y or Y. A customer with related orders shall not be deleted. The Java implementation counts rows in orders for the selected customer_num; the displayed message refers to “active orders,” but the supplied query does not distinguish active, paid, completed, or cancelled orders. The required business definition of an “active order” therefore remains unresolved. E0002 E0007

REQ-CUST-06 — Deletion feedback. A declined deletion shall leave the customer unchanged and shall not report successful deletion. This is an observed requirement in the Java customer flow, but the separate legacy menu1.4gl.main program contains a contrary behavior: del_cust() conditionally executes the delete but unconditionally clears the form and displays “Record deleted.” That legacy behavior is a known exception and should not be merged with the Java D4_Cust behavior without proving that the programs share an execution path. E0010

Order entry and order viewing

REQ-ORD-01 — Customer prerequisite. D4_Orders.add_order() shall first obtain a customer through query or selection. If no customer is found, it may open customer entry and call add_customer(FALSE); if no customer number is ultimately available, order entry shall return without inserting an order. This dependency is visible in the Java order flow, although the exact status contract of D4_Cust.query_customer() remains unresolved. E0002 E0012

REQ-ORD-02 — Order header and line entry. A new order shall collect order-date, purchase-order, and shipping-instruction values, followed by line items. The order-entry array supports up to ten items in the documented application. Each item includes item number, stock number, manufacturer code, description, quantity, unit price, and total price; descriptions and prices are obtained from stock data rather than freely entered in the form. E0007 E0009

REQ-ORD-03 — Stock-assisted item selection. While entering a line, the operator shall be able to invoke stock selection from stock number or manufacturer-code entry. In the 4GL flow this is associated with CTRL-B; selecting a stock record populates the order line. A valid stock/manufacturer combination is required before the item description and unit price can be used. The supplied source does not show explicit missing-row handling in get_item(), so the behavior for an invalid combination remains unresolved. E0007 E0010

REQ-ORD-04 — Line total calculation. When quantity and unit price are valid, item_total() shall calculate total_price as quantity multiplied by unit price. Invalid or incomplete item values shall return the operator to stock-number entry rather than producing a committed line. E0007

REQ-ORD-05 — Transactional posting. New-order posting shall insert the order header, obtain the generated order number, insert its item rows, and commit only after the required inserts succeed. If the order insert or item insertion reports failure, the operation shall roll back and display an error. D4_Orders.add_order() visibly implements these explicit rollback branches. Rollback after an uncaught exception is not established because the broad exception handler delegates to ErrorHandler without visibly issuing a rollback; this detail belongs in C04 and C08. E0002 E0012

REQ-ORD-06 — Invoice generation. After a successful commit, the Java flow shall report that the order was added, construct an invoice filename from the order number, invoke invoice(), and clear the form. Invoice data combines order, item, stock, and manufacturer information. Output destination depends on print_option, whose supported values are file, printer, and screen modes. Exact report-framework completion semantics remain dependent on unavailable framework classes. E0007 E0012 E0013

REQ-ORD-07 — Order totals. The order-entry total shall reflect a ten-percent uplift in the observed Java implementation, where order_total() multiplies the item sum by Money.valueOf(1.1d). The invoice path separately calculates 6.5 percent sales tax and 3.5 percent shipping. These figures suggest an intended ten-percent correspondence, but the source does not prove whether the interactive total is tax, shipping, or a combined charge, nor whether rounding is identical. The business interpretation and monetary precision are unresolved rules for C05 and C06. E0002 E0012

REQ-ORD-08 — Customer-based order viewing. get_order() shall retrieve orders for the selected customer, display associated items, limit displayed items to ten, calculate an order total, and allow the operator to select an order. This capability is implemented in D4_Orders; however, the separate legacy ordmenu.4gl.main program has additional Modify and Delete paths and must remain distinct from the Java interactive entry flow. E0002 E0007 E0009

REQ-ORD-09 — Order update and deletion qualification. In the Java D4_Orders implementation, update_order() and delete_order() are menu-level entries that display “This option has not been implemented.” They shall therefore not be documented as successful order-maintenance capabilities. Separately, ordmenu.4gl.main reports implemented Modify and Delete commands, subject to chosen = 1; these are conflicting program-specific findings, not a single lifecycle. E0002 E0007 E0009

Stock and reference data

REQ-STK-01 — Stock lookup dependency. Stock and manufacturer data shall support order-line lookup. Startup loaders populate bounded in-memory arrays: p_stock holds up to 30 records and p_state up to 50; records beyond those capacities are not retained by the observed loaders. No user-visible overflow behavior is established. E0012

REQ-STK-02 — Stock maintenance boundary. The Java D4_Stock menu exposes add, find, update, and delete operations, but each handler reports that the option has not been implemented. The legacy d4_stock.4gl source reports the same result. Stock selection for order entry therefore must not be interpreted as stock CRUD capability. E0002 E0007

REQ-STK-03 — State selection. Customer state entry shall support uppercase state codes and a selectable state list when the entered code is missing or invalid. statehelp() loads state records ordered by name, opens state_list, assigns the selected code to the customer, and redisplays it. The callback wiring and exact validation semantics are not fully demonstrated in every Java form variant. E0007 E0009

Reporting and operator controls

REQ-RPT-01 — Implemented reports. The Java report module shall support mailing-label and accounts-receivable reports. Mailing labels shall be selectable by customer criteria and ordered by ZIP code; accounts receivable shall select orders whose paid_date is null. Both reports support file, printer, and screen destinations through print_option. E0007

REQ-RPT-02 — Unimplemented reports. Backlog and stock-list reports shall be treated as unavailable in the current Java implementation: print_backlog() and print_stock() display the unimplemented-option error. Help text and 4GL source independently describe those options as not implemented, despite broader inventory claims. E0002 E0007

REQ-RPT-03 — Report interruption. The legacy 4GL report flows attempt to respond to int_flag during row processing. The source resets the flag before the later post-loop abort test, so an interrupted report may be treated as completed. This is a reported source-analysis finding rather than a proven runtime result and requires clarification in C04. E0008

REQ-CTL-01 — Command execution. D4_Main.bang() shall accept a command and pass it to _app.execute(true, Str.valueOf(cmd)). The source shows no command allowlist or sanitization; the effective permissions and security boundary of Application.execute() remain unresolved and are detailed in C09. E0012

REQ-CTL-02 — Help and interruption. The documented application provides field help through function keys and permits data-entry interruption, including DEL or CTRL-C in the 4GL documentation and F2 or Ctrl-Y in the Java-translated customer flow. These key mappings differ by artifact and must not be treated as one universal interface contract without identifying the active program. E0004 E0007

Expandable topic detail

Browse all topic detail.