Skip to content

AP256A RPG

The provided RPG program, AP256A.rpg.txt, is executed by the OCL program AP256.ocl36.txt, which is itself called from the main OCL program (AP250.ocl36.txt) within an IBM System/36 or AS/400 Accounts Payable (A/P) system. The purpose of AP256A is to process a temporary A/P transaction file (APDTWS) and update an indexed temporary file (APDTWSC) with counts of ACH (Automated Clearing House) transactions for each vendor, using the vendor master extension file (APVNFMX) for validation. Below, I will explain the process steps, business rules, tables (files) used, and external programs called based on the RPG code.


Process Steps of the AP256A RPG Program

The AP256A RPG program reads records from APDTWS, checks vendor information in APVNFMX, and updates APDTWSC with counts of ACH transactions. Here is a detailed breakdown of the process steps:

  1. Initialization:
  2. The program initializes variables for processing:

    • Sets COUNT to zero (used to track the number of ACH transactions for a vendor).
    • Clears KEY20 and KEY13 (used to build a key for accessing APVNFMX).
  3. Main Processing Loop (Indicator 01):

  4. For each record in the primary input file APDTWS (processed with indicator 01), the program performs the following:

    • Builds a key (KEY20, 20 characters) for accessing APVNFMX:
    • Copies the company/vendor number (ADCOVN, positions 2-8) from APDTWS into KEY20.
    • Sets KEY13 to 'ACHE' (indicating ACH transaction type).
    • Combines KEY13 into KEY20 to form the full key.
    • Positions the file pointer in APVNFMX using SETLL with KEY20 to locate records matching the company/vendor and ACH type.
  5. Read Vendor Master Extension (APVNFMX):

  6. Enters a loop (AGAIN tag) to read APVNFMX records:

    • Reads the next record in APVNFMX (indicator 10 set on end-of-file).
    • If end-of-file is reached (10 set), jumps to the END tag to exit the loop.
    • Compares the company/vendor number (ADCOVN from APDTWS) with AMCOVN from APVNFMX:
    • If they do not match, jumps to END to skip the record.
    • Checks if the form type (AMFMTY) in APVNFMX is 'ACHE':
    • If not 'ACHE', jumps to END to skip the record.
    • Increments the COUNT variable by 1 for each matching ACH record.
    • Loops back to AGAIN to read the next APVNFMX record.
  7. Update Temporary File (APDTWSC):

  8. Chains to APDTWSC using ADCOVN as the key to check if a record exists for the company/vendor (indicator 98 set if not found).
  9. Writes or updates a record in APDTWSC:

    • For new records (98 set, no existing record):
    • Writes a new record with:
      • ADCOVN (company/vendor number, positions 2-8).
      • COUNT (number of ACH transactions, binary, position 10).
    • For existing records (N98, record found):
    • Updates the existing record with the new COUNT value (binary, position 10).
  10. Completion:

  11. Processes all APDTWS records, updating APDTWSC with ACH transaction counts for each vendor.
  12. Terminates, returning control to the calling OCL program (AP256.ocl36.txt).

Business Rules

The program enforces the following business rules based on its logic and context within the A/P system:

  1. ACH Transaction Counting:
  2. Counts the number of ACH transactions (AMFMTY = 'ACHE') for each vendor in APVNFMX that matches the company/vendor number (ADCOVN) from APDTWS.
  3. Only records with AMFMTY = 'ACHE' are counted, ensuring the program focuses on ACH-specific transactions.

  4. Vendor Matching:

  5. Matches APDTWS records to APVNFMX using the company/vendor number (ADCOVN vs. AMCOVN).
  6. Skips non-matching records to ensure accurate vendor association.

  7. Temporary File Updates:

  8. Updates APDTWSC with the count of ACH transactions (COUNT) for each vendor.
  9. Creates new records if no existing record is found (98 set) or updates existing records (N98).
  10. Stores only the company/vendor number (ADCOVN) and count (COUNT) in APDTWSC, reflecting the compact 10-byte record structure.

  11. File Access:

  12. APDTWS is processed sequentially as the primary input file (IP).
  13. APVNFMX is accessed randomly (IF, keyed) to retrieve vendor data.
  14. APDTWSC is an update file (UF, keyed), allowing both read and write operations.

  15. No Error Reporting:

  16. The program does not generate error reports for unmatched records or invalid data, silently skipping non-matching APVNFMX records or handling missing APDTWSC records by creating new ones.

  17. Integration with A/P Process:

  18. Relies on APDTWS being populated by prior steps in the main OCL program (AP250.ocl36.txt).
  19. Prepares APDTWSC for use by the subsequent AP256 program, which generates reports based on this data.

