Skip to content

BB943V RPGLE

The RPG program BB943V.rpgle (referred to as BB9643V in the BB943 program) is an IBM i (AS/400) validation program called by BB943 to validate input fields for the Customer Sales Agreement Maintenance process. It ensures that the data entered in the sales agreement record adheres to specific business rules before it is added or updated in the bicuag file. Below, I will explain the process steps, business rules, tables used, and external programs called based on the provided RPG source code.

Process Steps of the RPG Program

The BB943V program is designed to validate a data structure (CUAGDS) containing customer sales agreement fields passed from BB943. It performs checks against multiple database files and returns error messages or cursor positioning information if validation fails. Here are the key process steps:

  1. Initialization (*inzsr Subroutine, Implicit):
  2. Parameters: Receives two parameters:
    • CUAGDS: A data structure containing fields like company (CONO), customer (CUST), location (ALOC), container (KCNTR), product codes (S3PR), start/end dates (STDT, ENDT), and others (see CUAGDS definition).
    • p$fgrp: File group ('G' or 'Z') to determine database file overrides.

  3. Y2K Setup: Sets y2kcen = 19 and y2kcmp = 80 for date handling (likely for legacy Y2K compatibility, per jb01).

  4. Open Database Tables (opntbl Subroutine):

  5. Applies file overrides (ovg or ovz) based on p$fgrp using the QCMDEXC API, mapping files to appropriate libraries (e.g., gbicont or zbicont).

  6. Opens input files (BICONT, ARCUST, SHIPTO, INLOC, GSTABL, GSCNTR1, BICUA3, BICUA9, BBORDH, GSPROD) with USROPN for validation checks.

  7. Main Validation Logic ($SBLK Subroutine):

  8. Initializes error flags and message fields (@MSG, @PC).

  9. Performs validation checks on the CUAGDS data structure fields, including:

    • Company (CONO): Chains to BICONT to verify the company exists (COM(01) if invalid).
    • Customer (CUST): Chains to ARCUST to verify the customer exists (COM(06) if not found).
    • Location (ALOC): Chains to INLOC to verify the location exists (COM(20) if invalid).
    • Container (KCNTR): Chains to GSCNTR1 to verify the container code (COM(33) if invalid). Checks container type (TCCNTY) against GSTABL (COM(32) if invalid).
    • Unit of Measure (UNMS): Validates against GSTABL (COM(08) or COM(50) if invalid).
    • Product Codes (S3PR): Ensures at least one valid product code is entered (COM(09)), checks for duplicates (COM(11)), and verifies against GSPROD (COM(51)). Ensures fluid products have a valid container (COM(54)) and non-fluid products have a blank container (COM(17), COM(52)).
    • Purchase Order (PORD): Validates against BBORDH if S3POOR = 'O' (COM(13) if invalid).
    • Ship-To (SHIP, ALSH): Validates ship-to codes against SHIPTO. Ensures ALSH = 'Y' implies SHIP = 0 (COM(28)), and ALSH = 'N' implies SHIP ≠ 0 (COM(49)). Checks for valid ship-to (COM(48)).
    • Other Locations (S3LO): Ensures no duplicates (COM(40)) and validates against INLOC.
    • Other Ship-To (S3SH): Ensures no duplicates (COM(43)) and validates against SHIPTO.
    • Other Customer Ship-To (S3CS): Ensures no duplicates (COM(56), COM(57)) and validates customer/ship-to combinations against ARCUST and SHIPTO.
    • Start/End Dates and Times (STDT, STTM, ENDT, ENTM): Validates date formats and ensures end date/time follows start date/time (COM(15), COM(18), COM(35)). Checks hours (00-23, COM(21), COM(23)) and minutes (00-59, COM(22), COM(24)). Ensures non-zero times (COM(25), COM(26)).
    • Freight Code (FRCD): Validates against GSTABL (COM(31) if invalid).
    • Prepaid (PPD): Must be 'P' or blank (COM(55)).
    • Primary Flag (PRIM): Must be 'I' or 'M' (COM(29)).
    • Min/Max Quantity (MNQY, MXQY): Ensures MXQY ≥ MNQY (implicit check, no specific error message listed).
    • PO/Order Code (S3POOR): Must be 'P' or 'O' (COM(36)).
    • Password (KAGPW): Validates against BICONT (BCAGPW, COM(34)). Requires a password if the start date is more than 3 days ago (COM(37)).

  10. Duplicate Record Check (EDITS3 Subroutine):

  11. For add operations (ADDREC = 'Y'), checks BICUA3 to ensure no existing agreement matches the key fields (company, customer, location, container, unit of measure, ship-to, product codes, PO, min/max quantities, start date/time, freight code) using otkH102 keylist (COM(58) if a duplicate exists).
  12. For update operations (ADDREC ≠ 'Y'), checks BICUA9 for:
    • An agreement with the new end date/time, ignoring records with start dates after the current end date or end dates not equal to 12/31/2079 23:59 (COM(58) if no match).
    • An agreement without an end date/time, ensuring a record exists to update (COM(58) if no match).

  13. Skips update checks for "copy to other" fields per jb01.

  14. Copy to Other Validation (jb01):

  15. Only allows "copy to other" processing (other locations, ship-tos, customer ship-tos) when adding a record (ADDREC = 'Y'), either via F6 or option 3 (copy).
  16. Protects "copy to other" fields during updates and prevents their modification.

  17. Validates "expire" field (S3EXPR) only for copy operations (COM(47) if not 'Y' during copy).

  18. Program Termination:

  19. Sets *inlr = *on and returns, passing back the CUAGDS data structure with any error messages (@MSG) and cursor positioning (@PC).

