Skip to content

AR9009 RPG36

The provided document is an RPG/36 program named AR9009.rpg36.txt, called from the main OCL script AR900.ocl36.txt to verify whether a customer has activity (e.g., invoices or sales) before allowing deletion in the Customer Master File Maintenance process (AR900) on an IBM midrange system (likely System/36 or AS/400, now IBM i). Below, I explain the process steps, business rules, tables used, and external programs called by this RPG program.

Process Steps of the RPG Program

The AR9009 program checks for customer activity in specific files to determine if a customer can be deleted. It is invoked from AR900 to ensure that customers with active records (e.g., open invoices or sales) are not deleted. The program processes input parameters, checks multiple files for matching records, and returns a flag indicating whether activity was found.

  1. Program Entry and Parameter Handling:
  2. Purpose: Receives input parameters to identify the customer and control the verification process.

  3. Steps:

    • Defines a parameter list (*ENTRY PLIST) with:
    • ARKEY (8 bytes): Key combining company and customer number (e.g., COCUST).
    • BCINST (1 byte): Billing instruction code, used to determine if sales files should be checked.
    • FOUND (1 byte): Output parameter set to indicate whether activity was found ('A' for invoices, 'S' for sales, or blank if no activity).
    • Calls the EACH subroutine to perform the activity check.
    • Sets the Last Record indicator (LR) and exits via the OUT tag.

  4. EACH Subroutine:

  5. Purpose: Checks for customer activity in invoice and sales files.
  6. Steps:
    • Invoice File Check (CRDETX):
    • Moves ARKEY to a 23-byte key (KEY21) for positioning in CRDETX (invoice detail file).
    • Uses SETLL to position the file pointer at the first record matching KEY21.
    • Reads CRDETX records in a loop (RDAGN tag) until end-of-file (indicator 10).
    • For each record:
      • Skips deleted records (ADDEL = 'D').
      • Compares the record’s key (ARDKEY) with ARKEY. If they match and the record is not deleted, sets FOUND = 'A' (indicating the customer has invoices) and exits to ENDDEL.
    • Sales File Checks (Conditional on BCINST = '5'):
    • If BCINST = '5', checks multiple sales files for activity:
      • SA5FIXD and SA5FIXM (fixed sales data, per LT02).
      • SA5BCXD and SA5BCXM (billing-related sales data, per JB03).
      • SA5DBXD and SA5DBXM (distribution-related sales data, per JB03).
      • SA5COXD and SA5COXM (customer order-related sales data, per JB03).
    • For each file:
      • Moves ARKEY to a 39-byte key (SAKEY) for positioning.
      • Uses SETLL to position the file pointer.
      • Reads the file and checks if the record’s key (SACOCU) matches ARKEY.
      • If a match is found, sets FOUND = 'S' (indicating the customer has sales activity) and exits to ENDDEL.
    • Termination:
    • If no activity is found, FOUND remains blank.
    • Exits via ENDDEL, closes files, and terminates the program.

Business Rules

The program enforces the following business rules to ensure accurate verification of customer activity before deletion:

  1. Invoice Activity Check:
  2. A customer cannot be deleted if they have active (non-deleted, ADDEL ≠ 'D') invoices in CRDETX.

  3. If a matching invoice record is found, FOUND is set to 'A', signaling that deletion is not allowed.

  4. Sales Activity Check:

  5. Sales activity is checked only if the billing instruction code (BCINST) is '5'.
  6. The program checks multiple sales files (SA5FIXD, SA5FIXM, SA5BCXD, SA5BCXM, SA5DBXD, SA5DBXM, SA5COXD, SA5COXM) for records matching the customer key (SACOCU = ARKEY).

  7. If a matching record is found in any of these files, FOUND is set to 'S', indicating that deletion is not allowed due to sales activity.

  8. Key Matching:

  9. The customer key (ARKEY) combines company and customer number and is used to match records in both invoice and sales files.

  10. Only non-deleted invoice records (ADDEL ≠ 'D') are considered for activity checks.

  11. Sequential File Checking:

  12. The program checks CRDETX first for invoices. If no activity is found, it proceeds to check sales files (if BCINST = '5').

  13. Sales files are checked in pairs (e.g., SA5FIXD and SA5FIXM), reflecting different data structures or indexes (per LT02 and JB03 revisions).

  14. Output:

  15. The FOUND parameter is set to:
    • 'A' if invoice activity is found.
    • 'S' if sales activity is found.
    • Blank if no activity is found, indicating the customer may be eligible for deletion.

