Skip to content

AR157A RPG36

The provided document, AR157A.rpg36.txt, is an RPG III program used in IBM midrange systems (e.g., AS/400, iSeries) to perform field adjustments on an EFT (Electronic Funds Transfer) cash receipts batch file before its creation. This program is loaded and executed by the AR157A.ocl36 OCL program, which is part of the EFT cash receipts batch file creation process orchestrated by the AR157P.ocl36 and AR157.ocl36 programs. Below is a detailed explanation of the process steps, business rules, tables/files used, and external programs called, based on the RPG code.


Process Steps of the RPG Program (AR157A)

The AR157A RPG program is designed to process records in the CRTRAN file, adjusting fields as needed for the EFT cash receipts batch file. The provided source code is incomplete, as it primarily defines the file structure and input/output specifications but lacks the main program logic (e.g., C specs for calculations or updates). However, based on the context and the OCL program (AR157A.ocl36), we can infer the steps involved. Here’s a step-by-step breakdown:

  1. Program Initialization:
  2. The program header (H spec, line 0001) identifies the program as AR157A with identifier P064.
  3. The file CRTRAN is defined as an update file (UP) with a record length of 256 bytes, stored on disk (DISK) (line 0004).
  4. Input specifications (I specs, lines 0059–0076) define the structure of the CRTRAN file, mapping fields such as transaction amount, date, customer number, and more.
  5. Output specifications (O specs, lines 0123–0132) indicate that the program writes records to CRTRAN with at least one field (KYUPDT) updated at position 37.

  6. Read and Process CRTRAN Records:

  7. The program likely reads each record from the CRTRAN file, identified by the input specification CRTRAN NS 01 (line 0007), which defines a non-sequential read for record type 01.
  8. For each record, the program processes fields such as:
    • ATDEL (position 1): Delete flag ('D' indicates a deleted record).
    • ATCO (positions 7–8): Company number.
    • ATCUST (positions 9–14): Customer number.
    • ATINV# (positions 15–21): Invoice number.
    • ATAMT (positions 22–26, packed): Transaction amount.
    • ATDISC (positions 27–30, packed): Transaction discount.
    • ATDATE (positions 32–37): Transaction date.
    • KYUPDT (positions 228–233): Likely the bank upload date, used as a key or for adjustment.
    • Other fields like G/L accounts, terms, and tax-related fields (ADTXCN, ADTXYY, etc.).
  9. The program likely performs field adjustments, such as updating KYUPDT (bank upload date) or other fields to ensure the data is formatted correctly for EFT processing.

  10. Update CRTRAN Records:

  11. The output specification CRTRAN D 01 (line 0123) indicates that the program updates records in the CRTRAN file.
  12. The field KYUPDT is written to positions 37 (line 0126), suggesting that the bank upload date is updated or adjusted in the record.
  13. Other fields may also be updated, but the incomplete C specs limit visibility into the exact logic.

  14. Program Termination:

  15. After processing all records, the program terminates, leaving the CRTRAN file updated and ready for the subsequent copy operation in AR157.ocl36 (which copies CRTRAN to ?9?CRIEGG).

Business Rules

Based on the RPG code, the OCL context, and the role of AR157A in the EFT cash receipts process, the following business rules are inferred:

  1. Field Adjustment for EFT Compliance:
  2. The program adjusts fields in the CRTRAN file to ensure the EFT transaction data is correctly formatted for the cash receipts batch file.
  3. A key adjustment involves the KYUPDT field (bank upload date), which is written to position 37, ensuring it aligns with the validated upload date from AR157P.rpgle (stored at location 110, length 6).

  4. Non-Deleted Records:

  5. The ATDEL field (position 1) indicates whether a record is deleted ('D'). The subsequent AR157.ocl36 program filters out records where ATDEL = 'D', so AR157A likely ensures this flag is correctly set or preserved.

  6. Dynamic File Naming:

  7. The CRTRAN file is dynamically named as ?9?E?L'110,6'? (e.g., QS36F/CO123E202311), where:
    • ?9? is the company code or batch identifier.
    • ?L'110,6'? is the bank upload date (KYUPDT, e.g., 202311 for November 2023).
  8. This ensures the program processes the correct company- and date-specific EFT data.

  9. Shared File Access:

  10. The CRTRAN file is opened in shared mode (DISP-SHR in AR157A.ocl36), allowing concurrent access by other processes, which is critical in a multi-user environment.

  11. Data Integrity:

  12. The program likely validates or adjusts fields like ATAMT (transaction amount), ATDISC (discount), ATDATE (transaction date), and G/L accounts (ATGLCR, ATGLDR, ATGLDI) to ensure they meet EFT or accounting requirements.

Tables/Files Used

The program interacts with the following file:

  1. CRTRAN:
  2. Type: Update file (UP), disk-based, 256 bytes.
  3. Physical File Label: ?9?E?L'110,6'? (e.g., QS36F/CO123E202311, where ?9? is the company code and ?L'110,6'? is the bank upload date).
  4. Library: Likely QS36F (based on consistency with AR157.ocl36).
  5. Disposition: DISP-SHR (shared access, as specified in AR157A.ocl36).
  6. Purpose: Temporary workfile containing EFT individual entry data, which is adjusted by AR157A before being copied to the cash receipts batch file (?9?CRIEGG in AR157.ocl36).
  7. Key Fields:
    • ATDEL (1): Delete flag.
    • ATCO (7–8): Company number.
    • ATCUST (9–14): Customer number.
    • ATINV# (15–21): Invoice number.
    • ATAMT (22–26, packed): Transaction amount.
    • ATDISC (27–30, packed): Transaction discount.
    • ATDATE (32–37): Transaction date.
    • KYUPDT (228–233): Bank upload date (adjusted in output).
    • Other fields for G/L accounts, terms, and tax data.
  8. Usage: Read and updated by the program to adjust fields for EFT processing.

External Programs Called

The AR157A RPG program does not explicitly call any external programs, based on the provided code. The incomplete C specs (calculation specifications) might include calls to other programs, but none are visible in the source.


Notes

  • Incomplete Code: The provided RPG source lacks the calculation specifications (C specs) that would detail the specific field adjustments. The program likely updates fields like KYUPDT, ATAMT, or others to ensure EFT compliance, but the exact logic is not visible.
  • Integration with Program Suite: AR157A is loaded by AR157A.ocl36, which is called by AR157.ocl36, itself invoked by AR157P.ocl36. The ?9? (company code) and ?L'110,6'? (bank upload date) parameters ensure consistency across the suite.
  • Jan Beccari Change: The change from ?WS? to GG (noted in AR157.ocl36 and AR157P.ocl36) does not directly affect AR157A, but the adjusted CRTRAN file is copied to ?9?CRIEGG in AR157.ocl36, reflecting this change.
  • Purpose of Adjustments: The program likely formats fields for EFT standards (e.g., ACH file requirements) or aligns data with internal AR processes, such as ensuring correct G/L accounts or transaction dates.
  • Shared Access: The DISP-SHR in the OCL program supports a multi-user environment, ensuring no file locks during processing.

If you have additional details (e.g., the missing C specs for AR157A or related program logic) or need further analysis of the integration with the other programs, please let me know!