Business Rules

The program enforces the following business rules to validate customer sales agreement data:

  1. Mandatory Field Validation:
  2. Company (CONO) must exist in BICONT (COM(01)).
  3. Customer (CUST) must exist in ARCUST (COM(06)).
  4. Location (ALOC) must exist in INLOC (COM(20)).
  5. At least one valid product code (S3PR) must be entered (COM(09)).

  6. PO/Order code (S3POOR) must be 'P' (purchase order) or 'O' (order) (COM(36)).

  7. Duplicate Prevention:

  8. No duplicate product codes (COM(11)).
  9. No duplicate other locations (COM(40)), ship-tos (COM(43)), or customer ship-tos (COM(56), COM(57)).

  10. No duplicate agreements for add operations based on key fields (COM(58)).

  11. Container and Product Rules:

  12. Container (KCNTR) must be valid in GSCNTR1 (COM(33)) and have a valid type in GSTABL (COM(32)).
  13. Non-fluid products (based on TPFLCD in GSPROD) must have a blank container (COM(17), COM(52)).
  14. Fluid products require a valid container (COM(54)).

  15. Unit of measure (UNMS) must be valid in GSTABL (COM(08), COM(50)).

  16. Date and Time Validation:

  17. Start and end dates (STDT, ENDT) must be valid (COM(15), COM(18)).
  18. Start and end times (STTM, ENTM) must have valid hours (00-23, COM(21), COM(23)) and minutes (00-59, COM(22), COM(24)).
  19. Start and end times cannot be all zeros (COM(25), COM(26)).
  20. End date/time must follow start date/time (COM(35)).

  21. Allows same start dates if freight codes (FRCD) differ (MG04).

  22. Ship-To Rules:

  23. If all ship-tos (ALSH = 'Y'), ship-to (SHIP) must be zero (COM(28)).

  24. If not all ship-tos (ALSH = 'N'), ship-to must be non-zero and valid in SHIPTO (COM(49), COM(48)).

  25. Copy to Other Restrictions (jb01):

  26. "Copy to other" fields (other locations, ship-tos, customer ship-tos) are only editable during add operations (F6 or option 3).
  27. These fields are protected during updates.

  28. The expire field (S3EXPR) is only used for copy operations and must be 'Y' (COM(47)).

  29. Password Validation:

  30. Agreement password (KAGPW) must match BCAGPW in BICONT (COM(34)).

  31. A password is required if the start date is more than 3 days in the past (COM(37)).

  32. Other Field Rules:

  33. Freight code (FRCD) must be 'C', 'P', 'A', or blank (COM(31)).
  34. Prepaid (PPD) must be 'P' or blank (COM(55)).
  35. Primary flag (PRIM) must be 'I' (invoice) or 'M' (month-end) (COM(29)).
  36. Either price (PRCE) or off-price (OFFP) must be non-zero (COM(14)).

  37. Purchase order (PORD) must exist in BBORDH if S3POOR = 'O' (COM(13)).

  38. Update Validation:

  39. For updates, ensures an agreement exists with the specified end date/time or no end date/time (COM(58)).
  40. Ignores records with start dates after the current end date or end dates not equal to 12/31/2079 23:59.

Tables Used

The program uses the following database files, with overrides applied based on p$fgrp ('G' or 'Z'):

  1. BICONT: Company master file (input, validates CONO and BCAGPW).
  2. ARCUST: Customer master file (input, validates CUST).
  3. SHIPTO: Ship-to file (input, validates SHIP and customer ship-tos).
  4. INLOC: Location file (input, validates ALOC and other locations).
  5. GSTABL: Table file (input, validates container type and unit of measure).
  6. GSCNTR1: Container file (input, validates KCNTR, alpha key, replaced GSCNTR per jk06 in BB943).
  7. BICUA3: Sales agreement logical file (input, checks for duplicate agreements during add, includes min/max quantities per jk02).
  8. BICUA9: Sales agreement logical file (input, checks for existing agreements during update, includes min/max quantities per jk02).
  9. BBORDH: Order header file (input, validates purchase order number for S3POOR = 'O').
  10. GSPROD: Product file (input, validates product codes and fluid/non-fluid status, added per jk04).

Overrides map these files to specific libraries (e.g., gbicont or zbicont).

External Programs Called

The program calls the following external program:

  1. QCMDEXC: System API to execute file override commands for the specified file group ('G' or 'Z').

No other external programs are explicitly called in the provided source code. Note that BB943V is called by BB943 but does not itself call other user-defined programs.

Summary

  • Process Steps: Initializes parameters, applies file overrides, opens database files, validates fields in the CUAGDS data structure (company, customer, location, container, product codes, dates, etc.), checks for duplicate or existing agreements, and returns error messages or cursor positioning if validation fails.
  • Business Rules: Validates mandatory fields, prevents duplicates, enforces container/fluid product rules, ensures valid dates/times, restricts "copy to other" to add operations, requires passwords for past dates, and validates freight codes, prepaid flags, and primary flags.
  • Tables Used: BICONT, ARCUST, SHIPTO, INLOC, GSTABL, GSCNTR1, BICUA3, BICUA9, BBORDH, GSPROD.
  • External Programs Called: QCMDEXC.

If you need a deeper analysis of specific validation checks, file structures, or related programs, please provide additional details or source code (e.g., for BB943 or BB943P). Alternatively, I can perform a DeepSearch for related information if enabled. Let me know how to proceed!