UXPROD-3256 - Getting issue details... STATUS
May require another feature for paying against upcoming fiscal years depending on the scope of work required to accomplish both
Problem(s):
- Not everything is paid and resolved before the Fiscal year period ends. This leaves the library with commitments that need to be resolved but should not be resolved in the current fiscal year as they were committed to using monies from the previous fiscal year.
- It is possible that budgets from the previous fiscal year don't exactly balance with the university accounting system after rollover has been completed. Libraries need a mechanism to correct these balances financials are archived correctly.
Use Cases & Requirements:
| Legend |
| Scope may require separate feature |
Requirement | Status | Use cases |
|---|---|---|
| Post-payment | ||
| Allow user to note the purpose of the invoice being paid against a previous year | VERIFIED | 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. |
VERIFIED | 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 | VERIFIED | 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. | VERIFIED | 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 | VERIFIED | 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 users to edit encumbrance values on previous fiscal years. Possibly by adding a new total to the encumbrance that can be edited. | DEFERRED | 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 | DEFERRED | We may need to adjust appropriations if something was missed, and not noticed until the fiscal close. |
| Pre-payment | ||
PENDING | >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. | |
PENDING | Pre-payment invoices are primarily created manually but some vendors will share these invoices via EDIFACT | |
PENDING | Credit invoices could be required for these prepayments but the majority of the time any credit would be processed once that year actually begins. | |
PENDING | 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. | |
PENDING | 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. | |
PENDING | 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. | |
PENDING | Budget allocations for the coming year are not likely known at this time so budget restrictions would not be helpful. | |
PENDING | 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. | |
PENDING | Helpful to be able to filter for all prepayment invoices within a set of other criteria | |
Proposed workflow:
Allow users with the correct permission to select a fiscal year for processing.
Questions:
Question | Status | Conclusion | Comments |
|---|---|---|---|
| How does this impact the Voucher? Are their specific use cases for transferring this information to the financial system? | ANSWERED | Voucher generated and exported with next batch export unless Export to accounting flag is False. By default it should be false | |
| Do users need to be able to select any previous fiscal year? | ANSWERED | Limit selection to previous fiscal year based on associated Funds. | Perhaps Fiscal Years should have an Open/Closed boolean, indicating whether transactions can still be run against them. Then only Open fiscal years (past, present and/or future) could be selected. |
| Should users be able to select any future fiscal years? | ANSWERED | The problem is not allowing users to actually pay the invoices in the future year. Ideally there is a way to help users keep track of what fiscal year future invoices need to be paid in for these unique scenarios. Separate feature | For some Vendors, GBV will begin to receive invoices at the end of the fiscal year. We would add those invoices but not approve them until the next year. Occasionally we prepay for a number of years (Eg 3 years) but the invoices need to be paid in each year to account for the "Expenditure value" in each year. |
| Should users be able to encumber money against future fiscal years? | ANSWERED | This is a budgeting and forcasting problem. Users want to be able to see what is already committed for next year to help budgeting. Separate feature | Want to discuss this in the context of the proposed approach to be sure we aren't limiting our options for satisfying those other requirements. We may order something for which we get a set price for a number of years. For these orders, we would want the encumbrance in each fiscal year to help with budgeting. This also reminds users to process invoices in the correct years You may acquire content that has an annual fee associated with it. This fee might be delayed for the first few years etc. |
| What dates should be associated with the transactions. The current date or a date in the selected fiscal year? | ANSWERED | 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 desired fiscal year |
Functionality Potentially Impacted by Changes:
Functional area | Records | Potential impact | Suggested Regression Testing |
|---|---|---|---|
| Orders | Orders and order lines, encumbrances, pending payments, payments/credits | Approving and paying invoices for past years may update the wrong encumbrance Or it may change the statuses of the purchase order. | Test how orders line statuses behave when paying an invoice for the past year. It should not change. |
Work Breakdown Structure: