AP Bill Payer
Functional Design and Specification
Page i
AP Bill Bayer
Functional Design
Document Version:
Date:
29 July 2017
Prepared By:
For:
Error! Reference source not found.
Mary McKeel
Internal development (Product)
© 2017 ASA Tire Systems
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design and Specification
Page ii
Revision History
Title :
Functional Design
Project:
Accounts Payable
Document :
AP Print Checks Functional Design and Specifications.docx
Version :
Error! Reference source not found.
Date :
29 July 2017
Changes :
Change History :
Version
Date
By
Summary
1.0
1.1
09/02/2014
09/23/2014
M McKeel
M. McKeel
First Draft
Added Void/Reprint
1.2
09/26/2014
M McKeel
1.3
10/22/14
M McKeel
Change to print one batch
at a time with connection to
g-bank for a company
Added detail to Alignment
check
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design and Specification
Page iii
Table of Contents
1
Introduction ..............................................................................................................5
1.1
Scope ............................................................................................................5
1.2
Security / Roles ............................................................................................5
1.3
Glossary .......................................................................................................5
1.4
References ....................................................................................................5
1.4.1 AP Data Structure Functional Design - BZ 2368 ............................5
1.5
Application Definitions ................................................................................5
1.5.1 Table “application” ..........................................................................5
1.5.2 descriptionUid ..................................................................................5
1.5.3 Type .................................................................................................6
1.5.4 accessUrl ..........................................................................................6
1.5.5 primaryEntity ...................................................................................6
1.5.6 allowConcurrent ...............................................................................6
1.5.7 Parking Definition Line 1 ................................................................6
1.5.8 Parking Definition Line 2 ................................................................6
1.5.9 Hover Help .......................................................................................6
1.5.10
Universal and Other Searches ..............................................6
1.5.11
“Complete” Button Definition .............................................6
2
Process Context........................................................................................................6
2.1
Data Flow Diagram ......................................................................................6
2.2
System Description ......................................................................................7
2.2.1 Tiremaster Enterprise (TME) ...........................................................7
2.2.2 Interactions with other external systems ..........................................7
3
Database Tables .......................................................................................................7
3.1
Introduction ..................................................................................................7
3.2
Batch and Transaction Tables ......................................................................7
3.2.1 apBatch – AP check writing batch control ......................................8
3.2.2 apTransCDCheck - actual check record .........................................8
3.2.3 apTransCDInvoice – remittance advice(invoice detail) ..................8
3.3
Forms tables for AP Checks ........................................................................9
3.3.1 formAPCheck – Check summary ....................................................9
3.3.2 formAPRemit – check remittance detail ..........................................9
3.3.3 printJob – printer and form info .......................................................9
3.3.4 payEFTReference – Reference # for electronic transactions ...........9
3.3.5 Changes to existing tables – add Uids .............................................9
3.4
AP Vendor Tables ......................................................................................10
3.4.1 apVendor (revised a-vend).............................................................10
3.4.2 apVendorMisc - AP Miscellaneous Vendor .................................10
3.4.3 apVendorCustNum – Vendor’s customer account list...................10
4
Work Flow .............................................................................................................11
4.1
Use Case 1 – Print Checks .........................................................................11
4.2
Use Case 2 - Send ACH/Credit Card payments........................................11
5
Process Model ........................................................................................................11
5.1
System Transactional Relationships ..........................................................11
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design and Specification
5.1.1
5.1.2
5.1.3
6
Page iv
AP Invoice Release ........................................................................12
AP Bill Payer .................................................................................13
AP Bill Payer Update .....................................................................14
Detailed Module Descriptions ...............................................................................15
6.1
System Set up and Assumptions ................................................................15
6.2
General Requirements ................................................................................15
6.3
AP Bill Payer .............................................................................................15
6.3.1 Batch Entry and Review ................................................................15
6.3.2 Initial States On Open of Application ............................................15
6.3.3 Populating the Batch Browse .........................................................16
6.3.4 AP Bill Payer Selection criteria .....................................................17
6.3.5 Payment Type: ...............................................................................18
6.3.6 Select the printer, form to be used, and payment type ...................19
6.3.7 AP Payment Batch Set ...................................................................20
6.3.8
Print Alignment Check
.........................23
6.3.9 Print Checks
......................................................23
6.3.10
Complete ............................................................................33
6.3.11
Reset – We will not allow this if we have actually printed
checks
33
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-5
1 Introduction
Some vendors require an actual check to be printed. These may be pre-printed forms or they could be
blank paper where the combination of software and special hardware print the whole check including
MICR encoding.
The check writing system will use 2 new transaction tables to hold check writing records. This is a
temporary table and will be deleted once checks have been printed.
1.1
Scope
Although payments can take the form of a check, ACH or Credit Card payment, this document describes
the functional design of printing hard copy check forms only. Enhancements for sending outgoing ACH
or credit card payments are separate APIs and will be outside of this program.
1.2
Security / Roles
The procedure supports 2 basic types of users in increasing order (each includes features of lower level
users and all is controlled by password):
1. AP Back Office User - all functionality except some maintenance.
2. Accounts Payable Administrator – allows maintenance to records that should not be touched without a
GL entry.
1.3
Glossary
Browse – a list view of data, typically with a scroll bar on the right to navigate through the list. Browses
can be read-only or updateable.
Remittance – Listing of all invoices and credits that make up the individual check.
PayClix – a 3rd party on line payment system including an end user UI and the requests/response web
service calls that allows data integration for remote payments and ACH transactions.
1.4
References
1.4.1 AP Data Structure Functional Design - BZ 2368
1.5
Application Definitions
1.5.1 Table “application”
“Bill Payer”
1.5.2 descriptionUid
apPrintChecksUid
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
1.5.3 Type
1:Runnable with UI
Page-6
1.5.4 accessUrl
A URL to directly access the application. An application context can be passed as a parameter to recreate
uncommitted application state.
1.5.5 primaryEntity
apBatch
1.5.6 allowConcurrent
FALSE
1.5.7 Parking Definition Line 1
Bill Payer
1.5.8 Parking Definition Line 2
This definition should consist of the batch chosen for printing
Table.Field
Label
Pay Type for Run
Starting CHk#
Ending Check#
1.5.9 Hover Help
No hover help is required in this application
1.5.10 Universal and Other Searches
There are no universal searches required for this application
1.5.11 “Complete” Button Definition
Today, the “Complete” button will do nothing but close the application. In the future, we may decide to
incorporate the Bill Pay Update here.
2 Process Context
2.1
Data Flow Diagram
The Bill Payer with a PayClix interface, impacts data flow of the system in the following ways:
 User can print checks for vendors who must receive hard copies via snail mail
 User can make payments via PayClix for ACH payments
 User can make payments by credit card through Merchants or Pay Clix.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-7
TME
User
Accounts
Payable
AP Checks
Bank
PayClix
Web
Service
Powerflow
Positive Pay
System Context
2.2
System Description
2.2.1 Tiremaster Enterprise (TME)
TME is ASA’s accounting system software that allows the user to select invoices for payment manually.
2.2.2 Interactions with other external systems
There are no changes identified for the following external systems:



