• Requisition (REQ)
• Purchase Order (PO)
• Purchase Order versions (POA, PORT, PO Split, POC, POV)
• Receiving (RCVL, RCVQ)
• Payment Request (PREQ)
• Vendor (VND)
• PURAP Maintenance Documents
• OLE Acquisitions Search, Extended (KFS) Custom Document Searches. See:OLE Search Technical Documentation

Using Namespaces:

• OLE-SELECT
• OLE-PURAP

And new OLE features or edocs added:

• Webform-to-REQ
• Order Holding Queue (OHQ)
• Receiving Queue (RCVQ)

Coming Soon or in progress:

• Credit Memo (CM)
• Disbursement Voucher (DV)

Plus, Rice 2.x Development for:

•  OLE Ingest 0.6 - Technical Specification

Major  OLE Modifications to Existing Code (PO & PREQ):*

Below have already been modified in OLE’s use of KFS or are planned.

1. Bibliographic information:  Additional fields and action buttons added to line items to capture Bib/cataloging functions. Includes several fields plus drop-down Note sub-tabs; bib fields added to Doc Searches and misc lookups. 
2. Foreign Currency conversion. OLE will allow foreign currency. If Foreign Vendor selected, and that vendors bills in other than USD, then system displays a foreign currency conversion tab for each line item, within REQ, PO, POA (and versions), PREQ. Unit cost, and extended line item costs, and document totals are still maintained in USD. Would need currency conversion on PPRQ (would we need to reverse code change on PREQ or keep it too?)
3. Prorating. OLE implementing Prorating on PREQ for below-the-line item additional charges, allowing users to take a $500 S&H charge (or other types)  and optionally assign accounting lines to it (KFS behavior), or prorate it across line items above: manually, by quantity, or by $$. This function would need to be applied on PPRQ, with added complexity of attributing additional charges across multiple POs
4. Sufficient Funds Check. OLE is in the process of extending the available functionality with additional qualifiers. SFC will be able to be setup for Encumbrances differently than for Expenses. We will allow SFC options like KFS (at Object Code, Object Level, Consolidation, Account, Cash), but allow it to block at =, or block/notify within a %/$ range of depletion, or allow overages to a $/%.  This would have to extend to PPRQ or PREQ edits.
5. PREQ (and all PURAP) & CoA Workflows & Roles. OLE has already greatly modified PREQ routing as noted above. We also anticipate removing more Parameters for the PREQ. We have already modified REQ, PO, APO and PREQ workflows to largely ignore Fiscal Officer, and other Chart routings. We still have to modify code to eliminate Contract Manager Assignment, modify APO rules.  In place of the existing rules/routings revolving around CoA, we have implemented workgroups, such as Selectors (can create REQs), Acquisitions (REQ, POs), Receiving (RCVL), and Invoicing (PREQ)- with no more than 2 roles/stops in routings in most cases. Future edits may have conditional routings or FYIs based on other metadata (in our Bib records, or over $$, etc). We still have to edit Taxation roles/routings for Foreign Vendors.
6. Deposit Accounts. Very soon we will be adding some functionality to accommodate advance payments to vendors. A deposit account is limited to this vendor and certain transactions. As new POs come through, they still encumber, then PREQs created (reversing encumbrance, applying expense). Now we need to stop the PREQ from batching to university thru PDP or other, as it’s already been paid, even though it shows a balance. We now need to link the previous payment to the new transactions, and reconcile the account balances. Working analysis: Deposit Accounts
7. Serials Action Interval, Checkin (variation of line item receiving coming soon)
8. Unordered line items. OLE presently offers function to add line items to a PREQ for lines not on the original PO. This produces an unapproved POA. The POA must be processed before the PREQ can be approved. We have discussed removing this function and forcing users to first create POA, then PREQ. This may be critical to PREQ or PPRQ modifications.
9. PDP (coming soon). Still evaluating. Will need to consider in PREQ solutions. OLE is considering reusing PDP and DV’s. Disbursement Vouchers “might” be used to track prepaid/deposit accounts (where lump advance payment made to vendor, and then multiple POs track to it- have metadata to inform PDP NOT to double-pay/send invoice request to University financial. Note: there may be additional stop-checks actions desired other than for advance deposits). PDP is being evaluated as existing source of GL updates. Instead of using KFS banking, check-writing etc tools, OLE might be able to use PDP to send batches of Payment Requests, requests for Advance payments/DVs, and Credit Memos to university systems. There may be times, however, when Libraries need ability to remove a transaction from the batch load; correct and retransmit to university; or, have ability to stop a financial transaction.
10. OLE adding Order Types (coming soon). We will be modifying/adding an Order Type attribute that will provide rules for Receiving, and Payments. These order types may affect how PO or POA line items are managed, whether RCV-L line item receiving or new Action-Interval/Serial Receiving are required, and how the order types interact with the Payment Request - esp if advance deposits made. Order types may have different rules for encumbrances, when/how a PO may be closed.
11. Disbursement Voucher (coming soon). Will edit to meet OLE metadata needs and to add Foreign Currency. Will remove unneeded personnel, HR, Employee, Asset etc tabs and features.