Skip to content

BB517 RPG36

The RPG program BB517.rpg36.txt is part of the invoice posting workflow in an IBM System/36 or AS/400 environment, likely called by an OCL program related to BB600P.ocl36.txt. Its primary function is to process EDI (Electronic Data Interchange) records from a temporary file (EDIOTH) and either add them to a permanent invoice header file (EDIINVH) or copy duplicate records to a duplicate invoice header file (EDIDPIH) while logging duplicates to a printer file (PRINTER). Below is a detailed explanation of the process steps, business rules, tables used, and external programs called.

Process Steps of the BB517 RPG Program

The BB517 program reads records from the EDIOTH file, checks for their existence in the EDIINVH file, and either adds new records to EDIINVH or handles duplicates by writing them to EDIDPIH and logging them to PRINTER. It operates using the RPG cycle for sequential processing.

Process Steps:

  1. File Initialization:
  2. The program opens four files:
    • EDIOTH: Secondary input file (IS), containing temporary EDI invoice header records (762 bytes per record).
    • EDIINVH: Update-capable file (UC) with an 18-byte alternate index (AI), used to store permanent EDI invoice header records (762 bytes per record).
    • EDIDPIH: Output file (O) with add capability (A), used to store duplicate EDI invoice header records (762 bytes per record).
    • PRINTER: Output file (O), a printer file (132 bytes per record) for logging duplicate records.

  3. All disk files are fixed-length (762 bytes, except PRINTER at 132 bytes).

  4. Record Processing:

  5. The program reads each record from EDIOTH sequentially using the RPG cycle (NS 01 for non-sequential input, processed as a secondary file).
  6. For each record, the program extracts the key field (EIKEY, positions 1–18), which includes:
    • EIDCTY (Document Type, positions 1–3)
    • EIINV# (Invoice Number, positions 4–10)
    • EIRECT (Record Type, positions 11–12)
    • EISEQ# (Sequence Number, positions 13–15)
    • EIKEY3 (Rest of Key, positions 16–18)

  7. The program performs a CHAIN operation on EDIINVH using EIKEY to check if a record with the same key already exists (sets indicator 99 if not found).

  8. Add New Record:

  9. If the record is not found in EDIINVH (99 is on), the program executes the ADDREC exception output (EXCPTADDREC).
  10. The OEDIINVH EADD ADDREC specification writes the entire 762-byte record to EDIINVH, split into three fields for output:
    • REC1 (positions 1–256)
    • REC2 (positions 257–512)
    • REC3 (positions 513–762)

  11. This adds the new EDI invoice header record to the permanent file.

  12. Handle Duplicate Record:

  13. If the record is found in EDIINVH (99 is off), the program executes the DUPREC exception output (EXCPTDUPREC).
  14. The OEDIDPIH EADD DUPREC specification writes the duplicate record to EDIDPIH, using the same fields (REC1, REC2, REC3) as above.
  15. The OPRINTER E DUPREC specification writes a log entry to the PRINTER file, including:
    • EIKEY (positions 1–18, output up to position 25)
    • The literal 'RECORD ALREADY EXISTS' (output at position 50)

  16. This logs the duplicate record for reporting purposes.

  17. Cycle Completion:

  18. The RPG cycle processes all records in EDIOTH until the end of the file is reached.
  19. Once all records are processed, the program terminates, closing all files.

Business Rules

  1. Duplicate Record Detection:
  2. The program checks for duplicate records in EDIINVH using the 18-byte key (EIKEY), which uniquely identifies each EDI invoice header record based on document type, invoice number, record type, sequence number, and additional key fields.

  3. If a record with the same key exists, it is considered a duplicate.

  4. Record Handling:

  5. New records (non-duplicates) are added to the permanent EDIINVH file for storage and future processing.
  6. Duplicate records are copied to the EDIDPIH file to segregate them from the main file, preserving the original data for auditing or troubleshooting.

  7. Duplicates are logged to the PRINTER file with the key and a message indicating they already exist, providing a record for review.

  8. No Data Modification:

  9. The program does not modify the content of the records; it performs a direct copy of the 762-byte record from EDIOTH to either EDIINVH or EDIDPIH.

  10. The record structure includes detailed fields (e.g., customer number, ship-to, invoice date, quantity, price), but these are not validated or altered.

  11. Purpose for EDI Processing:

  12. The program supports the EDI workflow by ensuring that temporary EDI invoice header records are either stored permanently or flagged as duplicates, maintaining data integrity for transmission to a third-party EDI service provider (e.g., Kleinschmidt, as referenced in related programs).

  13. No Error Handling:

  14. The program does not include explicit error handling for file access, key validation, or I/O errors. It assumes that EDIOTH contains valid records, EDIINVH and EDIDPIH are accessible for writing, and PRINTER can log output.

