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:
- Initialization:
-
The program initializes variables for processing:
- Sets
COUNTto zero (used to track the number of ACH transactions for a vendor). - Clears
KEY20andKEY13(used to build a key for accessingAPVNFMX).
- Sets
-
Main Processing Loop (Indicator 01):
-
For each record in the primary input file
APDTWS(processed with indicator01), the program performs the following:- Builds a key (
KEY20, 20 characters) for accessingAPVNFMX: - Copies the company/vendor number (
ADCOVN, positions 2-8) fromAPDTWSintoKEY20. - Sets
KEY13to'ACHE'(indicating ACH transaction type). - Combines
KEY13intoKEY20to form the full key. - Positions the file pointer in
APVNFMXusingSETLLwithKEY20to locate records matching the company/vendor and ACH type.
- Builds a key (
-
Read Vendor Master Extension (
APVNFMX): -
Enters a loop (
AGAINtag) to readAPVNFMXrecords:- Reads the next record in
APVNFMX(indicator10set on end-of-file). - If end-of-file is reached (
10set), jumps to theENDtag to exit the loop. - Compares the company/vendor number (
ADCOVNfromAPDTWS) withAMCOVNfromAPVNFMX: - If they do not match, jumps to
ENDto skip the record. - Checks if the form type (
AMFMTY) inAPVNFMXis'ACHE': - If not
'ACHE', jumps toENDto skip the record. - Increments the
COUNTvariable by 1 for each matching ACH record. - Loops back to
AGAINto read the nextAPVNFMXrecord.
- Reads the next record in
-
Update Temporary File (
APDTWSC): - Chains to
APDTWSCusingADCOVNas the key to check if a record exists for the company/vendor (indicator98set if not found). -
Writes or updates a record in
APDTWSC:- For new records (
98set, 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
COUNTvalue (binary, position 10).
- For new records (
-
Completion:
- Processes all
APDTWSrecords, updatingAPDTWSCwith ACH transaction counts for each vendor. - 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:
- ACH Transaction Counting:
- Counts the number of ACH transactions (
AMFMTY = 'ACHE') for each vendor inAPVNFMXthat matches the company/vendor number (ADCOVN) fromAPDTWS. -
Only records with
AMFMTY = 'ACHE'are counted, ensuring the program focuses on ACH-specific transactions. -
Vendor Matching:
- Matches
APDTWSrecords toAPVNFMXusing the company/vendor number (ADCOVNvs.AMCOVN). -
Skips non-matching records to ensure accurate vendor association.
-
Temporary File Updates:
- Updates
APDTWSCwith the count of ACH transactions (COUNT) for each vendor. - Creates new records if no existing record is found (
98set) or updates existing records (N98). -
Stores only the company/vendor number (
ADCOVN) and count (COUNT) inAPDTWSC, reflecting the compact 10-byte record structure. -
File Access:
APDTWSis processed sequentially as the primary input file (IP).APVNFMXis accessed randomly (IF, keyed) to retrieve vendor data.-
APDTWSCis an update file (UF, keyed), allowing both read and write operations. -
No Error Reporting:
-
The program does not generate error reports for unmatched records or invalid data, silently skipping non-matching
APVNFMXrecords or handling missingAPDTWSCrecords by creating new ones. -
Integration with A/P Process:
- Relies on
APDTWSbeing populated by prior steps in the main OCL program (AP250.ocl36.txt). - Prepares
APDTWSCfor use by the subsequentAP256program, 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:
- APDTWS (IP, 256 bytes, keyed,
DISK): - Primary input file, temporary A/P transaction file created by the main OCL program.
-
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).
-
APVNFMX (IF, 266 bytes, keyed,
DISK): - Vendor master extension file, accessed randomly for vendor data.
-
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).
-
APDTWSC (UF, 10 bytes, keyed,
DISK): - Indexed temporary file, created by the OCL program with a key in positions 2-7.
- 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
APDTWSrecords sequentially. - Matches each record to
APVNFMXusing a company/vendor key and checks for ACH form type ('ACHE'). - Counts matching ACH transactions and updates
APDTWSCwith the count for each vendor. -
Creates or updates
APDTWSCrecords 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 (
ADCOVNvs.AMCOVN). - Updates
APDTWSCwith 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!