Roll Cost Forward is an annual process that updates your site's current financial year to point to the upcoming financial year, usually between January and early March.
Mosaic blocks Roll Cost Forward from running before January 1st. You can run it any time after that, but it’s best to do it well before the new financial year so all systems are ready for users. In other words, you can run Roll Cost Forward up to three months before April 1st, but no earlier.
The Roll Cost Forward procedure updates purchases and adjusts the screens that show this years and next year’s costs.
For example, if today’s date is March 20, 2024, and the database still has 2023/24 as the current financial year in the finance_control table, then when the new financial year rolls over on April 1, 2024, your site will still reference 2023/24. This will cause issues with how costs display in the front-end views.
Regarding payment cycles, we previously said in this article that not running roll cost forward “would even prevent you from creating a payment cycle with a period end date outside the current financial year,” with the validation message shown below. We’d like to clarify that this isn’t the case:
'The period end date of a payment cycle must be before the end date of the active budget years.'
For a future payment cycle, you just need an active calendar, which means entering that year’s bank holidays and activating the calendar.
Back to how costs appear in the care package views: some customers have thought that activating a calendar for the correct financial year was enough. However, activating a calendar year doesn’t tell the database which financial year is current. Only a roll cost forward can do that.
To update your site to the correct financial year, our support team must assist you. Please raise a new case online and reference this article’s title.
The Roll Cost Forward Process
You’ll need:
A test environment to run the procedure first.
An active calendar for the upcoming financial year, including all bank holidays (and any used for rates purposes). Please see the 'Final Word' section below about Calendars.
Our support team will then:
Check the finance_control table to see if you need a roll cost forward as you may already have the new year as the current year in which case all will be good.
Should roll cost forward be needed, our Engineer will run the procedure for you on your test database.
📌Note: For Prod, the procedure will be run out of business hours.
Our support team will:
Check the finance_control table to see if you already have the new year as the current year.
If Roll Cost Forward is needed, run it on your test databas.
📌Note: For production, we run it outside business hours.
You’ll then be asked to check:
Rates and costs display correctly on a couple of care packages of your choosing when purchased for the upcoming year.
You can run a test cycle with the period end date in the new financial year, and costs appear correctly.
Additional testing you could undertake:
If you have an age-banded rate, for example a 15-year-old on a £10 rate who should move to £15 when they turn 16 in the upcoming financial year, check that the new rate appears correctly in the purchase screen. When you run a payment cycle that includes this person, make sure the rates show correctly on the PDF outputs.
Double check the cost tab screens on the care package and totals screen that the dates and values look as expected.
Once everything looks good and you’ve notified us, you’ll repeat the process on the production instance, activating the upcoming year’s calendar if needed, and we’ll follow the steps above. To reiterate, we run Roll Cost Forward on live outside business hours, usually overnight or after 6 PM, and we’ll agree on the timing together in the case ticket.
📌Note: To access the below link, you'll be redirected to the Access Portal, then please download the PDF file.
Further reading on Roll Cost Forward (Chapter 20) can be read here: Mosaic Finance
Why have Access stopped automatic yearly database jobs for Roll Cost Forward taking place, and now require a case to be raised
We have had issues with the automation of roll cost in previous years and so have requested that customers raise manual requests with us to have them done.
The troubles we would be seeing would be roll cost forward configured to run daily in some case and if there were two future calendars activated that would do them both on consecutive days putting the customer in the future in their current financial year.
Or the roll cost forward happening with a customer realising afterwards that they were short/incorrect of bank holiday dates for their configuration and that would then need manual database extraction of all the commitments and then repurchasing everything.
Or persons would leave their LA/business and then be unawares as to the state of when roll costs are being ran automatically etc.
So at present it's safest that we can take a service request and some quick testing in so that we can get one done on test and one done on prod and be in control of the process, guiding customers who are less familiar with what considerations they need prior to roll cost, and ensuring all goes right.
Final word: Calendars
Having an active calendar is for “paying”.
You can activate calendar years at any time, and it doesn’t affect client data. However, roll cost forward changes what shows on the screens for this years and next year’s costs.
It’s best to set up a calendar year and bank holidays (if used) for the next year and the year after before running roll cost forward. But you don’t need to make the year after next active, since the system works out the costs for that year automatically.
⚠️ Important: An active calendar cannot be amended once it is current.
In 2022, customers thought they’d configured all the bank holidays for the year, but the Queen’s unexpected passing added an extra one, and they couldn’t amend their calendars to include it.
Our SQL team had to provide a manual solution by inserting the bank holiday date, rolling back all purchase commitments for that year, and re-committing them to account for the extra bank holiday.
The Access Group didn’t charge customers on that occasion because the situation was completely unforeseeable, but please be careful not to make next year’s calendar active too early. Wait until the bank holidays for the year are reasonably known and account for possible changes from the Government.
Customers who activated a calendar in August 2022 had to pay for work when the King’s Coronation announcement added a May 2023 bank holiday in November. Our SQL developers had to manually fix calendars that were activated too early, while customers who hadn’t activated their calendars yet could make the change themselves.