Many aspects surround developing an interface between an EGOV travel application and a financial system. Understanding the type of documents the EGOV travel application produces and how the financial system handles each document type is very important. Determining the vendors required for each transaction type is also essential in this assessment. Accounting requirements of the financial system will also have a significant impact on the design of an interface. The type of travel specific information passed to the accounting system is important and has great impact on the reporting capabilities of the financial system.
The basic document types an EGOV travel application can produce include an authorization, a temporary duty voucher, a local voucher, and amendment documents for both authorizations and vouchers. Other document types can include group authorizations, blank authorizations, constructed vouchers, and interim vouchers. The authorization documents produced from the EGOV travel application serve to create an obligating document in the financial system. Amendments to authorizations act as the modifications to the obligating documents in the financial system. Both the temporary duty voucher and local voucher in an EGOV travel application provide for the creation of invoices in the financial system. Amendments to vouchers act as supplemental invoices to the original invoices in the financial system. A group authorization created from an EGOV travel application would also provide for the establishment of obligating documents in the financial system. In order for group authorizations to be usable for the creation of obligation documents in the financial system, the group authorization must contain details on all travelers included in the group authorization along with any differences, i.e. accounting, expense details, etc. Blank authorizations from the EGOV travel application would also serve to create obligating documents in the financial system. The key with blank authorizations would involve the EGOV travel application’s functional ability to create multiple vouchers from a single authorization. Constructed and interim vouchers created from an EGOV travel application would also serve to create invoices in the financial system. The primary concern with both constructed and interim voucher types is again the functional ability of the EGOV travel application to correctly and consistently produce the document types without error.
Determining the vendors required for the creation of each obligating and invoice document is crucial to a successful interface. Vendors required for both the obligating and voucher documents could include the traveler (or employee), credit card vendor for centrally billed obligating items, credit card vendor for items billed to the traveler’s individual government credit card, and a third party vendor for items paid directly to a third party such as the vendor for the EGOV travel application. Creating obligations and/or invoices in the financial system under the correct vendor for the appropriate dollar amount is reliant on the level of detail the EGOV travel application transmits for each transaction. The EGOV travel application must be able to supply with each transaction, at a minimum, the expenses broken down by vendor or vendor type and expense category in order to create an obligating document and/or invoice in the financial system.
The accounting requirements of the financial system must be taken into consideration when developing an interface for the EGOV travel application to the accounting system. The EGOV travel application should be analyzed to determine the availability for accounting flexfields along with the total number of characters the EGOV travel application can transmit for a line of accounting. To reduce the required number of characters an EGOV travel application is required to transfer, the interface can default values that are the same for all transactions. Using an alias for some or all of the accounting elements housed in the EGOV travel application is also a method of reducing the number of characters required for the EGOV travel application to transmit to the financial system. The use of alias account values would, however, require additional coding in order to crosswalk the values along with the additional time and effort needed to maintain the crosswalk going forward.
The travel specific information transferred to the financial system from the EGOV travel application will be dependent primarily on the information available that accompanies each transaction from the EGOV travel application and the fields available in the financial system to house the information. The basis of what is needed to be housed in the financial system should be driven by expected reporting needs of the agency(s). Travel specific information that is generally required with some financial reporting include the begin trip date, end trip date, authorization number from the EGOV travel application, and traveler name. Other travel specific information routinely requested is the trip purpose of the travel and the per diem location(s) for the trip. The financial system may have limited fields to house the travel specific information needed for reporting purposes. In the case of limited fields in the financial system, it is possible to use a delimiter such as a pipe, colon, or semi-colon in order to segregate multiple values in one in a single field.
By Grant Brown
“The views expressed are those of the author and do not reflect any position of the Government or my agency.”