| Post-payment |
|---|
Allow user to note the purpose of the invoice being paid against a previous year
| | At Duke we don't run the rollover process until 2-3 weeks after the last day of the FY so we can wrap up and reconcile the prior year against our university AP system. Not processing new invoices for purchases but making adjustments like exchange rate discrepancies. This is done to reconcile the ILS with the AP systems records. |
| Budgets may not balance with external system records because of rounding errors and exchange rate calculations. When this occurs the library will create Journal Voucher (JV) transactions to adjust balances |
| Allow user to approve and paid invoices against previous fiscal year budget for the assigned Funds | | Book was purchased in previous year and library would prefer to purchase in the same year the order was created. Could be a last minute invoice for which you need the vendor to make a correction. This might not show up until the fiscal year was closed. So you would want to process this invoice against the previous fiscal year. Rollover tends to happen around Christmas and we simply don't have the chance to process them so they would need to be processed after the rollover is done. |
| When invoice is approved for previous year the approval date and transaction timestamps should not be adjusted. They will still be the current date but the transactions will be made against the users desired fiscal year. | | After rollover we realized that things had been processed on time by AP but it wasn't recorded. In this case we need to record those payments against the previous year. In this case it didn't need to be sent to AP via voucher and the paid date would be the last day of the fiscal year. The date of the transactions is not important as long as they could against the correct fiscal year totals. |
| When paying against previous year budgets must meet spending criteria for invoice approval | | As long as the library has not frozen the previous year's budget the limits should apply. Once Frozen/closed nothing can be paid against that budget. |
| Allow user to approve and pay invoices against previous fiscal year budget for the assigned Funds. User is able to choose years as many as 5 years in the past | | LoC operate on fiscal year periods that are five years in length. Meaning every fiscal year can be active for 5 years. The money from this year is NOT rolled over but if committed during the given year it can be spent in any of the following five years. After 5 years the remaining Funds must be returned. |
| Allow users to edit encumbrance values on previous fiscal years. Possibly by adding a new total to the encumbrance that can be edited. | | After our first fiscal close in FOLIO, we have a period of about 2 weeks to make corrections and adjustments. Our numbers must match with the University numbers. To do this, we must be able to adjust expenditures by debiting/crediting in the invoice app, using the previous FY ledger. We also need to be able to adjust encumbrances in the POLs, using the previous FY ledger. |
| Allow users to increase or decrease allocations for previous years | | We may need to adjust appropriations if something was missed, and not noticed until the fiscal close. |
| Pre-payment |
|---|
| | >90% of subscription orders are paid in advance. For example, we're currently paying renewal fees for our 2022 subscriptions, ie we're making payments in our 2021 FY that will be accrued to the 2022 FY. It would help a lot if Folio allowed us to make these payments against the next FY's funds. |
| | Pre-payment invoices are primarily created manually but some vendors will share these invoices via EDIFACT |
| | Credit invoices could be required for these prepayments but the majority of the time any credit would be processed once that year actually begins. |
| | Purchase springer ebook collection and they publish starting august each year, occasionally we will pay a portion of it this year and a portion out of the next year. This is because our fiscal year begins on Jan 1. This is a lower priority as it is rare and we currently just pay these against. This could happen with renewals as well. |
| | The overwhelming majority of pre-payments are made against the next fiscal year. There have been situations where they are paid 3 or 5 years in advance but generally, these are just divided and invoiced each year. |
| | Pre-payment invoices are made in all currencies and the system will register the exchange rate at the time of approval. We don't generally update the exchange rates after but in extreme cases, this could be necessary. |
| | Budget allocations for the coming year are not likely known at this time so budget restrictions would not be helpful. |
| | Unlike paying against previous years pre-payments are part of the general acquisitions workflow. Users that are able to approve invoices should be able to make prepayments. However, we do not want people paying invoices against a future fiscal year at the beginning of the current one. We generally begin allowing users to make prepayments around August of the current fiscal year. |
| | Helpful to be able to filter for all prepayment invoices within a set of other criteria |