Credit card interface
Etirelink
EDI interfaces
3 Database Tables
3.1
Introduction
The following tables will be updated during the AP Print Check process.
3.2
Batch and Transaction Tables
The tables referenced below can be found attached to BZ 2368 – AP Data Structure Functional Design.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
3.2.1 apBatch – AP check writing batch control
Page-8
This table is used for controlling batch input of AP invoices.
Field
apBatchUid
batchUid
Type
Character
Character
Format
X(36)
X(5)
Label
Unique ID
Batch Loc
journalCode
invoiceCount
Character
Integer
X(3)
9999999
Journal
Invoice Count
checkCount
Integer
9999999
Check Count
APInvoiceTot
Dec
AP Total
discountAmt
Dec
bankTotal
Dec
999,999,999.99
999,999,999.99
999,999,999.99
-
Initial
Disc taken
Check Total
Help/Description
System Assign Unique ID
Batch UID used to group
transactions
Journal source CDJ”
Number of invoices
entered/paid
Number of Checks
Written
Total Invoice amt to/From
AP
Total Discount taken
during check writing
Total Check amount
apBatchUID Description: A unique record id that is used to tie all of the entries for 1 batch together.
This will allow reports to be reprinted after posting.
batchUID Description: Unique Id of the Batch control
journalCode Description: Journal code used when posting to the GL and to identify an entry for invoice
entry vs check writing.
invoiceCount Description: Number of invoices entered during PJ entry or paid during check writing
checkCount Description: Number of “checks” or single payments(ACH) created
APInvoiceTotal Description: Total invoice amount CR/DR to AP Control
discountAmt Description: Total cash discount taken during check writing
bankTotal Description: Total check amount written
Index Name
Key-uid
Key-upd
3.2.2








Area
Description
Unique id
Update key
Flags
PAUW,Ab
PU
U
Fields to be included
apbatchUid
batchUid
A/D
A
A
apTransCDCheck - actual check record
One record per check written.
Total Due, Total Discount and checkAmt are the totals of the invoice detail
Records are created during the release invoices for payment
The records in this table do not get deleted after the update. They remain for history audit until
purged.
Check numbers are assigned after checks are printed/sent electonically for payment
PayType is used to identify the kind of payment.
Void check records are added to this table prior to a reprint.
The company in this record could be different than the companies in the detail
3.2.3 apTransCDInvoice – remittance advice(invoice detail)
 One record per invoice on the remittance advice
 The records in this table do not get deleted after the update. They remain for history audit until
purged.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-9
 The number of records in this table dictate whether a separate remittance advice is needed.
 These records could be mixed companies
3.3
Forms tables for AP Checks
The data to be printed on the check is contained in the forms tables so the program rendering the print
data (BIRT) does not have to look up data in other tables. Checks are represented in the database by 2
tables; 1)a check table that holds the information about the check and/or payment if credit card or ACH
2) the remittance advice which is the invoice detail paid by this check.
A special printJob table has been created to pass the form and printer ids to BIRT.
3.3.1 formAPCheck – Check summary
 Records are added to this table when the “Print Check” button is selected
 One record per check number
 Data fully populated
3.3.2 formAPRemit – check remittance detail
 Records are added to this table when the “Print Check” button is selected.
 One record per invoice on the remittance, multiple records per check
 May be counted to determine if a separate remittance advice is needed
3.3.3 printJob – printer and form info
 A record is added to this table when the “Print Check” button is selected
 One record per print job sent to BIRT
3.3.4 payEFTReference – Reference # for electronic transactions
When making an ACH or credit card payment, a transaction id must be sent along with the payment.
This id will be used by both the sending and receiving parties to trace a transaction if necessary. The id
must be system wide meaning one set of numbers for a database instance. Even if the system has
multiple companies and locations we need a unique number for traceability. Normally a db sequence
number could be used for this. However, since we are trying to be database independent, a regular table
for this purpose will be used. This reference will be used like a “check Number” in that it will be
assigned to the transactions during the “PrintCheck” routine and updated by one automatically each time
a number is used.
3.3.5 Changes to existing tables – add Uids
3.3.5.1 S-form
This table contains the form definitions that will tell BIRT which form to use for the print check format.
sformUid has been added to this table. This is a Tirepro table and will be used as is for now.
3.3.5.2 S-printer
This table contains the printer definitions for all printers on the networks. It will be passed to BIRT for
printing directly to the printer without stopping for user intervention. sprinterUid has been added to this
table. This is a Tirepro table and will be used as is for now.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
3.3.5.3 Password
Page-10
There are no changes to the password table. The default form# and printer designation are in the
password table. The field for the AP Check printer default is password.printer[6]. The field for the AP
Check form is password.form#[6]. This default will be moved to the paymentType table in Phase 2
when the final printing methodology is complete.
3.4
AP Vendor Tables
The system uses standard and miscellaneous vendors. All Universal Vendor search components will
need to search both types. Additionally, there is now an affordance to create a parent/child relationship
between a vendor and a customer. This information will be used to populate the form* tables.
The tables referenced below can be found attached to BZ 2368 – AP Data Structure Functional Design.
3.4.1
apVendor (revised a-vend)
This table holds all of the necessary information for a regular vendor.
The table referenced can be found attached to BZ 2368 – AP Data Structure Functional Design
3.4.2
apVendorMisc - AP Miscellaneous Vendor
A new table is added for miscellaneous vendors. A flag has been added to the invoice and check
records to tell the system it is a miscellaneous vendor’s invoice/check. 95% of the time, there is only 1
invoice in the system for a miscellaneous vendor. Retreader’s casing purchases do use the same misc
vendor more often. Maybe 10 – 20 % of the time.
A name search –for miscellaneous vendors - will use the new table and will display in the AP Invoice
Release and Vendor Account Inquiry. We will be able to reuse the name in case the misc vendor isn’t
exactly as miscellaneous as it should be. . This is different than how Tirepro views a miscellaneous
vendor.
All other vendor information will come from the regular apVendor record attached to this table via the
VendorNum field. That includes the 1099 box id default.
A new password “AllowMiscVendors” yes/no will be added. If FALSE, a user will not be allowed to
enter a miscellaneous vendor during AP Invoice Release.
The table referenced can be found attached to BZ 2368 – AP Data Structure Functional Design.
3.4.3 apVendorCustNum – Vendor’s customer account list
This table will hold the customer numbers with the vendor account. Many vendors have separate
accounts for each location. This table will allow us to have 1 vendor record with multiple customer
numbers. At least 1 record for each vendor will be created.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-11
4 Work Flow
4.1
Use Case 1 – Print Checks
A list of batches that have release invoices is displayed.
The user can select one or more batches for check printing.
The pay types must be printed one at a time because different banks could have different check formats.
This means different paper in the printer. This could mean selecting a batch more than once for printing.
4.2
Use Case 2 - Send ACH/Credit Card payments
Sending the actual ACH payment or credit card payment will be done through a third party vendor. It
will be added to this spec in a later pahse.
5 Process Model
5.1
System Transactional Relationships
The following is a representation of the entire Bill Pay process from release invoices for payment,
printing checks, sending ACH payments and updating the information into permanent tables.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
5.1.1 AP Invoice Release
Page-12
Batch
apBatch
batchLoc
batchid
batchDate
batchUid
apBatchUid
apinvoice
isRelease = Yes
apTransCDInvoice
apTransCDCheckUid
Location
invoiceNum
futureCode
As invoices are selected for
payment from apInvoice,
apTransCDInvoice detail is
created. At the same time,
apTransCDCheck is created
and updated. This record
contains the total payment to
be made to the vendor.
The invoices may cross
company boundaries making
intercompany accounting
mandatory.
Checks are printed and or
electronic payments are made
from the apTransCDCheck
record.
apTransCDCheck
(summary of released invoices)
batchLoc
batchid
batchDate
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
5.1.2 AP Bill Payer
Page-13
Batch
apBatch
batchLoc
batchid
batchDate
batchUid
apBatchUid
apTransCDCheck
(summary of released invoices)
apBatchUid
apTransCDInvoice
apTransCDCheckUid
Location
invoiceNum
futureCode
formAPCheck
(copy of apTransCd )
printJobUid
fromAPRemit
formAPCheckUid
Location
invoiceNum
futureCode
PRINT Checks
Assign check #s
E Ref #s
If Print
printJob
printjobUid
batchUid, printUid
formUid
EXIT
REPRINT
OK
Done Print Checks
Get next PayType
Printed
Checks
Yes
Reprint
and
VOID?
No
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
5.1.3 AP Bill Payer Update
Batch
apBatch
batchLoc
batchid
batchDate
bztchUid
apBatchUid
Page-14
apTransCDInvoice
apTransInvHeadUId
apTransCDCheck
apBatchUid
apTransCdGL**
apTransCdGLUId
Intercompany Process
Disc and AP Control
apCheck
batch loc,id,date
vendorNum
checkNum
Company
paymentType
.vendorNum
NE “”
Yes
apPurchases
No
To Bank
apCheckInvoice
apCheckUid
Company
Location
invoiceNum
futureCode
apInvoice
apInvoiceGlDist
if paid by
another vendor.
Include
getInterCoEntry
vendorNum
GL Period
Disc Taken
Payments
Checkcount
(if real check)
g-prepst
vendorNum
Location
invoiceNum
batchloc
batchid
batchdate
If new
apInvoice
update
Purchases and
InvoiceCount
apInvoice
AP Control entries
are made based on
the invoice location.
Possible multiple
Intercompany
entries are made if
the bank is in a
different location
than the invoices
being paid.
**apTransCdGL is not part of this phase. It was to hold write offs made during the release invoices for
payment.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-15
6 Detailed Module Descriptions
6.1
System Set up and Assumptions
ATTRIBUTE SETTINGS:
TABLE SETTINGS:
Password Setting
Location Settings
Third Party Info
Other Table Settings (inventory, customer, etc)
OTHER SET UPS:
Menu definitions
Report Meta Data
6.2
General Requirements









