|Check writing||- The Underlying Settings and Procedures|
Computer generated checks are issued against negative balances (credits) in designated Subledger Control Accounts. The most common of these are Accounts Payable (for purchases made) and Accounts Receivable (for refunds to customers, when necessary). Check writing requires these settings and procedures:
|1.||Establish Subledger Control Account and Inspector specifications .|
|2.||Create a Check writing Procedure to generate the applicable accounting transactions.|
|3.||Create a Print Template: launch Print Templates editor select the Template > New menu item. Since checks are printed on pre-printed forms, the fields should be laid out to fit the form design. STEP FORWARD can print checks to any pre-printed check form format.|
|This template consists of a Header to print the actual check, a Body to print the individual item lines on the check stub, and a Footer to print the check total on the check stub.|
You may want to preview the template by clicking on the Preview button
|4.||Create a Report Procedure. We have numbered the five Retrieval objects (1-5) for ease of reference.|
|I.||The Procedure starts with a Parameters box which requires an Integer "TX number" as the basis of the Search. The Variable Payee is set to NO (primed as a logical - note its use in the second "slice" to restrict the loading of the Vendor's Name and Address to a single Retrieval). The Retrieval box (1) has these Inspector settings:|
|Row processing: Multiple rows (all)|
|II.||First a Retrieval loop (2), this time from the OpenItem table to locate all the Open Items that match the TX number. The Retrieval box has these Inspector settings:|
Then, if Payee = NO, a Retrieval from the Trade Subledger table (3) to obtain the Name and Address of the Vendor followed by setting the Payee logical to YES. Thus, Payee works like a semaphore, making sure that the Vendor info is retrieved once (and only once) per every Vendor.
Row processing: Single row
And then another looping Retrieval (subservient to the previous OpenItem Retrieval) through the OpenItem table (4) to find the Payment type records belonging to the OPI match value retrieved through the first Retrieval loop. This Retrieval box has these Inspector settings:
Row processing: Multiple rows (all)
Record type = Payment
|III.||Upon processing the first Payment type record, we carry out another Retrieval from the OpenItem table (5), this time to obtain the Document Date of the Primary record which is being paid in whole or in part. This Retrieval box has these Inspector settings:|
|Row processing: Single row|
Record type != Payment
|We then determine whether the Vendor offers Discounts, and depending upon the answer, divert the path to generate a suitable Description for the Record type being processed.
Lastly, we direct the accumulated data for this record to the Checks Print object. On the first encounter with the Print object, it prints the Header and the first Body line.
|Looping back through the Procedure|
|The Procedure now loops back to the last OpenItem Retrieval in Phase II (4) to find another Payment type record for the same OPI match value. If one is found, the Procedure cycles back through the Print object in Phase III.
If no additional Payment type record is found for the same OPI match value, the Procedure steps back to the first OpenItem Retrieval of Phase II (2) and searches for another OPI match value belonging to the currently active TX number. If one is found, the Procedure goes through both Phase II and Phase III to process the new OPI match value and its associated Payment Record types.
If no additional OPI match value is found for the same TX number, the Procedure encounters the Terminator object which "stops" the Checks Print object, causing the Footer to be printed. This completes generating the Check report page (one check).
The Procedure then resets the Payee logical to NO and proceeds to retrieve another TX number (1) according to the Parameters specification. If another TX number is found, the Procedure loops through all three Phases until the next Check report page is completed.
If no additional TX number is found, the Procedure is completed and the Check report, containing all generated Check pages is saved and accessible through the Saved Reports window. Launch Run-time Run Report and select the Report > Saved reports... menu item.
|5.||Create a Print Template for the Drill Down Transaction Distribution report and Preview it:|
|6.||Create a Procedure for the Transaction Distribution report.|
|Please note that the three Parameters are the same values as those being retrieved in the first OpenItem Retrieval in Phase II of the Check's Print Procedure. This Transaction Distribution report and its Parameter requirements are mapped to the Checks Print object in the next step.|
|7.||Define the drill-down trigger in the Check's Print Procedure:|
|select the Checks Print object to display Print Fields Inspector with its Print Fields view,|
|select the field that is to trigger the drill-down report, in our example the OpenItem.[OPI match value];|
|select the Drill Down tab:|
|click on the Add button, this will display the Add Report panel:|
|select the TXDistribution report, this will show the Parameters required;|
|specify the data source for the required Parameters.|
|On completion, both views will look like this (the drill icon is not added to the Print Fields view until after the Drill Down definition is completed) :|
|8.||Test the Checks Print Procedure and select the Report preview tab. The two Reference # items are shown in red indicating that this field is defined as drill-down trigger. If you wish, click on any one of the references and the applicable Transaction Distribution report will be displayed - even in the Test mode.|
Table of Contents