1) What happens when you process an invoice? What format does the vouche=
r 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 canno=
t be altered in OLE so wire transfer information are not added after the fa=
ct. Check # and proof of payment are most important. Auditors always ask fo=
r voucher number. Need a way to handle transactions that don't feed into th=
e 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-de=
partmental payments - library pays the full amount and then department paym=
ent 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 (JV=
s) come in and out all the time.

At Cornell -The invoice is processed in Voyager and adjusted when the w=
ire transfer is complete - then the invoice is adjusted and then approved.&=
nbsp; We have the means to code as manual so it doesn't feed to AP at Corne=
ll.

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 accoun=
t.

Preferred to have proof of payment =3D image of check, but check # is ty=
pically all we have. External number that external systems use to get to th=
e actual proof of payment. At Cornell we make payments via check or ACH, bo=
th have a number generated by the financial system.

3) Within the FOLIO fund, if we have fields "allocation to and allocatio=
n from" - if I leave those blank, are we allowing people to transfer to/fro=
m 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 (o=
r allow to anything).

4) ?

If our system cannot connect to university financial system, there's no=
reason to add in all of the statuses. It can be important to include all o=
f the statuses when a payment can involve many people/departments.

Authorization step is required for auditing purposes.

We electronically feed invoices each day in a batch at the end of th=
e day, from the Voyager invoice data file to the financial system.

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 p=
ermission restrictions because there could be serious ramifications, especi=
ally 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 e=
ntire finances module, departments in same institution would share statuses=
, at least initially, though different ledgers could have different setting=
s.

If you allow for multi-line POs, you aren't precluding those that use t=
hem. 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 no=
t require extra clicks for those that do not use them.