6.3
Ability to quickly select vendors for check printing
Ability to reprint checks for any reason.
Ability to Void Checks that need to be reprinted. Only checks that were actually destroyed or
printed in error are voided.
This application is password controlled – meaning a user can either do the function or not.
Ability to see the Check List in Summary after the checks are printed.
Ability to print and reprint as many time as needed. “Complete” will finish the process.
Ability to Park a partially completed entry.
Ability to Send to another User.
Ability to Email to another User.
AP Bill Payer
6.3.1 Batch Entry and Review
There is no batch entry or review for this process. All apTrandCd* records will be available whether
printed or not.
6.3.2 Initial States On Open of Application
When the application is first opened, the main application area will display the Batch Browse based on
the users password/locations allowed.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-16
There is no “batch” that controls this application. It is looking at many batches already in existence in
order to make payments/print checks. At this point, the user selects a batch for printing. The print will
be done for one batch at a time.
The user needs to choose between Print Checks or Electronic Funds Transfer (EFT). If EFT, no other
filter criteria is needed except for the Pay Type.
The Filter Criteria is to be moved to the left of the main window where all other criteria is. It is
additional info used for selecting the checks to be printed once the batch(s) is selected:
Select the Pay Type to be printed. It should default to blank. – Mandatory Entry
Select the printer and the check form to be printed
Toggle negative checks on/off. Off is the default
Enter the starting/ending check numbers - Mandatory
Enter the check date (default to TODAY”)
Select the sort option
If this is a rerun, enter the “Starting/ending check numbers.
Once the Apply Filter is selected, the user may deselect/select the Payment records to be taken into
consideration for check printing. The user can click on the batch to see all of the “checks” that are to be
considered for the pay type. . The user can click on a vendor to see the invoices that are being paid but
cannot change or select/deselect the invoice records.
The Print Alignment Check and Print Checks button will be used to print the actual checks on a form.
The “Print Check” Button will also be used to assign EFT Reference ids to payments and designate them
as electronic payments. This will tell the update process they are ready to go. Can we change the name
of this button to “EFT Reference” if the PaymentType.isCheck <> TRUE?
UNDO, Reset and Complete are disabled.
6.3.3 Populating the Batch Browse
TABLE
batch
batch
batch
batch
apBatch
Join Criteria
batchModule = “AP”
moduleProcess = “Release Invoices”
batchLoc = [user allowed locs]
userLoginID = [current user or ALL if
password allows]
Operator
Comment
AND
AND
AND
AND
batchUid = batch.batchUid
Most of the time the user who released the checks will be the one who prints the checks and they will
only want to see their batches. However, some companies only have 1 person who is allowed to actually
print the checks so the userLoginId is critical for this.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-17
Table.Field
Type
Format
Label
batch.batchloc
batch.batchID
batch.batchDate
batch.userLoginId
Toggle
Character
character
Date
char
ON/OFF
x(5)
x(8)
mm/dd/yyyy
x(15)
Select
Batch Loc
Batch ID
Batch date
User Id.
apBatch.invoiceCount
apBatch.apInvioceTot
apBatch.discountAmt
apBatch.bankTotal
integer
decimal
decimal
decimal
9,999,999
999,999,999.99999,999,999.99999,999,999.99-
# Invoices
Total Amount
Total Discount
Payment
6.3.4
Description
Shows the batch has this pay type
in it and is selected for printing
Location from master Batch
BatchID from master batch
Batch Date from Master Batch
identifies whose batch it is
Total # of invoices being paid in the
batch
Total Gross invoice amount in batch
Total discount taken in batch
Total Amount of Payments
AP Bill Payer Selection criteria
The user must select one of the following options. EFT will be completed in a later Phase. It will be
used for ACH and Credit card payments.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-18
 Print Checks
 Electronic Funds Transaction (EFT) (option will be added later. It requires no other filter)
