Skip to content

BB9059 RPGLE

The RPG program BB9059 is a component of the Accounts Payable system, designed to capture a "replacing" carrier ID when creating a new carrier ID, specifically to populate the bbfx62w file with "From" and "To" carrier IDs. It is called by the BB905 program to handle this specific task. Below is a detailed explanation of the process steps, business rules, database tables used, and external programs called, based on the provided source code.

Process Steps of the RPG Program BB9059

The BB9059 program manages the entry of a replacement carrier ID through a display window (rplwdw) and validates the input before updating the bbfx62w file. It ensures the "From" carrier ID is valid and not linked to a vendor, then sends confirmation messages to specific users. Here’s a step-by-step breakdown of the process:

  1. Initialization (*inzsr Subroutine):
  2. Receive Input Parameters: The program accepts four parameters:
    • p$co: Company number.
    • p$caid: Carrier ID (the "To" carrier ID, representing the new carrier).
    • p$flag: Return code (1 for successful update, 2 for cancellation).
    • p$fgrp: File group (Z or G for database overrides).
  3. Initialize Format Fields: Copies p$co to w$co and p$caid to w$cito (the "To" carrier ID field for the display window).
  4. Set Up Variables: Initializes message handling fields (dspmsg, m@pgmq, m@key), and defines key lists:
    • kltocaid: For chaining to bbcaid with w$co and w$cito (To carrier).
    • klfrcaid: For chaining to bbcaid with w$co and w$cifr (From carrier).
    • klapveny: For checking apveny with w$co and w$cifr.

  5. Set Window Flag: Sets winagn to *on to enter the window processing loop.

  6. Open Database Tables (opntbl Subroutine):

  7. Apply File Overrides: Based on p$fgrp (Z or G), executes override commands (ovrdbf) using QCMDEXC to point to the appropriate database files (gapveny, gbbcaid, gbbfx62w or zapveny, zbbcaid, zbbfx62w).
    • Loops through three override commands (ovg or ovz) for each file.

  8. Open Files: Opens apveny (input-only for vendor data), bbcaid (input-only for carrier data), and bbfx62w (input/add for replacement data).

  9. Retrieve Data (rtvdta Subroutine):

  10. Check To Carrier ID: Chains to bbcaid using kltocaid (w$co, w$cito) to verify the "To" carrier ID.

    • If found (*in99 = *off), the program proceeds (though no specific action is taken, as w$tonm assignment is commented out).
    • If not found, no error is raised, as the "To" carrier is assumed to be new (per the program’s context).

  11. Process Window (prcwdw Subroutine):

  12. Main Loop (winagn):

    • Display Message Subfile: If dspmsg is on, writes the message subfile (wrtmsg); otherwise, clears it (msgclr).
    • Display Window: Displays the rplwdw format using exfmt, allowing the user to enter a "From" carrier ID (w$cifr).
    • Clear Messages: Clears the message subfile if displayed (clrmsg).
    • Clear Error Indicators: Resets indicators *in50 to *in69.
    • Process User Input:
    • F12 (Exit): Sets winagn to *off, sets p$flag = '2' (indicating cancellation), and iterates to exit the loop.
    • F22 (Confirm): Validates input via winedt. If no errors (*in50 = *off), updates the database via winupd, sets p$flag = '1' (success), and exits the loop.
    • Other (e.g., Enter): Validates input via winedt and redisplays the window if errors exist.

  13. Edit Window Input (winedt Subroutine):

  14. Allow Blank Entry: If the "From" carrier ID (w$cifr) is blank, no update to bbfx62w is performed, and no error is raised.
  15. Validate From Carrier ID:
    • Chains to bbcaid using klfrcaid (w$co, w$cifr).
    • If not found (*in99 = *on), clears w$frnm (From carrier name), sets error ERR0000 with message com(01) ("Invalid Carrier ID"), sets *in50 and *in51, and calls addmsg.
    • If found, moves the carrier name (cicanm) to w$frnm.

  16. Check Vendor Linkage:

    • If no prior errors (*in50 = *off), checks apveny using klapveny (w$co, w$cifr).
    • If no vendor record is found (*in99 = *on), sets error ERR0000 with message com(02) ("Code [w$cifr] is linked to a vendor for ARGLMS. Contact IT to convert."), sets *in50 and *in51, and calls addmsg.

  17. Update Database from Window Input (winupd Subroutine):

  18. Check Blank Entry: If w$cifr is blank, no update occurs, and the subroutine exits.
  19. Update bbfx62w: Clears the bbfx62wpf record, sets w1cifr (From carrier ID) to w$cifr, sets w1cito (To carrier ID) to w$cito, and writes the record to bbfx62w.

  20. Send Confirmation Messages:

    • Constructs two messages using the msg array:
    • First message: "BBFX62W Entry Created. From Carrier [w$cifr] To Carrier [w$cito].) TOUSR(JLBIT)"
    • Second message: "BBFX62W Entry Created. From Carrier [w$cifr] To Carrier [w$cito].) TOUSR(CAPO)"
    • Executes each message using QCMDEXC with a length of 120 characters, sending notifications to users JLBIT and CAPO.

  21. Message Handling:

  22. Add Message (addmsg): Sends error messages to the program message queue using QMHSNDPM with message ID, file (GSMSGF), data, and type (*DIAG).
  23. Write Message Subfile (wrtmsg): Writes the message subfile (msgctl) with indicator *in49.

  24. Clear Message Subfile (clrmsg): Clears messages using QMHRMVPM. (Saving/restoring rcdnam and pagrrn is commented out, likely unnecessary for a window-based interface.)

  25. Program Termination:

  26. Closes all files (close *all).
  27. Sets the last record indicator (*inlr) to *on and returns.

