Questions from Acquisitions group:
1) What happens when you process an invoice? What format does the voucher take on?
- At Chicago, processed in the system and then it goes to the university financial system. Some things need to be processed manually. Invoices cannot be altered in OLE so wire transfer information are not added after the fact. Check # and proof of payment are most important. Auditors always ask for voucher number. Need a way to handle transactions that don't feed into the campus's financial system.May have to handle adjustments that don't have to go through campus' system. With OLE, invoices are generated for cross-departmental payments - library pays the full amount and then department payment to library is treated as a credit.
- At Duke - only process payments that are paid by check, other payments, e.g. wire transfers, credit card payments, are done outside and then added into the system. Funds are encumbered until the whole process is completed. Doesn't bring in the transaction ID from a wire transfer from university financial system into ILS - they're not really needed. Journal vouchers (JVs) come in and out all the time.
- At Cornell -The invoice is processed in Voyager and adjusted when the wire transfer is complete - then the invoice is adjusted and then approved. We have the means to code as manual so it doesn't feed to AP at Cornell.
2) Is it sufficient to relate a fund to an external account?
- Yes, and more than one FOLIO fund can refer to a single external account.
Preferred to have proof of payment = image of check, but check # is typically all we have. External number that external systems use to get to the actual proof of payment. At Cornell we make payments via check or ACH, both have a number generated by the financial system.
3) Within the FOLIO fund, if we have fields "allocation to and allocation from" - if I leave those blank, are we allowing people to transfer to/from anywhere, or does this mean that funds cannot be transferred to/from?
- Why restrict? The number of people who would be working on payments is small so it should be up to them. If filled in, they can be transferred to the specific place; if blank, it's up to the payment person's discretion (or allow to anything).
4) ?
5) ?
- Occasionally have to cancel processed payment - "cancellation" status. Preferred to have option to cancel, rather than simply delete out. Good to have both options as some people do delete. It's important that there are permission restrictions because there could be serious ramifications, especially if completed transactions are able to be deleted.
- Identify a status that is uneditable? Yes
- Nice to haves: status labels based on institution preference; for the entire finances module, departments in same institution would share statuses, at least initially, though different ledgers could have different settings.
6) How important are POs versus PO lines?
- How many clicks will be needed?
- Some institutions use PO lines, some don't
- Can vary between monographs/one-time purchases versus annual subscriptions.
- If you allow for multi-line POs, you aren't precluding those that use them. However, if you limit to POs only, it can be a problem for those that do use PO lines. The process needs to be streamlined so that PO lines do not require extra clicks for those that do not use them.