6.3.5 Payment Type:
Select the payment type that is to be compared to the data for selecting records. Once the Pay Type
has been selected, apbatches and their apTransCDCheck records will be automatically selected
where that PayType is included. We can only print one pay type at a time because different banks
and bank accounts may require different check form stock. The user may need to run this procedure
several times to get all of the checks printed. For example, they would select a payment type, enter
the filter criteria, Choose Print Checks. When check printing is done, reload the printer with
different check forms, select the Pay Type, enter the filter criteria, Choose print Checks. They may
need to change the Printer and/or form# in between as well – but probably not in most cases. Once
they have printed all of the checks, they would choose complete and the system will update the
apTransCDCheck with the proper check numbers. If reruns were done, the void checks would
already be in that table.
Display payment types in this combo.
TABLE
batch
location
file-assoc
Operator
Join Criteria
batch.batchUid = apBatch.batchUid
location.loc = batch.batchloc
file-assoc.a-assoc = location.co
AND
g-bank
gb-co = file-assoc.a-assoc
gb-bank = paymentType.gb-bank
paymentType
paymentType
gb-bank is in the list of g-banks available to
the batch’s company
PayModule = “APP”
The user selected “Print Checks”
isCheck = TRUE
The user selected “EFT”
isCheck = FALSE
isACH or isCredit or isDebit = TRUE
Comment
Get a list of all g-banks
available for this batch
locations company
AND
AND
AND
OR
AND
AND
AP payment types only
Checks only
Show all electronic pay types
Populate the combo with the following data. Fixed length columns would make it easier for the user
to find the correct selection
Table
paymentType
paymentType
paymentType
7/29/2017
Field
PayType
gb-bank
Descr
Format
x(8)
x(2)
x(20)
Comment
Payment Type
Bank ID – FYI only
Description
TME
Version 1.0
AP Bill Payer
Functional Design
If an EFT Pay Type was chosen, skip to section 6.3.7
Page-19
6.3.6 Select the printer, form to be used, and payment type
Without seeing what Gikas and Dmitry are working on for printer and forms selection, this part of the
spec is pure TME. We need the exact same functionality in G4. It does not have to look the same. The
printer and form definitions do not have to be the same. But, bottom line when the user needs to print
anything in the system, it should follow the exact same functionality as described below.
Printer Name:
Select the printer. The printers that are available to the user are in password.allprt. The combo box
should be populated with that list only. If that list is blank, the combo is populated with all printers in sprinter where s-printer.sp-name does not begin with a “!”. The “!” records are used for creating new
printer records only using the copy function in the Tirepro maintenance. They are never used for actual
printing.
The default for printing AP Checks is found in password.printer[6]. If for some reason the default
printer is not in the password.allprint list, it must be added to the printer selections in the combo box. It
will be selected by default.
Form Number:
Select the form to be used. There could be many different AP Check forms in the system. Today, we
don’t list just the application’s forms. We list all forms in the combo box that are in the table s-form.
Our new forms design must include the application module where the form should be listed so the
combo list does not include superfluous forms for the app.
The current s-form table contains information that is now controlled by BIRT. However, there is a Print
Program name (s-form.sf-printprg), an XSL Template path and name (s-form.sf-template), a Crystal
Reports template (s-form.sf-crystaltemplate) and the number of copies to print (s-from.sf-copies).
All/any of these fields could be used to point to the [form].rptdesign that Marianne is building for the
checks. We can still display the form# and description in the window. She is using the form# in her
from design name. For example: formCheck215.rptdesign and formRemit215.rptDesign are both BIRT
layouts used in forms printing. They will be mentioned in the spec below. The user, for example, just
needs to be able to pick 215 OR AP Standard Check- 1 stub, 315 OR AP Standard Check-2 stubs, 415
OR ABC Tire Custom Check. By selecting the correct form option the software needs to be smart
enough to pass enough information to BIRT so it knows which *.rptdesign to use. The data will always
be the same. The form design will use what it needs out of it.
The default form for printing AP Checks is found in password.form#[6]. This will be moved to the
paymentType table once the final printing methodology is determined. Meanwhile we will use the
existing method of find the default form. If it is not in the s-form table, an error should be displayed that
the form does not exist in the system and force the user to change it to a proper form. This will only
happen when we initially set up the system. It will not be a common error. All AP Check forms should
be listed in the combo box with the default form# highlighted and selected.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
6.3.6.1 Print Checks Filter Criteria
Page-20
The check print program will create records in the formAP* table to be used by BIRT for printing. This
takes all of the business logic out of the report rendering tool and puts it in the calling program. Every
check print or reprint follows the chart below showing the fields on the Filter Criteria. The filter criteria
will be used for creating the formAP* records to be printed as well as how the checks should be sorted,
printed, reprinted or voided.
Filter
Id
Sort By:
Print $0 or Negative Checks?
Table.Field or
Description
 Vendor Number