Tables (Files) Used

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

  1. APDTWS (IP, 256 bytes, keyed, DISK):
  2. Primary input file, temporary A/P transaction file created by the main OCL program.
  3. Fields include:

    • ADDEL: Deletion flag (position 1).
    • ADCO: Company number (positions 2-3).
    • ADVEND: Vendor number (positions 4-8).
    • ADCOVN: Company/vendor number (positions 2-8).
    • ADINVN: Invoice number (positions 9-18).
    • ADIDSC: Invoice description (positions 19-43).
    • ADINV$: Invoice amount (packed, positions 44-49).
    • ADDISC: Discount amount (packed, positions 50-54).
    • ADLPAM: Last payment amount (packed, positions 55-60).
    • ADDATE: Date (positions 61-66).
    • ADVCH#: Voucher/check number (positions 67-71).
  4. APVNFMX (IF, 266 bytes, keyed, DISK):

  5. Vendor master extension file, accessed randomly for vendor data.
  6. Fields include:

    • AMDEL: Deletion code (position 1, e.g., 'D' for delete).
    • AMCONO: Company number (positions 2-3).
    • AMCVEN: Vendor number (positions 4-8).
    • AMCOVN: Company/vendor number (positions 2-8).
    • AMFMTY: Form type (positions 9-12, e.g., 'ACHE' for ACH).
    • AMSEQ#: Sequence number (positions 13-21).
    • AMCNTC: Contact name (positions 22-71).
    • AMEMLA: Email address (positions 72-131).
    • AMFAX#: Fax number (positions 132-151).
    • AMFMYN: Send original flag (position 152).
  7. APDTWSC (UF, 10 bytes, keyed, DISK):

  8. Indexed temporary file, created by the OCL program with a key in positions 2-7.
  9. Fields include:
    • ADCOVN: Company/vendor number (positions 2-8).
    • COUNT: Number of ACH transactions (binary, position 10).

External Programs Called

The AP256A RPG program does not call any external programs. It is self-contained, performing all processing within the main logic and a single DO loop. It is invoked by the AP256.ocl36.txt OCL program as part of the A/P workflow.


Summary

The AP256A RPG program is a specialized component of the A/P system, designed to count ACH transactions for vendors and store the results in an indexed temporary file. Its key functions are:

  • Process Steps:
  • Reads APDTWS records sequentially.
  • Matches each record to APVNFMX using a company/vendor key and checks for ACH form type ('ACHE').
  • Counts matching ACH transactions and updates APDTWSC with the count for each vendor.
  • Creates or updates APDTWSC records with the company/vendor number and ACH count.

  • Business Rules:

  • Counts only ACH transactions (AMFMTY = 'ACHE') for matching vendors.
  • Matches records using the company/vendor number (ADCOVN vs. AMCOVN).
  • Updates APDTWSC with compact records containing only the company/vendor number and ACH count.
  • Operates in a read/write environment with no error reporting for unmatched records.
  • Prepares data for subsequent reporting by AP256.

  • Tables Used:

  • APDTWS: Temporary A/P transaction file (input).
  • APVNFMX: Vendor master extension file (input, reference).
  • APDTWSC: Indexed temporary file (update, output).

  • External Programs Called: None.

The program integrates with the A/P process by preparing summarized ACH transaction data for use by the AP256 program, which generates reports. If you have the RPG source code for AP256 or additional details about APDTWS or the reports, I can provide further analysis. Please let me know if you need clarification or more details!