Skip to content

AP256A

The RPG program AP256A.RPG is invoked by the OCL procedure AP256A as a preprocessing step before AP256.RPG36 in the Accounts Payable (A/P) Check Register process. Its primary purpose is to create or update the APDTWSC file, which stores the count of email addresses for ACH vendors based on records in the APVNFMX file. This information is used by AP256.RPG36 to generate vendor payment detail reports. Below is a detailed explanation of the process steps, business rules, tables/files used, and external programs called, as requested.

Process Steps

The AP256A.RPG program processes payment records from the APDTWS file, retrieves email information from the APVNFMX file, and writes or updates records in the APDTWSC file with the count of valid ACH email addresses for each vendor. The program is structured around a single main processing loop without explicit subroutines. The steps are as follows:

  1. Process Each Payment Record:
  2. Reads records from the primary input file APDTWS (indicator 01).
  3. For each record, constructs a key (KEY20, 20 bytes) to access the APVNFMX file:
    • Copies the company/vendor key (ADCOVN, positions 2–8) to KEY20.
    • Appends the form type 'ACHE' (ACH email) to a temporary key (KEY13) and combines it into KEY20.

  4. Sets the lower limit (SETLL) on APVNFMX using KEY20 to position the file pointer.

  5. Count Valid Email Addresses:

  6. Initializes a counter (COUNT) to zero.

  7. Reads APVNFMX records sequentially, looping until end-of-file (indicator 10) or a mismatch occurs:

    • Skips records where the company/vendor key (ADCOVN) does not match AMCOVN (from APVNFMX).
    • Skips records where the form type (AMFMTY) is not 'ACHE'.
    • Increments COUNT for each valid record (matching ADCOVN and AMFMTY = 'ACHE').
    • Continues looping (GOTO AGAIN) until all relevant records are processed or a mismatch/end is reached.

  8. Update or Add APDTWSC Record:

  9. Chains to the APDTWSC file using ADCOVN to check for an existing record (sets indicator 98 if not found).
  10. Writes or updates a record in APDTWSC:
    • If no record exists (98 on), writes a new record (DADD) with:
    • ADCOVN (company/vendor key, positions 2–8).
    • COUNT (number of valid email addresses, packed, positions 9–10).
    • If a record exists (N98), updates the existing record with the new COUNT value.

Business Rules

The program enforces the following business rules:

  1. Email Address Counting:
  2. Counts only APVNFMX records where:
    • The company/vendor key matches (ADCOVN = AMCOVN).
    • The form type is 'ACHE' (indicating ACH email notifications).

  3. The count (COUNT) represents the number of valid email addresses for the vendor, which will be used by AP256.RPG36 to determine how many reports to generate (up to four).

  4. Record Matching:

  5. Uses ADCOVN (company number + vendor number) as the key to match records between APDTWS, APVNFMX, and APDTWSC.

  6. Skips non-matching or irrelevant records in APVNFMX to ensure only ACH-related email addresses are counted.

  7. APDTWSC File Maintenance:

  8. Creates a new record in APDTWSC if no matching record exists for the company/vendor key (98 on).
  9. Updates the existing record if found (N98), overwriting the email count (COUNT).

  10. Ensures the APDTWSC file contains one record per company/vendor with the correct email address count.

  11. No Error Logging:

  12. The program does not log errors or generate output reports if records are not found or skipped; it silently continues processing.

  13. Single-Pass Processing:

  14. Processes each APDTWS record once, calculating the email count and updating APDTWSC immediately.

Tables/Files Used

The program interacts with the following files, as defined in the OCL and RPG source:

Logical Name Label Usage Disposition Record Length
APDTWS ?9?APDT?WS? Input: ACH payment data (company, vendor, invoice, amounts, check date). Input (IP) 256
APVNFMX ?9?APVNFMX Input: Vendor email/fax details (email addresses, form type). Input (IF) 266
APDTWSC ?9?APDT?WS?C Output/Update: ACH vendor control (company/vendor key, email count). Update (UF) 10

Key Fields: - APDTWS: - ADCO (company number, positions 2–3) - ADVEND (vendor number, positions 4–8) - ADCOVN (company/vendor key, positions 2–8) - APVNFMX: - AMCONO (company number, positions 2–3) - AMCVEN (vendor number, positions 4–8) - AMCOVN (company/vendor key, positions 2–8) - AMFMTY (form type, positions 9–12, must be 'ACHE') - APDTWSC: - ADCOVN (company/vendor key, positions 2–8) - COUNT (email address count, packed, positions 9–10)

External Programs Called

The AP256A.RPG program does not explicitly call any external programs. All processing is handled internally within the main loop. The program is a preprocessing step for AP256.RPG36, which relies on the APDTWSC file being populated with the correct email address counts.

Notes

  • OCL Context:
  • The OCL procedure AP256A creates the APDTWSC file with a capacity of 50 records and a record length of 10 bytes, using the BLDFILE command.
  • The RETAIN-T parameter ensures the file is temporary, and DISP-SHR allows shared access for APVNFMX.
  • Purpose:
  • The program prepares the APDTWSC file by counting valid ACH email addresses per vendor, enabling AP256.RPG36 to generate the appropriate number of payment detail reports (up to four per vendor).
  • Error Handling:
  • Skips non-matching or non-ACH records in APVNFMX without logging errors.
  • Handles missing APDTWSC records by creating new ones (DADD) when necessary.
  • Modifications:
  • No explicit modification history is noted in the provided code, but the program aligns with the AP256.RPG36 enhancements (e.g., supporting up to four email addresses, added 5-13-19).
  • Efficiency:
  • Uses SETLL and sequential reads to efficiently count email addresses, minimizing file access overhead.
  • Writes or updates APDTWSC records only once per vendor, reducing I/O operations.

This summary provides a comprehensive overview of the AP256A.RPG program's functionality, business logic, file interactions, and lack of external program calls. Let me know if you need further clarification or additional analysis!