o Vendor Name
Toggle Box
Beginning Check #
g-bank.gb-chk#
Label
1
2
3
Type
Format
Radio
logical
yes/no
integer
>>>>>9
integer
date
>>>>>9
99/99/99
4
5
Ending Check #
Date of Checks
Description
The checks will print in this
order
Default to toggle off
This will be from the bank id
in the select pay type.
Ending number cannot be
more than the beginning
Check date default to TODAY
The main application area will not become active until the user has hit Apply Filter.
If there are no released invoices for a vendor with Pay Types = to the applied filter criteria, the user will get a
message: “There are no Pay Types for your search. Please try again.”
These selections can be run many times before “Complete” is chosen.
6.3.7
AP Payment Batch Set
Clicking on the “Apply Filter” button will automatically select the Payment records for the batch chosen in the
“Batch Browse” that have paytypes matching the payType selected. It will activate all rows in the Batch
Browse so they can be queried but the system will not allow the user to deselect the batch chosen at the
beginning. It will also look at the “print $0 or Negative toggle”. Select those payments and their detail as
follows:
TABLE/origin
Selection Criteria
Operator
AND
apTrandCdCheck.PayType
Filter ID = 2
apTrandCdCheck.checkamt
payType = PayType selected in
combo
Print $0/Negative = TRUE
<= 0
7/29/2017
TME
AND
OR
Comment
Just select chosen pay types
If toggle is on
select $0 or negative checks
Version 1.0
AP Bill Payer
Functional Design
Page-21
Filter ID = 2
Print $0/Negative = FALSE
apTrandCdCheck.checkamt
>0
AND
If any records in your batch
apTransCdCheck.checkNum have checkNum = “”.
IF toggle off
Select positive value checks
only
Only show batches where
there are checks to be printed
or sent
Select the apBatch and the apTransCdCheck for printing when the records meet the above criteria. Show the
apBatch as selected in the Browse.
Batch Browse
6.3.7.1 Populating the Payment Browse
When the user clicks on a row in the Batch browse, populate and display the “Check” Browse.
Payment Browse
Get all apTransCdCheck records in the batch including other payTypes. Show the ones with matching
PayTypes as selected. A toggle option “Include Printed Checks?” for seeing/not seeing Printed/ EFT Ref
assigned should be available.
Include Printed/EFT Assigned? (Default this to off)
TABLE
apBatch
apTransCdCheck
Join Criteria
apBatch.apBatchUid
Operator
AND
AND
Include paid toggle = OFF
aptransCdCheck.checkNum = “”
Include paid toggle = ON
aptransCdCheck.checkNum <> “”
OR
AND
Comment
User select the apBatch
get all of the Check records for
the batch
Show non printed or sent
payments only
Show all records
Field definitions for the “Payment Browse”
Table.Field
7/29/2017
Type
Format
TME
Label
Description
Version 1.0
AP Bill Payer
Functional Design
Page-22
Select
Toggle
ON/OFF
Select
batch.batchid
apTransCdCheck.PayType
char
char
x(8)
x(8)
Batch ID
Pay Type
apTransCdCheck.checkNum
apTransCdCheck.vendorNum
OR
apVendorMisc.vendorNum
apVendor.vendorName OR
apVendorMisc.vendorName
char
x(12)
Check/Ref#
char
x(10)
Vendor#
char
x(20)
Vendor Name
apVendor.payee_name
car
x(15)
Payee Name
Shows the vendor’s “Check” that
has the pay type in it and is
selected for printing
It is possible that more than one
batch has been selected. We
need to see the batch id of the
check displayed.
Browses shows all
This will be used to display the EFT
reference as well. It should be
large enough to handle that once
we decide what it will be. If this
field is not blank, the payment
was printed/sent successfully
apTrandCdCheck.totalDue
decimal
apTrandCdCheck.totalDiscount decimal
apTrandCdCheck.checkAmt
decimal
999,999,999.99- Amount Due
999,999,999.99- Discount Amount
999,999,999.99- Payment Amount
CALCULATED
integer
9,999,999
apTrandCdCheck.comment
character x(70)
Invoices
Payment Notes
Cut off to make room
May be blank- cut off to make
room
Total Gross invoice amount for the
check
Total discount taken for the check
Total check amount
Number of invoices this check is
paying
Can Wrap if we need room. If
apTransCdCheck.checkType = “V”,
display “VOID”
It is possible that a pay type must be changed. Allow the user to change the pay type in the Payment browse.
They can change a non selected payment’s pay type to be equal to the one selected at the beginning. By doing
this, it will select the payment for printing. They can also change one that has been selected for printing to
another pay type. In this case the payment would be deselected for printing. They can deselect any payment
they do not wish to print. This will not change how the records are updated. It will only remove it from
printing in this session. Do not let the user change anything if the checknum <> “”. This means it has been
thru the printing/ or assigned an electronic reference.
6.3.7.2 Populating the Remit Browse
If the user wants to see the invoices that the check will be paying, they can do that by clicking on a line
in the Payment browse. Nothing can be changed or selected in this browse. It is for information only.
TABLE
Join Criteria
apTransCdCheck
7/29/2017
Operator
Comment
User selects the check
TME
Version 1.0
AP Bill Payer
Functional Design
aptransCdInvoice
apInvoice
Page-23
apTrandCdCheckUid = apTransCdCheck.
apTrandCdCheckUid
apInvoiceUid =
apTransCdInvoice.apInvoiceUid
List all invoice details for the
check
To get vendor cust num
Field definitions for the “Remit Browse”
Table.Field
Type
Format
Label
apInvoice.VendorCustNum
apTransCdInvoice.Location
apTransCdInvoice.invoiceNum
apTransCdInvoice.futureCode
apTransCdInvoice.invoiceDate
apInvoice.discountDate
apTransCdInvoice.amountDue
apTransCdInvoice.discountAmt
apTransCdInvoice.writeOffAmt
apTransCdInvoice.payAmount
apTransCdInvoice.comment
Char
char
char
char
Date
Date
Dec
Dec
Dec
Dec
char
x(10)
x(5)
x(16)
x(2)
MM/DD/YYYY
MM/DD/YYYY
999,999,999.99999,999,999.99999,999,999.99999,999,999.99x(70)
Acct#
Location
Invoice#
Future code
Invoice Date
Discount Date
Amount Due
Discount Amount
Write Off
Payment Amount
Invoice Comment
6.3.8
Description
Our account number with the
vendor for the invoice
Invoice Location
Invoice Number
Blank if not future invoice
Total Invoice amount due
Invoice Discount
Invoice Write off amount
Total payment on the invoice
may wrap if needed
Print Alignment Check
This option is used to make sure the forms are aligned in the printer correctly. The system has
to keep track of the check# used for alignment printing. All of the values to be printed are hard
coded in BIRT with the exception of the check#. We need to make one call to the printer, with
the next check# each time the “Print Alignment Check” button is chosen.
This option does not print the “real” checks that have been selected for printing. It prints one
void check each time the “Print Alignment Check” button is clicked.. An “alignment” parameter
needs to be sent to BIRT when we make the call to the print routine. Each time an alignment
check is printed, a VOID check record is added to the formAPCheck table where printstatus =
“VOID” with the check# used for the alignment check. There is no need to create
formAPRemit.
Each time an alignment check is printed, the next check # is updated by 1, the one printed is
voided. Most check paper is not completely blank paper. There is usually a control number of
some kind on a special kind of paper that makes erasing and changing number manually
impossible. They need to keep track of those control numbers too.
This option will be disabled if EFT.
6.3.9 Print Checks
This option is used to print all of the checks that have been selected for printing. First we need
to build the data to be printed, then pass the printer id and form # to the printing routine. If EFT
has been cosen, change the name of the button to “EFT Reference #s.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
6.3.9.1 Build the data to be printed
Page-24
Create the print job record to pass to the logic BIRT will need to print the checks
Table = PrintJob – Ties the check data to a batch, printer, and form
Field
printJobUid
batchUid
printUid
formUid
Data Map
System assigned to this record
batch.batchUid
s-printer.printUid
s-form.formUid
Label
Unique Id
Batch ID
Printer ID
Form Uid
Description
System assigned unique ID
Parent Id for the batch
Unique ID of the printer we want to use.
Uniqu id of the form we need to use
This table has the information needed for a print run. We need to look at the printing requirements for
all of the formats. BIRT needs to be able to use the data, bundle up the *rptdesign records it needs for
the form, then print the data without any further user intervention on the BIRT side. The form# and
printer designation for the application has a default for the user. A “reprint” will assign a new
printjobUid to the records selected for reprinting..
Additonal tables needed for populating the data.
Add’l TABLEs
batch
location
file-assoc
country
g-bank
apVendor
apVendorMisc
apInvoice
Operator
Join Criteria
batch.batchUid = apBatch.batchUid
location.loc = batch.batchloc
file-assoc.a-assoc = location.co
countryCd = file-assoc.Country
gb-co = file-assoc.a-assoc
gb-bank = paymentType.gb-bank
vendorNum = apTransCdCheck.vendorNum
apVendorMiscUid =
apTransCdCheck.apVendorMiscUid
apInvoiceUid =
apTransCdInvoice.apInviceUid
Comment
AND
This data is in similar format to apTransCDCheck and apTransCdInvioce except it is print ready. BIRT
does not have to look at any other tables besides these to print a check. This means we need to populate
the data accurately before we send the print job to BIRT.
Table = formAPCheck – populate with apTransCDCheck records that have been selected for
printing
Field
formApCheckUid
printJobUid
company
company_Name
Data Map
System assigned to this record
printJob.printJobUid
apTransCdCheck.company
file-assoc.a-name
Label
Unique Id
Print Uid
Company#
Co Name
company_Addr1
company_Addr2
company_Addr3
company_City
company_State
file-assoc.a-addr1
file-assoc.a-addr2
file-assoc.a-addr3
file-assoc.a-city
file-assoc.a-st
Co Add 1
Co Add 2
Co Add 3
Co City
Co State
7/29/2017
TME
Description
System assigned unique ID
Parent Id for the print job.
Company ID
Company Name to print on check
(note: this is _not_ the Payee Name).
Address 1 to print on the check
Address 2 to print on the check
Address 3 to print on the check
City to print on the check
State code for the check
Version 1.0
AP Bill Payer
Functional Design
Page-25
file-assoc.a-zip1 + “-“ + a-zip2
company_Zip
company_Country country.name
Co Zip
Co Country
bank_Name
g-bank.bank_name
Bank Name
bank_Addr1
bank_Addr2
bank_Addr3
bank_City
bank_State
bank_Zip
bank_Country
bank_Route
vendorNum
g-bank. bank_Addr1
g-bank. bank_Addr2
g-bank. bank_Addr3
g-bank. bank_City
g-bank. bank_State
g-bank. bank_Zip
g-bank. bank_Country
g-bank. bank_Route
apTransCdCheck.vendorNum
Bank Add1
Bank Add 2
Bank Add 3
Bank City
Bank State
Bank Zip
Bank Country
Routing #
Vendor #
payee_Name
See Below – 1.
Payee Name
See Below
payee_Addr1
payee_Addr2
payee_Addr3
See Below – 1.
See Below – 1.
Payee Add 3
Payee name to print on the check
Payee address line 1 to print on the
check
Payee address line 2 to print on the
check.
Payee address line 3 to print onthe
check
Payee Add 2
See Below – 1.
Postal code to print on the check
Country Name (not Code) to print on
the check
Bank name Bank name to print on
check
Bank address line 1
Bank address line 2
Bank address line 3
Bank city
Bank State code
Bank postal/zip code
Bank country code
Bank's Transit/Routing Number (ABA)
Enter the vendor number
payee_City
See Below – 1.
Payee City
Payee city to print on the check
payee_State
See Below – 1.
Payee State
Payee Zip
Payee State to print on the check
Payee postal/zip code to print on the
check
Payee country to print on the check.
payee_Zip
See Below – 1.
payee_Country
See Below – 1.
Payee Country
checkDate
See Below – 2.
Ck Date
checkNum
checkAmt
See Below – 3.
apTransCdCheck.checkAmt
Check Number
Net Check Amount
checkAmtDisp
payInWords
comment
VendorCustNum
See Below – 4.
Amt Disp
See Below – 5.
Amt in words
Check Notes
Acct#
apTransCdCheck.comment
See Below – 6.
apTransCdCheckUid apTransCdCheck. apTransCdCheckUid Check Trans
Check date
Check Amt formatted for the check
(*****1,234.44)
Amount of the check spelled out in
words
Check comment to print on check.
The customer Account# with the
vendor. If there is only one vendor's
customer number for the account, this
field will get filled in to print in the
heading of the check stub. If more than
one, the detail comment will be
populated with the correct # for the
location.
Id of the Bill Pay transaction this came
from
1. Populating the payee_* fields
IF apTransCdCheck.isMisc = TRUE THEN
Field
7/29/2017
Map Table
Map Field
TME
Version 1.0
AP Bill Payer
Functional Design
payee_Name apVendorMisc
payee_Addr1 apVendorMisc
payee_Addr2 apVendorMisc
payee_Addr3 apVendorMisc
apVendorMisc
payee_City
payee_State apVendorMisc
apVendorMisc
payee_Zip
payee_Country apVendorMisc
Page-26
vendorName
address1
address2
address3
city
state
zip
country
IF apTransCdCheck.isMisc = FALSE AND apVendor.payee_Name <> “” THEN
Map Table
Field
payee_Name apVendor
payee_Addr1 apVendor
payee_Addr2 apVendor
payee_Addr3 apVendor
apVendor
payee_City
payee_State apVendor
apVendor
payee_Zip
payee_Country apVendor
Map Field
payee_Name
payee_Addr1
payee_Addr2
payee_Addr3
payee_City
payee_State
payee_Zip
payee_Country
IF apTransCdCheck.isMisc = FALSE AND apVendor.payee_Name = “” THEN
Map Table
Field
payee_Name apVendor
payee_Addr1 apVendor
payee_Addr2 apVendor
payee_Addr3 apVendor
apVendor
payee_City
payee_State apVendor
apVendor
payee_Zip
payee_Country apVendor
Map Field
vendorName
address1
address2
address3
city
state
zip
country
2. Check Date This comes from Filter ID 5 entered at the beginning of the program
3. Check Number(checkNum)
The first check number to be used is from Filter ID 3 - Beginning check number. The next check
number will be calculated automatically each time a check # is assigned to an FormAPCheck id.
This starting number comes from g-bank.gb-chk# for printed checks. For ACH or credit card
paymentTypes, the electronic reference will come from payEFTReference.eftTransId.
Alignment checks:
 Create a formAPCheck record :
 checkNum = the next available real check number then update that to the next number
 payee_name = “Alignment”
 comment = “VOID” + batch.userLoginID.
