Skip to content

AR105 OCL

The AR105.ocl36 script is an OCL (Operation Control Language) procedure for the IBM System/36 environment, designed to handle the edit and validation of payment statement entries created by the AR050 program in the accounts receivable (AR) system. It is conditionally invoked from the main OCL script (AR050P.ocl36) when the user selects option 1 at memory location 100,1 (indicating payment statement mode). The script ensures that payment and adjustment transactions are validated before posting, producing edit reports and Notices of Difference (NODs) as needed. It incorporates an Atrium environment adaptation by replacing ?WS? with GG (per JB01 comment, 11/28/23). Below, I outline the process steps, business rules, tables (files) used, and external programs called, leveraging context from the provided documents and prior analyses.

Process Steps of the AR105 OCL Program

  1. Year 2000 Compliance:

  2. // GSY2K: Executes the GSY2K utility to ensure Year 2000 compliance for date fields in payment and adjustment transactions, preventing errors in date validation or storage (e.g., ensuring 4-digit years).

  3. Check for Input Files:

  4. // IF ?F'A,?9?CRCKGG'?/00000000 GOTO END: Checks if the check work file (?9?CRCKGG, created by AR050) contains records. If empty, skips to the END tag.

  5. // IF ?F'A,?9?CRWKGG'?/00000000 GOTO END: Checks if the invoice work file (?9?CRWKGG, also from AR050) contains records. If empty, skips to END. This ensures processing only occurs if both files have data.

  6. Delete Temporary Files:

  7. // IF DATAF1-?9?CRPSGG DELETE ?9?CRPSGG,F1: Deletes the payment statement transaction file if it exists to ensure a clean file for output.
  8. // IF DATAF1-?9?CR10GG DELETE ?9?CR10GG,F1: Deletes the sorted payment transaction file.

  9. // IF DATAF1-?9?AR11GG DELETE ?9?AR11GG,F1: Deletes the sorted adjustment transaction file. These deletions prevent stale data from prior runs.

  10. Edit Payment Statement Entries:

  11. // LOAD AR105: Loads the AR105 program to perform initial validation of payment statement entries.
  12. Defines files:
    • CRWORK,LABEL-?9?CRWKGG: Invoice work file (open invoices).
    • CRCHKS,LABEL-?9?CRCKGG: Check work file.
    • ARCONT,LABEL-?9?ARCONT,DISP-SHR: AR control file (shared).
    • ARCUST,LABEL-?9?ARCUST,DISP-SHR: Customer master file (shared).
    • ARDETL,LABEL-?9?ARDETL,DISP-SHR: AR detail file (shared).
    • CRTRAN,LABEL-?9?CRPSGG,RECORDS-999000,EXTEND-500: Output transaction file with large capacity and 500-record extension.

  13. // RUN: Executes AR105 to validate payment statements, writing validated or errored transactions to CRPSGG.

  14. Sort Payment Transactions:

  15. // LOAD #GSORT: Loads the #GSORT system utility to sort payment transactions.
  16. // FILE NAME-INPUT,LABEL-?9?CRPSGG: Input is the transaction file from AR105.
  17. // FILE NAME-OUTPUT,LABEL-?9?CR10GG,RECORDS-999000,EXTEND-999000: Output is the sorted payment file.
  18. // RUN with sort specifications:
    • HSORTA 15A 3 N: High-speed sort, ascending, 15 fields, 3 levels, no sequence checking.
    • I C 1 1NECD: Includes records where position 1 is not 'D' (excludes deleted records).
    • IAC 31 31EQCP: Includes records where position 31 is 'P' (payment transactions only).
    • FNC 7 21 CO/CUST/INV: Sorts by company/customer/invoice (positions 7-21).

  19. // END: Produces sorted file CR10GG for payment validation.

  20. Validate Sorted Payments:

  21. // IF ?F'A,?9?CR10GG'?/00000000 GOTO ADJUST: Skips to adjustment processing if no payment transactions exist.
  22. // LOAD AR110: Loads the AR110 program to validate sorted payment transactions.
  23. Defines files (mostly shared, DISP-SHR or DISP-SHRMM):
    • CR110S,LABEL-?9?CR10GG: Sorted payment transactions.
    • CRTRAN,LABEL-?9?CRPSGG: Original transaction file.
    • ARDETL,LABEL-?9?ARDETL,DISP-SHR: AR detail file.
    • ARCUST,LABEL-?9?ARCUST,DISP-SHR: Customer master file.
    • GLMAST,LABEL-?9?GLMAST,DISP-SHR: General Ledger master file.
    • ARCONT,LABEL-?9?ARCONT,DISP-SHR: AR control file.
    • GSTABL,LABEL-?9?GSTABL,DISP-SHR: General system table.
    • CRCHKS,LABEL-?9?CRCKGG,DISP-SHRMM: Check work file.
    • SA5FIND,LABEL-?9?SA5FIND,DISP-SHRMM: Sales index file.
    • SA5FINM,LABEL-?9?SA5FINM,DISP-SHRMM: Sales master file.
    • SA5SHX,LABEL-?9?SA5SHX,DISP-SHRMM: Sales index file.
    • XGSTABL,LABEL-?9?GSTABL,DISP-SHRMM: System table alias.
    • Printer files: NODLIST and NODPRINT for edit and NOD reports.
  24. Printer overrides:
    • // IF ?9?/G OVRPRTF FILE(PRINT) OUTQ(QUSRSYS/AREDIT): Uses AREDIT queue if ?9? is G.
    • // IFF ?9?/G OVRPRTF FILE(PRINT) OUTQ(QUSRSYS/TESTOUTQ): Uses TESTOUTQ otherwise.

  25. // RUN: Executes AR110 to validate payments, flag errors, and produce NOD reports for discrepancies.

  26. Sort Adjustment Transactions:

  27. // TAG ADJUST: Marks the adjustment processing section.
  28. // LOAD #GSORT: Loads #GSORT for sorting adjustment transactions.
  29. // FILE NAME-INPUT,LABEL-?9?CRPSGG: Input is the transaction file.
  30. // FILE NAME-OUTPUT,LABEL-?9?AR11GG,RECORDS-999000,EXTEND-999000: Output is the sorted adjustment file.
  31. // RUN with sort specifications:
    • HSORTA 15A 3 N: Ascending sort, 15 fields, 3 levels, no sequence checking.
    • I C 1 1NECD: Excludes deleted records.
    • IAC 31 31EQCJ: Includes records where position 31 is 'J' (adjustment transactions, though disabled in AR050 per March 2024 note).
    • FNC 7 21 CO/CUST/INV: Sorts by company/customer/invoice.

  32. // END: Produces sorted file AR11GG.

  33. Validate Sorted Adjustments:

  34. // IF ?F'A,?9?AR11GG'?/00000000 GOTO END: Skips to END if no adjustment transactions exist.
  35. // LOAD AR111: Loads the AR111 program to validate adjustments.
  36. Defines files (all shared):
    • AR111S,LABEL-?9?AR11GG: Sorted adjustment transactions.
    • ARTRAN,LABEL-?9?CRPSGG: Original transaction file.
    • ARDETL,LABEL-?9?ARDETL,DISP-SHR: AR detail file.
    • ARCUST,LABEL-?9?ARCUST,DISP-SHR: Customer master file.
    • GLMAST,LABEL-?9?GLMAST,DISP-SHR: General Ledger master file.
    • ARCONT,LABEL-?9?ARCONT,DISP-SHR: AR control file.
    • GSTABL,LABEL-?9?GSTABL,DISP-SHR: General system table.

  37. // RUN: Executes AR111 to validate adjustments and update CRPSGG.

  38. Cleanup and Termination:

  39. // TAG END: Marks the end of processing.
  40. // SWITCH 0XXXXXXX: Resets the first bit of the switch register to 0, leaving others unchanged, to restore system state.
  41. // IF DATAF1-?9?CR10GG DELETE ?9?CR10GG,F1: Deletes the sorted payment file.
  42. // IF DATAF1-?9?AR11GG DELETE ?9?AR11GG,F1: Deletes the sorted adjustment file.