Business Rules

The program enforces the following business rules: 1. Replacement Carrier Capture: - The program captures a "From" carrier ID (w$cifr) to pair with the "To" carrier ID (w$cito) when creating a new carrier ID, storing the relationship in bbfx62w. - A blank "From" carrier ID is allowed, in which case no record is written to bbfx62w.

  1. Validation:
  2. The "From" carrier ID must exist in bbcaid for the given company (w$co). If not, an error (ERR0000, "Invalid Carrier ID") is displayed.

  3. The "From" carrier ID must not be linked to a vendor in apveny. If linked, an error (ERR0000, "Code [w$cifr] is linked to a vendor for ARGLMS. Contact IT to convert.") is displayed, preventing the update.

  4. User Notification:

  5. Upon successful creation of a bbfx62w record, two messages are sent via QCMDEXC to users JLBIT and CAPO, confirming the entry with both carrier IDs.

  6. User Interface:

  7. The window (rplwdw) allows the user to enter a "From" carrier ID and confirm with F22 or cancel with F12.
  8. F12 sets p$flag = '2', indicating the user chose not to proceed with the replacement.

  9. F22 triggers validation and, if successful, updates bbfx62w and sets p$flag = '1'.

  10. Error Handling:

  11. Errors prevent the database update and keep the window open for correction.
  12. Messages are displayed via the message subfile for user feedback.

Database Tables Used

The program interacts with the following database files: 1. apveny: Input-only file for vendor data, overridden to gapveny or zapveny based on p$fgrp. Used to check if the "From" carrier ID is linked to a vendor. 2. bbcaid: Input-only file for carrier ID data, overridden to gbbcaid or zbbcaid. Used to validate the "From" carrier ID. 3. bbfx62w: Input/add file for storing replacement carrier relationships, overridden to gbbfx62w or zbbfx62w. Updated with "From" and "To" carrier IDs. 4. bb9059d: Display file (workstation file) containing the rplwdw window format and message subfile (msgctl) for user interaction.

External Programs Called

The program calls the following external program: 1. QCMDEXC: Executes override commands (ovrdbf) for database files and sends confirmation messages to users JLBIT and CAPO.

Summary

The BB9059 program is a specialized module called by BB905 to capture a "From" carrier ID when creating a new carrier ID, storing the relationship in the bbfx62w file. It presents a window (rplwdw) for user input, validates the "From" carrier ID against bbcaid and apveny, and ensures it is valid and not linked to a vendor. Upon successful validation, it writes to bbfx62w and notifies users JLBIT and CAPO. The program supports cancellation (F12) and confirmation (F22), with business rules enforcing data integrity and user notification. File overrides ensure the correct dataset is used, and error messages guide the user through invalid inputs.