Voided Checks (from a reprint):
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-27
 Create a formAPCheck record for the voided check# by copying the original formAPCheck
record to a new record. There is no need to copy the detail because we’re not backing out
numbers. We’re simply saying we messed up a form.
 Payee_name = “Reprint”
 Comment = “VOID” + batch.userLoginID.
 Reassign a new check number to be printed to the original formAPCheck record
The voided checks will be added to apTransCDCheck when we OK the print. They will also be
created in the final apCheck table so we can account for all check numbers.
Regular checks:
As formAPCheck records are created, assign the check # automatically starting with the next
available check number. The records and check#s will be assigned by sort type which is vendor
name or vendor number. Create formAPCheck records until you assign the ending check number.
There may be more checks to print but you will need to reload the paper at this point. We will use
formAPCheck.checkNum to update apTransCdCheckNum. We must keep track of the last check#
printed so we can update the next available check # in g-bank when we OK the print run. This means
we need to be aware of others printing checks for this g-bank. Locking the g-bank record at the
beginning of the check run is recommended.
ACH and Credit Card payments:
Each electronic transaction must have a unique id so it can be traced in both systems using the same
number. It must be human readable because when search for something we may need to give that id
verbally on either side. A new table/field payEFTReference.eftTransId is used for this unique
identifier. When we update the check# it will be “E” + this number. If this is an electronic payment
update apTransCdCheck.electronicReference id = payee_name + “ID: + ”this number . Do not
exceed 50 characters – cut off part of the Payee name to make it fit. Each time a reference number is
used, increment eftTransId by 1.
4. Check Amount to be displayed (checkAmtDisp)
Format the check amount with leading asterisks (**). This is to prevent someone from changing the
check amount by adding numbers in front of the actual amount. The format of the check amount is
999,999,999.99-. It is OK to replace this format with ** for the leading zeroes plus 1 extra asterisk in
case the check is actually written for the full amount. Do not replace the commas with *. There
should be a routine we can run that does this for us. But the result should be as follows:
2,265.00 = *****2,265.00
100,000,000.00 = *100,000,00.00
IN other words, replace the actual leading 0s with asterisks + 1 if the amount is full.
5. Check Amount in words (payinwords)
There should be a routine already available that can be called to produce this value.
2,265.00 = TWO THOUSAND TWO HUNDRED SIXTY-FIVE and 00/100 DOLLARS
Do not worry about how long the field is. BIRT will wrap the comment around to make room for all.
The field size is big enough to hold the maximum possible words.
6. Our Account number with the vendor (vendorCustNum)
This one is tricky because there is not enough room to print this account number on the stub along
with everything else we need to print BUT it is possible that different locations will have different
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-28
vendor account #s. We need to check the data to see what it is we’re printing AND how the vendor’s
customer account#s are created.