Business Rules

  1. Conditional Execution:
  2. Only runs if both CRCKGG (checks) and CRWKGG (invoices) contain records, ensuring valid input from AR050.

  3. Invoked from AR050P.ocl36 when option 1 is selected (payment statement mode).

  4. Atrium Compatibility:

  5. Uses GG suffix for files (CRWKGG, CRCKGG, CRPSGG, CR10GG, AR11GG) per JB01 (11/28/23) to align with the Atrium environment, avoiding file conflicts.

  6. Data Integrity and Cleanup:

  7. Deletes temporary files (CRPSGG, CR10GG, AR11GG) before processing to prevent stale data.
  8. Deletes sorted files after processing to free disk space.

  9. Sorts payments and adjustments separately, including only non-deleted records (atdel <> 'D') and specific transaction types ('P' for payments, 'J' for adjustments).

  10. Transaction Types:

  11. Processes payments (ATTYPE = 'P') and adjustments (ATTYPE = 'J'), though adjustments are disabled in AR050 (per March 2024 note in AR050.rpgle).

  12. Sorts by company/customer/invoice to organize validation and reporting.

  13. File Sharing:

  14. Uses DISP-SHR or DISP-SHRMM for master files (ARCUST, ARDETL, GLMAST, ARCONT, GSTABL) and sales files, supporting multi-user access.

  15. CRTRAN (CRPSGG) has a large capacity (999,000 records, extendable by 500) to handle high volumes.

  16. Y2K Compliance:

  17. GSY2K ensures date fields (e.g., payment dates) are processed correctly.

  18. Printer Output:

  19. AR110 generates edit and NOD reports (NODLIST, NODPRINT) with conditional queue overrides (AREDIT or TESTOUTQ) based on ?9?.

