There can be a number of valid limitations preventing person merges and deletes and should really be shown as a validation warning and not an error.
You can find more general information about merge person functionality, including prevention criteria, in our merging duplicates guide.
Common finance-specific merge errors
Person has failed because person have delivered actuals.
For example, Person 816581 has Delivered Actuals.
Person is an allocated Party in Case package for another person.
For example, Person 1216594 is an allocated Party in Care package for 1216593.
Person has invoices.
For example, Person 123456 has Invoices.
Person is made an Allocated Party
Person 609212 is Allocated in Element Changes
For example, 'Person 104575 has an incomplete Personal Budget on 'Personal Budget''
For example, 'Person 630478 has a one Financial Assessment of type ‘Non Residential’ that conflicts with target person'
A known issue - Empty Care Package Changes
In the majority of cases where a validation error has been shown that will in of itself be a valid cause for any merge to go ahead.
There is a known exception to this that has been fixed in Mosaic 22.2.4.3, where a purchase step is used by a worker, but the step is empty of any finance. In this case, when the step is completed, there will still be an entry written to the care_package_changes table in the database which shouldn't be as there was no finance on the step, but the step was still a designated purchase step.
This can also occur when the Abandon all proposed Purchase Changes next action is used to abandon the care package within a finance step.
The person may actually have no finance at all to their name apart from this one empty entry in a finance table.
When the merge process is underway it scans all the relevant finance tables to check if a person has finance, and when it checks the care_package_changes table and finds this entry, is therefore confused into thinking that this person has finance even when they do not. The merge process will then fail.
If you have gone to a relevant article for your merge person finance specific error and have either been unable to find the data on the front end, and support cannot find any evidence of the relevant error data, then to overcome empty care package data (if identified as the cause) and you are not on the fixed version yet, the support team will need to run a script that can backup and remove these empty rows from the table, and will do so in bulk so that any other person affected will have this resolved without further incident. For self-hosted customers, we can provide this script on request via a raised case.
Until you are on 22.2.4.3 or above, it will continue to be a scenario that can be created by workers in the ways listed above, and one for which they should be made aware of.
The release notes for 22.2.4.3 for this issue can be found on Page 17 of the knowledge article titled:
📌Note: To access the link, you'll be redirected to the Access Portal.
Further Information
Mosaic will not allow the deletion of financial data that fits the merge prevention criteria so you will need to see the Options section below.
When planning for the delete person with finance functionality, we also looked at merging records containing finance data.
Although we recognise that this would be a really useful piece of functionality, it is extremely complicated as it would have to check for a lot of potential problems, such as overlapping payments or purchases, budgets, clashing carer records, etc.
If we did decide it was feasible, it would take a large amount of time to complete, and although progress has been made on deleting persons with finance functionality in 21.1, at present we do not have a plan for merging records with finance in the near future, although it is a requirement we are still aware of and will continue to evaluate against other items in our backlog. Even on 21.1, merge and delete prevention criteria would apply.
Options when you legitimately can't merge
The advice from our Product Team on the deletion of person records with finance introduced in Mosaic 21.1.0.0 and in general, is that the restrictions around this are to ensure finance data is retained, as required by law, for six years.
Where there is a reason to remove the personal data on these cases, you may want to consider restricting a case that has not yet reached the six-year stage and then scheduling delete following that time.
You can also delete workflows, attachments, and case notes etc. from the case where these do not relate to the finance recording.
Our understanding is that the requirement for retaining finance information is a valid reason for retaining personal data, but that it should only be accessible for that purpose, hence we would recommend restricting the case so that the information cannot be viewed by other users during that time.
So in the case of for example a delivered actuals validation, you could try and see if this will merge in the other direction, but if not you may have to make clear on one of the records that the other person ID is to be used going forward, and could even look to restrict the record you do not want workers to be working on.