Tables (Files) Used

  1. EDIOTH:
  2. Description: Temporary EDI invoice header file.
  3. Attributes: 762 bytes per record, secondary input file (IS), disk-based.
  4. Fields Used:
    • EIKEY (18 bytes, positions 1–18): Composite key including:
    • EIDCTY (3 bytes, positions 1–3): Document Type.
    • EIINV# (7 bytes, positions 4–10): Invoice Number.
    • EIRECT (2 bytes, positions 11–12): Record Type.
    • EISEQ# (3 bytes, positions 13–15): Sequence Number.
    • EIKEY3 (3 bytes, positions 16–18): Rest of Key.
    • EICUST (6 bytes, positions 19–24): Customer Number.
    • EISHIP (3 bytes, positions 25–27): Ship-to Number.
    • EISYD8 (8 bytes, positions 28–35): System Date.
    • EIIND8 (8 bytes, positions 36–43): Invoice Date.
    • EICP08 (8 bytes, positions 44–51): Customer PO Date.
    • EICPO# (14 bytes, positions 52–65): Customer PO Number.
    • EIBOLC (3 bytes, positions 66–68): BOL Code.
    • EIBOL# (16 bytes, positions 69–84): BOL Number.
    • EINAME (60 bytes, positions 85–144): Name.
    • EIADD1 (60 bytes, positions 145–204): Address Line 1.
    • EICITY (30 bytes, positions 205–234): City.
    • EISTAT (2 bytes, positions 235–236): State.
    • EIZIPC (15 bytes, positions 237–251): Zipcode.
    • EIQTY (4 bytes, positions 252–255, packed): Quantity.
    • EIUM (3 bytes, positions 256–258): Unit of Measure.
    • EIPRCE (4 bytes, positions 259–262, packed): Price.
    • EIVPID (20 bytes, positions 263–282): Vendor Product ID.
    • EIPROD (13 bytes, positions 283–295): Product ID.
    • EIFIL1 (1 byte, position 296): Filler 1.
    • EILPRC (5 bytes, positions 297–301, packed): Line Price Total.
    • EIIDSC (86 bytes, positions 302–387): Item Description.
    • EIIAMT (5 bytes, positions 388–392, packed): Invoice Amount.
    • EIITOT (5 bytes, positions 393–397, packed): Invoice Total.
    • EIADCT (9 bytes, positions 398–406): Additional Charge Type.
    • EIADCA (5 bytes, positions 407–411, packed): Additional Charge Amount.
    • EIFIL2 (189 bytes, positions 412–600): Filler 2.
    • EISEND (128 bytes, positions 601–728): Field for Resend.
    • EIRED8 (8 bytes, positions 729–736): Resend Date.
    • EIRET8 (6 bytes, positions 737–742): Resend Time.
    • EIFIL3 (20 bytes, positions 743–762): Filler 3.
    • REC1 (256 bytes, positions 1–256): First segment of the record.
    • REC2 (256 bytes, positions 257–512): Second segment of the record.
    • REC3 (250 bytes, positions 513–762): Third segment of the record.
  5. Purpose: Contains temporary EDI invoice header data to be processed.

  6. Usage: Read sequentially to check for duplicates and copy to EDIINVH or EDIDPIH.

  7. EDIINVH:

  8. Description: Permanent EDI invoice header file.
  9. Attributes: 762 bytes per record, update-capable (UC) with an 18-byte alternate index (AI), disk-based, add capability (A).
  10. Fields Used: Same as EDIOTH (copied directly via REC1, REC2, REC3).
  11. Purpose: Stores unique EDI invoice header records for permanent storage and further processing.

  12. Usage: Checked for duplicates using EIKEY and updated with new records via ADDREC.

  13. EDIDPIH:

  14. Description: Duplicate EDI invoice header file.
  15. Attributes: 762 bytes per record, output file (O) with add capability (A), disk-based.
  16. Fields Used: Same as EDIOTH (copied directly via REC1, REC2, REC3).
  17. Purpose: Stores duplicate EDI invoice header records for auditing or troubleshooting.

  18. Usage: Receives duplicate records via DUPREC.

  19. PRINTER:

  20. Description: Printer output file for logging duplicates.
  21. Attributes: 132 bytes per record, output file (O), printer-based.
  22. Fields Used:
    • EIKEY (18 bytes, output up to position 25): Record key.
    • Literal 'RECORD ALREADY EXISTS' (output at position 50): Error message.
  23. Purpose: Logs duplicate records for reporting and review.
  24. Usage: Receives output for duplicate records via DUPREC.

External Programs Called

The BB517 RPG program does not explicitly call any external programs. It is a self-contained program that processes EDI records from EDIOTH and writes to EDIINVH, EDIDPIH, and PRINTER.

Summary

The BB517 RPG program, likely called by an OCL program in the BB600P.ocl36.txt workflow, processes temporary EDI invoice header records by: - Reading each record from EDIOTH and checking for duplicates in EDIINVH using the 18-byte key (EIKEY). - Adding new records to EDIINVH. - Copying duplicate records to EDIDPIH and logging them to PRINTER with a message. - Terminating after processing all records.

Tables Used: EDIOTH (temporary EDI input), EDIINVH (permanent EDI invoice header), EDIDPIH (duplicate EDI invoice header), PRINTER (duplicate record log). External Programs Called: None.

This program ensures that EDI invoice header data is stored permanently, with duplicates segregated and logged, supporting the EDI workflow for transmission to a third-party service like Kleinschmidt.