If apTransCdCheck.isMisc = TRUE ASSIGN formAPCheck.vendorCustNum =
apVendorMisc.vendorCustNum.
If we have one account number with this vendor, there will be only 1 record in
apVendorCustNum where apvendorCustNum.apVendorUid = apVendor.apVendorUid. In
this case, ASSIGN formAPCheck.vendorCustNum = apVendorCustNum.vendorCustNum.
IF there is more than one record in apVendorCustNum where
apvendorCustNum.apVendorUid = apVendor.apVendorUid leave this field blank. We will
assign those by location in formAPRemit.Comment. This will override any actual comment
that may have been entered. For furter details, see below for populating the table
formAPRemit.
Table = formAPRemit – popuilate with apTransCDCheck records that have been selected for
printing
Field
formApRemitUid
formApCheckUid
Data Map
System assigned to this record
formApCheck.formApCheckUid
Label
Unique Id
Parent Id
VendorCustNum
company
location
See Below - 7.
apTransCdInvoice.company
apTransCdInvoice.location
Acct#
Company Id
Loc
invoiceNum
apTransCdInvoice.invoiceNum
Invoice #
futureCode
invoiceDate
amountDue
apTransCdInvoice.futureCode
apTransCdInvoice,invoiceDate
apTransCdInvoice.amountDue
Future Code
Invoice Date
Invoice Amt Due
discountAmt
apTransCdInvoice.discountAmt Invoice Discount
writeOffAmt
payAmount
apTransCdInvoice.writeOffAmt Write Off
apTransCdInvoice.payAmount Net Invoice Amt
comment
apTransCdInvoice.comment
Comment
poNum
deductTotal
apInvoice.poNum
formAPRemit.discountAmt +
PO No.
Total Deductions
7/29/2017
TME
Description
System assigned unique id
Check Parent ID
The customer Account# with
the vendor.
Company ID
Control GL Interface
Vendor invoice# OR original
invoice# if a transfer If we
pay one vendor account with
another, that orignal invoice#
is copied to the new vendor.
If a duplicate, we will add "###" to the end until we get a
unique #
Future code for split
payments If this is a future
invoice, enter AA-ZZ for
additional payment. This is
used for split terms and is
part of the invoice number
that makes it unique
Total Discount taken during
check writing
Total amount of write offs
against this invoice this check
run
Net amt to be paid
Invoice comment to print on
check. Entered at AP invoice
entry.
PO# or Claim# from interface
to a-apclr and o-claim
For a print option on the
Version 1.0
AP Bill Payer
Functional Design
Page-29
formAPRemit.writeOffAmt
check stub.
7. Our Account number with the vendor (vendorCustNum)
This one is tricky because there is not enough room to print this account number on the stub along
with everything else we need to print BUT it is possible that different locations will have different
vendor account #s. We need to check the data to see what it is we’re printing AND how the vendor’s
customer account#s are created.


