A significant project that I completed during 2010 was the development of a requirements traceability matrix (RTM) that includes all global, functional, and technical (testable) requirements for an interface between an EGOV Travel Application and a Central Financial System. Authorizations and vouchers have separate RTM’s that house all information regarding individual requirements. The overall objective for the interface is to provide the capability to upload obligations and invoices to the Core Financial System for all authorizations, temporary duty travel vouchers, advance vouchers, and local vouchers via the import of a data source file from the EGOV Vendor to the Core Financial System while applying the same business rules, program logic, and validation edits used by the Core Financial System when transactions are processed manually by the user. The interface shall also provide the capability to capture and store travel specific data elements from the EGOV Travel Application source file for reporting purposes. The following table displays the expected document types that the EGOV Travel Application will produce, which act as the primary assumptions for the requirements.
|
EGOV Travel Application |
Core Financial System |
||
|
Travel Type |
Authorization Type |
Obligating Document Type | Vendor Type |
|
Temporary Duty |
Original |
Traveler – Payable to the Traveler | Employee |
| CBA – Centrally Billed Account (Agency Account) | Non-Federal | ||
|
Amendment |
Traveler – Payable to the Traveler | Employee | |
| CBA – Centrally Billed Account (Agency Account) | Non-Federal | ||
|
|
|
||
|
|
|
||
|
Travel Type |
Voucher Type |
Invoice Type | Vendor Type |
|
Temporary Duty |
Original |
Traveler – Payable to the Traveler | Employee |
| Credit Card – Payable to the Traveler’s Credit Card | Non-Federal | ||
| EGOV Vendor – Payable to a Third Party | Non-Federal | ||
|
Supplemental |
Traveler – Payable to the Traveler | Employee | |
| Credit Card – Payable to the Traveler’s Credit Card | Non-Federal | ||
|
Advance |
Traveler – Payable to the Traveler | Employee | |
| Credit Card – Payable to the Traveler’s Credit Card | Non-Federal | ||
|
Local |
Original |
Traveler – Payable to the Traveler | Employee |
| Credit Card – Payable to the Traveler’s Credit Card | Non-Federal | ||
| EGOV Vendor – Payable to a Third Party | Non-Federal | ||
The interface will accomplish the following four fundamental operations:
- Data Validations
- Data Load
- Generation of a Status Report
- Automated Reconciliation
Data validations shall be the initial process of an interface and most requirements involving validations can be considered global requirements (i.e. applicable to both authorizations and vouchers). The following are examples of global requirements for data validations:
- The process shall provide the ability to save files to the applicable location to be processed.
- The process shall provide a mechanism for end-users to specify the file name to be processed.
- The process shall truncate free form values at the maximum allowable character length.
- The process shall validate across organizational units.
- The process shall prevent processing source file by user with insufficient access.
- The process shall validate that the source file is complete and contains all the required data elements.
- The process shall validate that data type and field lengths are correct.
- The process shall validate the source file does not contain duplicate documents.
- The process shall validate the derived supplier is active under the Core Financial System.
- Validation errors shall not prevent the entire source file from loading.
The data load shall incorporate in the actual creation of the obligatory document or invoice in the Core Financial System. The following are examples of data load requirements for invoices:
- The process must derive the appropriate supplier.
- For original temporary duty vouchers, the process shall create an invoice payable to the traveler for expenses identified as reimbursable in the source file.
- For advance vouchers, the process shall create an invoice payable to the traveler for expenses identified as reimbursable in the source file.
- For local vouchers, the process shall create an invoice payable to the traveler for expenses identified as reimbursable in the source file.
- For supplemental vouchers, the process shall create an invoice payable to the traveler for expenses identified as reimbursable in the source file.
- The process shall reduce the amount on the invoice payable to the traveler by the amount due to the traveler’s individual government credit card and/or third party, giving the user defined criteria is met for disbursing funds to the credit card or a third party.
- Process shall create an invoice payable to the traveler’s individual government credit card when user defined criteria is met.
- Process shall create an invoice payable to a third party vendor when user defined criteria is met.
- The generation of a status report is needed in order to verify documents loaded successfully, identify documents that encountered an error, and also for reconciliation purposes. The following is an example of a status report requirement for both authorizations and invoices:
- The process shall provide the ability to generate a status report upon processing the source file which provides the load status of each record contained under the source file along with the reason for failure where applicable.
The automated reconciliation process shall provide a daily reconciliation for transactions uploaded through the interface. The following is an example of a reconciliation requirement for invoices:
- The process shall verify that every voucher contained in the source file has generated the appropriate invoices in the Core Financial System.
- The process shall verify the sum of every invoice that is created from a particular voucher is equal to the total reimbursable amount of that voucher in the source file.
By Grant Brown
“The views expressed are those of the author and do not reflect any position of the Government or my agency.”