Functional Specifications
User Story/SpecName
Process Module
Sub-Process:
Release :
Author(s)
Date
Jira
INVOICE DATA FOR EXPORT
Select & Acquire
-OLE 1.0
S&A Team
6/25/13
OLE-3574 and subtasks (see below)
1.0 Purpose
To collect data from invoices for exporting to external financial systems.
2.0 Index to User Stories
This spec covers the following Jira tickets:
OLE-2701 File Export of Invoices to be Paid
OLE-2099 P-Card Payment & Invoicing
OLE-2946 University System number for the vendor record
3.0 Terms & Definitions
Term
Definition
P-card, Procard
Synonyms for credit card
PDP
Pre-Disbursement Processor – a module of KFS used to collect data for
generating payments.
INV
The new document type OLE will use for invoice input. Defined by the
spec on OLE-2657.
4.0 Specifications & 10.0 Business Rules
Many OLE libraries will need to export invoice-related data to an external system that generates the payments.
This data needs to be in a standard place and format within OLE.
1
Functional Specifications
Some invoices posted in OLE should be flagged for exclusion for this extract because they are already paid
another way. Examples of these are credit card invoices (where the charge has already been paid by credit card,
and has a separate accounting workflow), and invoices covered by a deposit account.
The extraction of the data from OLE will be done either by a script outside OLE, or by a service within OLE,
extracting data from the PDP tables. Sites will then configure the extracted data to meet the requirements of
their external financial system. This spec does not cover the creation of the script or service; it only describes
how to make the necessary data available to it.
Field in Vendor record
OLE-1908 defined a way to store the university’s vendor ID number for each vendor to be paid. A type of
Search Alias was defined as “External Vendor Code”. Two things will have to be done to make this field
useable for invoice data extract:
* the field will have to be defined as nonrepeatable, so that each vendor record can have only one Search Alias
of type=External Vendor Code. (It appears to be repeatable in OLE 0.8.)
* this data will have to be written to one of the PDP tables as part of the PREQ approval process.
Payment Method
KFS has a Payment Method field on the Disbursement Voucher (DV). OLE has already been modified to add
this field on the Payment Request (PREQ) as well. Since OLE PREQs will be auto-generated by the Invoice
document (INV), whatever Payment Method is listed on the INV should be inherited by each PREQ it creates.
Pay Date and Immediate Pay
PREQs in KFS contain a Pay Date, calculated based on the Payment Terms field of the Vendor record. They
also have a check box marked “Immediate Pay”, in case you want to override the usual Pay Date and issue a
payment immediately.
INV records in OLE will also have both these fields, and should pass the data from them on to each PREQ they
generate.
However, checking “Immediate Pay” on a PREQ does not currently affect the Pay Date; it remains the same as
usual. Instead, each element gets written separately to the PDP tables. In KFS, it was expected that the PDP
routines would override the Pay Date field when the Immediate Pay field was set to “y”.
2
Functional Specifications
Since, in OLE, the data will be extracted prior to PDP, a different workflow is necessary. When the Immediate
Pay checkbox is checked on the INV record, this should cause the Pay Date on the INV to change to the date the
INV document is approved. This new date should be passed on to all the PREQs created by the INV approval.
PDP tables
In order for the extract to work, all the necessary data elements must be easily accessible. The PreDisbursement Processor (PDP) tables seem the likeliest place to harvest the data from, since most of it is there
already.
When a Payment Request is approved, our understanding is that OLE already writes the following data elements
to the PDP tables:
In the PDP_PMT_DTL_T table:
* Invoice number
* Invoice date
* Invoice grand total
In the PDP_PMT_GRP_T table:
* Vendor name
* Customer Institution Number (aka Acquisition Unit Vendor Account -- the vendor’s account number for the
library)
* Payment Attachment Indicator
* Pay Date
* Immediate Pay indicator
In the PDP_PMT_ACCT_DTL_T table:
* Expenditure totals by accounting string
OLE should be modified to also write the following data to one of the PDP tables:
* Payment Method, from both the DV and the PREQ
* Search Alias of type=External Vendor Code from the Vendor record
(We don’t know whether it matters which table, so long as the data is easily extractable. HTC should choose
whichever table looks most appropriate.)
3
Functional Specifications
In this scenario, the exclusion of certain payment types, like p-card invoices, would be handled by the extracting
script or service. This allows institutions to have flexibility in handling excluded payment types. For instance, a
site may be required to transmit data for all approved invoices from OLE, but to send the credit-card invoices in
a separate feed from the ones to be paid. Other sites may be expected to not send any data for credit card
invoices.
An additional field in the PDP tables would be “extract date”. This would insert a date showing when the data
for any given invoice was extracted. (A field for this purpose may already exist; if not, one should be created.
Possible candidates may be in the PDP_PROC_T table.) It is assumed that that script or service extracting the
data would populate this field with the date of extract.
Note: OLE-1884 allows for PREQs with either positive and negative totals. This method should work for both,
since either way the PREQ will be writing the value to the PDP table. In release 1.5, when we adapt the KFS
Credit Memo (CM) document for OLE, we’ll have to examine how it interacts with these tables as well.
5.0 Data (Dataflows or Workflows, 6.0 Data Requirements & 12.0 Maintenance
Documents)
7.0 Acceptance Criteria
Ref
Question/Acceptance Criteria
Confirmation
An INV record is approved, spawning one or more
PREQs.
Each PREQ should have the same “Pay Date” as the
INV.
The “Immediate Pay” checkbox is checked on the INV
document, and the document is approved.
The INV’s Pay Date is reset to today’s date, which
is then passed on to the PREQs.
One or more PREQs are approved.
All the fields listed in the “PDP Tables” section
above are populated in the appropriate PDP
tables.
Data is extracted from the tables.
The date of extract is written to the “Extract
Date” field in one of the PDP tables.
(Note: this test cannot be performed until the extract
method, which is being developed separately, is ready.)
A vendor with a Search Alias of type=External
Vendor Code is used on an approved INV.
The Search Alias is written to one of the PDP
tables.
A vendor with noSearch Alias of type=External
Vendor Code is used on an approved INV.
The Search Alias field in the PDP tables should
be blank or null.
4
Functional Specifications
8.0 User Roles/Permissions
Writing the values to the PDP tables happens automatically when a PREQ or DV is extracted, so no special user
permissions are needed.
Running the extract script or service will require a user with server access and the appropriate permissions. (We
assume those permissions will be defined by other specs.)
9.0 Routing or Workflows (ie, Rice): Notifications or Approvals
None.
11.0 UI Requirements
None.
APPENDIX:
Spec Review/Sign-off & Annotations
Name, Title or Role
Notes
Date
Lead SME signoff
Carlen Ruschoff
6/25/13
Module Analyst review
Bob Persing
6/25/13
Spec Tester
Bob will coordinate testing this ticket. Someone from the
Project Team with direct access to the PDP tables will have to
verify the data.
Spec Team/Author
SME Lead/Spec Team lead
5