Tables (Files) Used

  1. ?9?CRWKGG (aliased as CRWORK):
  2. Type: Input work file (invoices from AR050).

  3. Usage: Provides open invoice data for validation.

  4. ?9?CRCKGG (aliased as CRCHKS):

  5. Type: Input work file (checks from AR050).

  6. Usage: Provides check data.

  7. ?9?CRPSGG (aliased as CRTRAN, ARTRAN):

  8. Type: Output transaction file.
  9. Record Capacity: 999,000, extendable by 500.

  10. Usage: Stores validated payment/adjustment transactions.

  11. ?9?CR10GG (aliased as CR110S):

  12. Type: Sorted payment transaction file.
  13. Record Capacity: 999,000, extendable by 999,000.

  14. Usage: Input for AR110 validation.

  15. ?9?AR11GG (aliased as AR111S):

  16. Type: Sorted adjustment transaction file.
  17. Record Capacity: 999,000, extendable by 999,000.

  18. Usage: Input for AR111 validation.

  19. ?9?ARCONT (aliased as ARCONT):

  20. Type: AR control file (shared).

  21. Usage: Provides defaults (e.g., GL accounts).

  22. ?9?ARCUST (aliased as ARCUST):

  23. Type: Customer master file (shared).

  24. Usage: Validates customer data.

  25. ?9?ARDETL (aliased as ARDETL):

  26. Type: AR detail file (shared).

  27. Usage: Validates invoice details.

  28. ?9?GLMAST (aliased as GLMAST):

  29. Type: General Ledger master file (shared).

  30. Usage: Validates GL accounts.

  31. ?9?GSTABL (aliased as GSTABL, XGSTABL):

    • Type: General system table (shared).
    • Usage: Configuration data.

  32. ?9?SA5FIND (aliased as SA5FIND):

    • Type: Sales index file (shared, multiple members).
    • Usage: Sales data lookup.

  33. ?9?SA5FINM (aliased as SA5FINM):

    • Type: Sales master file (shared, multiple members).
    • Usage: Sales transaction details.

  34. ?9?SA5SHX (aliased as SA5SHX):

    • Type: Sales index file (shared, multiple members).
    • Usage: Additional sales indexing.

External Programs Called

  1. GSY2K:
  2. System utility for Y2K date compliance.

  3. Purpose: Ensures correct date handling.

  4. #GSORT:

  5. System utility for sorting transactions into CR10GG (payments) and AR11GG (adjustments).

  6. Purpose: Organizes transactions for validation.

  7. AR105:

  8. RPG program for initial payment statement validation.

  9. Purpose: Validates CRWKGG and CRCKGG, writes to CRPSGG.

  10. AR110:

  11. RPG program for validating sorted payment transactions.

  12. Purpose: Validates CR10GG, updates CRPSGG, produces NOD reports.

  13. AR111:

  14. RPG program for validating sorted adjustment transactions.

  15. Purpose: Validates AR11GG, updates CRPSGG.

  16. AR1101 (implied by OCL):

  17. Called by AR110 for additional processing (e.g., posting or reporting).
  18. Purpose: Likely handles GL updates or detailed reporting (uses NODPRINT).

Summary

The AR105.ocl36 script orchestrates the validation of payment statement entries from AR050 by: - Ensuring Y2K compliance and checking input files (CRWKGG, CRCKGG). - Running AR105 for initial validation, sorting payments (AR110) and adjustments (AR111) separately. - Validating against master files (ARCUST, ARDETL, GLMAST, ARCONT) and producing NOD reports. - Cleaning up temporary files and resetting switches. - Supporting Atrium with GG suffixes and multi-user access via shared files.

It enforces strict data integrity, processes payments and (disabled) adjustments separately, and prepares validated transactions for further processing (e.g., posting via AR1101).