This issue affects only SQL Server customers and will be fixed in a future version of Mosaic.
The issue occurs when multiple element_suspensions are updated at the same time; the trigger runs for only one of the records.
For example, if an element is cancelled, all the suspensions linked to it are also cancelled, or at least that's what's supposed to happen. However, the trigger calls the p_cancel_suspension_variations procedure for only one of the records instead of all of them individually, so the linked contribution commitments are still active.
This leaves a shortfall in the number of suspensions that were supposed to be cancelled commitments (due to ended or cancelled elements) but were not.
The net effect is that the payment cycle tries to claw back monies paid out to suppliers that should never have been paid, as the element is deemed cancelled. The billing cycle inadvertently tries to refund service users who it assumes would have contributed to the cost of their care for the elements purchased for them, without cross-referencing the fact that these elements were marked as suspended at the time and should just be cancelled as well.
Another scenario could be that you updated contributions for an old contribution element that you had your suspensions tethered to. When you completed the new assessment, the new contribution elements would have been regenerated. When a new contribution element is created, it doesn't check if the provision element is suspended. So, the suspensions don't get added across.
You can resolve this in one of two ways:
Manually via the worker
Go into the care package screens.
Add in suspensions manually for each person.
Generate contributions on a one-to-one basis for each person.
After generating contributions, double-check the suspensions.
Check if any manual additions are required.
📌Note: This process is typically needed for auto-contributions. Customer feedback indicates that the FABU process copies across the suspensions, whereas the manual process does not.
Fix Script
We have a fix script that can identify all persons where this has occurred. Once this list is passed to you, you can choose whether to fix all the records identified or only fix those which were ended or cancelled from a certain date. They will be easily identified from our cancelled_on and ended_on columns.
We can then run the fix after setting the date parameter for when you'd like the fix from, if desired, or alternatively, this can also be run as is, in which case all the pending suspensions will be fixed.
Please raise a new case online and reference the title of this article if you need any further assistance with any of the information described above.
Language