Tables (Files) Used

The program uses the following files, as defined in the File Specification (F) section:

  1. CRDETX (IF, Input, 128 bytes, Key at position 2, Logical File):
  2. Invoice detail file used to check for customer invoices.

  3. Fields:

    • ADDEL (1 byte): Delete code (D for deleted).
    • ARDKEY (8 bytes): Key combining company and customer number.

  4. SA5FIXD (IF, Input, 1024 bytes, Key at position 2, Logical File, per LT02):

  5. Sales file (fixed data, detail) for checking customer sales activity.

  6. Field: SACOCU (8 bytes): Key combining company and customer number.

  7. SA5FIXM (IF, Input, 1024 bytes, Key at position 2, Logical File, per LT02):

  8. Sales file (fixed data, master) for checking customer sales activity.

  9. Field: SACOCU (8 bytes): Key combining company and customer number.

  10. SA5BCXD (IF, Input, 1024 bytes, Key at position 2, Logical File, per JB03):

  11. Billing-related sales file (detail) for checking customer sales activity.

  12. Field: SACOCU (8 bytes): Key combining company and customer number.

  13. SA5BCXM (IF, Input, 1024 bytes, Key at position 2, Logical File, per JB03):

  14. Billing-related sales file (master) for checking customer sales activity.

  15. Field: SACOCU (8 bytes): Key combining company and customer number.

  16. SA5DBXD (IF, Input, 1024 bytes, Key at position 2, Logical File, per JB03):

  17. Distribution-related sales file (detail) for checking customer sales activity.

  18. Field: SACOCU (8 bytes): Key combining company and customer number.

  19. SA5DBXM (IF, Input, 1024 bytes, Key at position 2, Logical File, per JB03):

  20. Distribution-related sales file (master) for checking customer sales activity.

  21. Field: SACOCU (8 bytes): Key combining company and customer number.

  22. SA5COXD (IF, Input, 1024 bytes, Key at position 2, Logical File, per JB03):

  23. Customer order-related sales file (detail) for checking customer sales activity.

  24. Field: SACOCU (8 bytes): Key combining company and customer number.

  25. SA5COXM (IF, Input, 1024 bytes, Key at position 2, Logical File, per JB03):

  26. Customer order-related sales file (master) for checking customer sales activity.
  27. Field: SACOCU (8 bytes): Key combining company and customer number.

External Programs Called

The AR9009 program does not call any external programs. It performs direct file operations on CRDETX and the sales files (SA5FIXD, SA5FIXM, SA5BCXD, SA5BCXM, SA5DBXD, SA5DBXM, SA5COXD, SA5COXM) to check for customer activity.

Summary

  • Process Steps: Receives parameters (ARKEY, BCINST, FOUND), checks CRDETX for invoice activity, and, if BCINST = '5', checks multiple sales files (SA5FIXD, SA5FIXM, SA5BCXD, SA5BCXM, SA5DBXD, SA5DBXM, SA5COXD, SA5COXM) for sales activity. Sets FOUND to 'A' (invoices), 'S' (sales), or blank (no activity).
  • Business Rules: Prevents deletion if the customer has active invoices or sales (when BCINST = '5'); skips deleted invoice records; checks multiple sales files for comprehensive activity verification.
  • Tables Used: CRDETX (invoices), SA5FIXD, SA5FIXM, SA5BCXD, SA5BCXM, SA5DBXD, SA5DBXM, SA5COXD, SA5COXM (sales data).
  • External Programs Called: None.

This RPG/36 program is a critical validation step in the customer deletion process, ensuring that customers with active invoices or sales are not deleted, maintaining data integrity in the customer master maintenance system. If you need further details on specific logic or file structures, let me know!