If formAPCheck.vendorCustNum <> “”, there is only 1 vendorCustNum account for this
vendor. WE do not need to populate this field. It will be printed once on the check stub
If formAPCheck.vendorCustNum == “” THEN
ASSIGN formAPRemit.vendorCustNum = apInvoice.vendorCustNum
NOTE: BIRT will have to look at this field to decide what to print in the comment. If this
field is not blank, then the vendorCustNum will print in the comment column. If it is blank,
formAPRemit.comment will print in the comment column.
6.3.9.2 Send the data to the black box for printing
This part of the program will call a program that interfaces with the G4 print mechanism.
BIRT will only print checks for those formAPCheck records with the printjobUid we send to it. For a
reprint, this is accomplished by resetting the printjobUid to a new value when we reassign check
numbers for a reprint. We will never “reprint” or “void” an EFT.
It may take some time to print the data so we need to let the user know what is happening with a
message. In the standard message area at the top of the screen, as soon as the user clicks on either “Print
Alignment Check” or “Print Checks” display “Printing Checks, please wait.” We cannot let the user go
elsewhere or park this until it is done printing. When the program is done printing it will return the
screen to the user, the program will display “Checks have been printed” at the top of the screen and the
“Paid for Payment Type [AAAAAA] browse below:
Paid for Payment Type [AAAAAAAA]
Reprint
(ALL)
(select)
Void
(ALL)
(select)
BatchId
Check/Ref# Check Date
Payment
Amount
MM/DD/YYYY 11.2-
Vendor#
x(8)
x(12)
x(10)
Payee
Name
x(30)
Status
x(8)
One record for each formAPCheck for the PayType.
Field definitions for the “Paid for Payment Type [selected in section 6.2.5.1 at the beginning]” Browse
The Reprint and Void selections will have an “ALL” selection option in the heading. Previously voided
checks will show in this display but will not be changeable.
Table.Field
Type
Format
Label
see below
see below
batch.batchid
Toggle
Toggle
char
ON/OFF
ON/OFF
x(8)
Reprint
VOID
Batch ID
7/29/2017
TME
Description
Allow user to select this check to
be reprinted
Is this check# to be voided?
It is possible that more than one
Version 1.0
AP Bill Payer
Functional Design
Page-30
formAPCheck.checkNum
formAPCheck.checkDate
formAPCheck.checkAmt
formAPCheck.vendorNum
char
date
decimal
char
formAPCheck.payee_name
formAPCheck.printStatus
x(12)
MM/DD/YYYY
999,999,999.99x(10)
character x(30)
Character x(8)
Check/Ref#
Check Date
Payment Amount
Vendor#
Payee Name
Status
batch has been selected. We
need to see the batch id of the
check displayed.
This will be used to display the EFT
reference as well. It should be
large enough to handle that once
we decide what it will be.
Total check amount
May be blank- cut off to make
room
Reprint, Voided (FYI only)
Reprint Toggle – Reprint the check selected. It is possible that we need to re-assign check#s on a reprint
because not all of the checks need to be voided – only a few actually jammed. Change the status to
“Reprint”. If the user deselects “Reprint”, change the status back to blank.
Void Toggle – Void the check# showing by creating another formAPCheck record with the voided
information as described above. Set the status to “Voided”. If the user deselects “VOID”, the status
should be changed to blank. If a check’s status was previously set to voided, do not let the user reprint
or change the status back once it has been through another print cycle. If Void Toggle is on,
automatically turn Reprint on. If deselect void, deselect both.
BIRT will not print Void records.
Status – The status will be blank the first time the data is sent to BIRT. “Sent for Pay” if electronic
payment was made when it comes back.
When the printing is done, the user will verify 1 of the following. .
REPRINT
OK
EXIT – checks are not printed successfully, do not reprint (close the print check part of the application,
delete printJob and formAP* tables. Do not update as printed, as a result on reopen the application that
checks are displayed in the list as if they had not been sent to the printer). Go to the final section
6.3.9.4.. EXIT is a BAD option. Both Cindy and I agree this is too dangerous and should not be
included. Once checks have been “printed” there is no way you can actually tell if a hard copy
was in fact created. To let the user simply make the check disappear would be a violation of
security. If they have come this far, they either need to Reprint or VOID whatever checks were
not successful but always finish this procedure with an OK. That will leave an audit trail in the
system.
OK – The checks have been printed successfully. Close the browse, Go to the update section
6.3.9.3 – Update apTransCdCheck.
REPRINT – Disable the REPRINT BUTTON until the Print Criteria is entered for reprinting:
If reprinting is needed, in the Print Filter Criteria:
The user will enter the new Starting and Ending Check numbers and check date.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-31
Change “Rerun” to “Reprint”
The user will click the “Is this a Reprint”? Once this toggle is on, ask the following questions:
Filter
Id
7
Label
Reprint FROM old Check#
8
Reprint TO old Check#
Table.Field or
Description
formAPCheck.checkNum
Type
integer
Format
>>>>>9
formAPCheck.checkNum
integer
>>>>>9
Description
This is the original starting
check number that needs
to be reprinted.
This is the original ending
check number that needs
to be reprinted.
Field ID 7/8 – The user must enter the first and last check #s from the Paid for Payment Type
browser to be reprinted. When the apply filter is selected, select those checks in the Paid
browse to be reprinted. By comparing the reprints with the new check number range, figure
out which of the original checks are to be voided. These would be any checks selected for
reprinting that are not included in the new check # range. Set those to be voided as well.
For example, the original print was for check #s 100 to 200. The reprint is from check # 103 to
200 in the original range which is displayed in the Paid for Payment Browse. The new check
number range is 104 to 201. This tells me check #s 100, 101 and 102 are fine and do not need
to be reprinted. Since 103 is not in my new number range it should be voided. Set that to void.
My original checks 104 thru 200 do not need to be voided, they are still good checks because I
am reusing those numbers in my reprint run.
The Reprint and Void options in the browse have an “ALL” selection in the column heading that
will allow a select/deselect of all rows in the brose. .A password setting will disable the user
from changing these settings. If the user is allowed to change the reprint/void selections they
should be able to click on the heading option or change individual checks. Any check set to
VOID, will automatically be set to REPRINT. If the use is not allowed to change these, they will
be disabled.
When the user clicks on REPRINT, create voided checks in formAPCheck for those marked
Void and display the Status as VOID when displayed from the reprint process. Reprint all
checks that are marked for reprint. Assign new check #s and printJobUids for the records to
be reprinted before it sends them to the printer API. Checks that have been reprinted, should
display a status of “Reprint” when displayed from the reprint process. The reprint functionality
may be run several times before OK is selected. It would be unusual for checks to have
intermittent good/bad checks needing to be voided but we should allow for it.
The EFT option will not have a reprint function. It can have a void option because nothing has
been sent anywhere, yet. Voiding an electronic payment will not update apTrandCDCheck as
if it had been paid. It will remain as open in the browses.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
Page-32
6.3.9.3 Update apTranCdCheck showing the checks were printed or to be sent electronically.
Printed Checks –
Table.Field
apTransCDCheck.checkNum
apTransCdCheck.checkType
apTransCdCheck.payee_Name
Description
= formAPCheck.checkNum
the actual check number printed
= “C”
Computer printed check
= formAPCheck.payee_Name Actual Payee_Name
.
Find g-bank for the PayType to update g-bank.gb-chk# = last check number printed.
Table.Field
g-bank.gb-chk#
=
the last (highest) check # printed in
formAPCheck.checkNum
Description
This is done for paymentType.isCheck =
TRUE only.
Voided Checks – Create apTransCdCheck records
Table.Field
apTransCDCheck.apTransCdCheckUi
d
apTransCDCheck.apBatchUid
apTransCDCheck.batchDate
apTransCDCheck.batchId
=
= apBatch.apBatchUid
= batch.batchDate
= batch.batchId
apTransCDCheck.batchLoc
apTransCDCheck.company
apTransCdCheck.checkType
apTransCDCheck.PayType
apTransCDCheck.gb-bank
apTransCDCheck.vendorNum
apTransCDCheck.checkAmt
=
=
=
=
=
=
=
apTransCdCheck.comment
“VOID” + batch.userLoginID +
= payee_name
apTransCdCheck.payee_Name
Description
System assigned unique id
Link to parent
AP Entry Batch Date
AP Entry Batch ID
Batch Location used to group
transactions
Company ID
Computer printed check
Printing pay type
batch.batchLoc
formAPCheck.company
“V”
PayType being selected for printing
paytype.gb-bank
formAPCheck.vendorNum
formAPCheck.checkAmt
Vendor Number
Check Amount
Void identity
= formAPCheck.Payee_Name
No apTransCdInvoice records need to be created. This is simply a form being voided. It has not affect
on totals or GL.
Electronic Payments – ACH & Credit Cards
If an electronic payment was “voided” in the print check routine, ignore this section of the update and
DO NOT create a void check record in apTransCdCheck.
Table.Field
apTransCDCheck.checkNum
apTransCdCheck.checkType
Description
System assigned unique id
Computer printed check
= formAPCheck.checkNum
= “E”
formAPCheck.payee_name + “ID:” +
apTransCdCheck. electronicReference = formAPCheck.checkNum
Reference for reconciliation
6.3.9.4 Exit and OK
Delete the formAPCheck and formAPRemit records for your print job(s)
Delete the printJob record(s). You may have more than one if a reprint.
7/29/2017
TME
Version 1.0
AP Bill Payer
Functional Design
6.3.10 Complete
Page-33
The message: “Selections have been paid” will appear on a successful Complete and the application will
close. There are no other data base updates necessary because the bill payer update routine is another
process. It would seem that the Complete button is unnecessary because the user can close the app using
the “X” button or “Close” option in the Context menu. However, at some point we may change the
complete button to fully run the bill payer update so that we can eliminate another menu process.
Leaving the Complete button in place will make more sense to the end user because every program of
this type has a Complete button which finishes the application. Without it, I think the users will be
confused. They won’t know what to do next.
6.3.11 Reset – We will not allow this if we have actually printed checks
If no checks have been printed and or EFT Transaction Refeences have been assigned, Reset will clear
the filter criteria, deselect any records that have been selected for printing, and reset the Batch Browse to
Read Only.
Once check and reference numbers have been assigned to apTransCdCheck, this button should
disappear.
7/29/2017
TME
Version 1.0