Documentation
📌Note: To access the guide, you'll be redirected to the Access Portal.
You may find more documentation on the FABU process below and this is one of the pages from the Chapter 9 Financial Assessment Batch Uplift section MosaicFinance
Below are some issues that may be seen with FABU process:
Service Users not appearing on FABU
There are some circumstances where Financial Assessment Batch Uplift (FABU) doesn't pick up all the candidates you would expect to see for inclusion in a FABU run.
The main case is for persons who have been merged, and this is something that FABU doesn't handle well at present.
When FABU comes up to against a merged person record, it cannot proceed because it cannot work out which person of the two needs the uplift. The FABU process effectively automates what a worker would do by adding a new form for a Person only if there is nothing to cause it confusion and everything has been mapped out properly from on Financial Assessment (FA) form to another.
A human worker would know which of the two merged persons they mean to get the new year's FA form, but the FABU automation will not. In these cases, there is a script which we run against the database to find out which person FABU is stuck on due to merges. Once that person is noted, a worker would go into Mosaic and add an FA Form manually to the person.
Next time FABU is ran, it will not be unsettled by that person anymore as it will see that it already has a recent FA Form and just go to work on the next person in the run.
Report to identify persons
You can find the script below to identify which persons a FABU batch ignored below. Just amend it at the beginning with the Batch ID you're interested in. You can run it in a database or local report. The column headings should hopefully explain which persons were excluded from the batch at that time and why.
/*
* address: service_users_not_in_fabu_batch_ss.sql
* DESCRIPTION: Package to collect MIV data and format into XML
* HISTORY: 1.0 gk 23/02/2022 Created
*
* SQL to get batch schedule ID to include in query:
select
fbs2.form_batch_schedule_id
from
mo_form_batch_schedules fbs2;
*/
declare @v_batch_id numeric(9);
--
set @v_batch_id = **AMEND WITH THE ID OF YOUR FABU BATCH**;
select
mp2.person_id,
case when mp2.date_of_death is null then 'N' else 'Y' end has_date_of_death,
coalesce((select 'Y'
from mo_persons mp3
where mp3.person_id = mp2.person_id
and exists (
select 'x'
from mo_person_merges mpm
where mpm.merge_to_person_id = mp3.person_id
)
),'N') is_merge,
coalesce((
select distinct 'Y'
from mo_forms mf
inner join mo_subgroups ms
on ms.subgroup_id = mf.subgroup_id
where ms.only_subject_compound_id = mp2.person_id
and ms.only_subject_type_code = 'PER'
and mf.template_id = (
select
fbs2.previous_template_id
from
mo_form_batch_schedules fbs2
where
fbs2.form_batch_schedule_id = @v_batch_id
)
and mf.finished_on is not null
), 'N') has_old_complete_form
--6) No Service covering FABU Service date
/*coalesce(
(select distinct 'Y'
from care_packages cp
join package_services ps on ps.care_package_id = cp.id
join elements e on e.package_service_id = ps.id
where fbd.applicable_from_date between e.start_date and mosaic_dates.future(e.end_date)
and e.cancelled_on is null),'N') has_services_on_FABU_date*/
from mo_persons mp2
where mp2.context_flag = 'A'
and mp2.person_id in (
-- list of people with active packages
select distinct cp.person_id
from care_packages cp
join package_services ps on ps.care_package_id = cp.id
join elements e on e.package_service_id = ps.id
where getdate() between e.start_date and mosaic_dates.future(e.end_date)
and e.cancelled_on is null
)
-- list of people processed in FABU batch
and mp2.person_id not in (
---------------------------------------------------------------------------------------------------------
select
mp.person_id
from mo_form_batch_details fbd
inner join mo_form_batch_schedules fbs
on fbs.form_batch_schedule_id = fbd.form_batch_schedule_id
--
inner join mo_subgroup_subjects mss
on mss.subgroup_id = fbd.subgroup_id
and mss.subject_type_code = 'PER'
--
inner join mo_subjects msj
on mss.subject_compound_id = msj.subject_compound_id
and mss.subject_type_code = msj.subject_type_code
--
inner join mo_persons mp
on mp.person_id = msj.person_id
--
where
fbs.form_batch_schedule_id = @v_batch_id
and
--CONDITION: Assessment Status
fbd.status in ('PENDING','COMPLETED','EXCLUDED','FAILED') -- Pending/Excluded/Failed/Completed
----------------------------------------------------------------------------------------------------------
)
order by mp2.person_id;
Why does the FABU (Financial Assessment Batch Uplift) Results report contain incorrect financial representative contact details?
This is something that should be rectified across all our customers as we proactively informed and raised cases with all our customers. However, if you do pick this issue up then please visit the KB titled:
Mosaic: Person Relationship Sequencing issue causing duplicate IDs
When creating a batch, why does FABU populate some service users twice or multiple times?
This is a known issue that will require a code change in a future release of Mosaic to resolve. This is more a user interface bug that shows the worker more lines for a given person then it should. However, this will not duplicate any forms when FABU is run so is safe to test and run your FABU as you normally would for these duplicated service users. It's just a bug on the views screen.
When running FABU, the financial assessment results have not pulled through to the Financial Assessment Results screen (FAR screen)
There may be an issue with your form if it is not a clean CLC FA Form which is tested amongst all our customers and issues fed back during Beta testing. See article Request the new CLC financial assessment form for more information.
If your FA form has been written bespoke by Access Group Forms Developers or you have made local modifications at your site to the Form then that may impact how the form performs when used, either in the FABU process, or as a standalone Form, or as part of workflow.
Aside from there being any inherent form issues as described in the proceeding paragraphs, the mappings on your FA form may be missing and it is these mappings which allow the old form to bridge to the new form, and then following completion of that form by the automated FABU process these results then drive the population of the FAR screen.
With regards to mappings to check what you have, these are found in Template Manager linked to the FA form that FABU will be linking towards.
To navigate: Tools menu > Configuration Tools button> 'Form/letter templates' to bring up Template Manager > Search for your relevant Financial Assessment form > Click paper icons at the right hand side to go inside that chosen form > There will be an icon at the top which is for Financial Assessment Mappings that take you to the screen where you can add what is needed.
You may also get a steer of the kind of mappings you need from the last FA form you were using by looking at how that was configured.
As said above, it's the mappings that are ascribed to the FA forms that will drive what goes on to the FAR screen. This would be the starting point during testing.
Lastly, if you have ruled out mapping and form build as an issue, you will want to look at the individual service user which did not have their results populate. You may have seen on the FABU report a service user has COMPLETED (and they do have a form on their Documents section so FABU creating a form has been a success) but that there are no results in the report fields (and so requires a look into why that was).
FABU takes the last completed form for the service user of the template that you are pulling forward from. On the Documents screen from the Person Summary screen you will see the created on date of these FA forms, however it does not show you the date that these FA forms were completed and so what looks like a chronological date order of creation may hide that the action completion dates of the forms came on different out of sequence dates.
If the service user has more than one form from the previous year then the new year form in FABU will pre-populate with the last completed of the old year and if for example that was Respite (when you were expecting Non-Residential), then FABU will create a form with Respite assessment. You will need to either make sure that the service user has a new Form added for the previous year with the assessment you expect to see prior to the FABU run so that the new year form picks up the same assessment type to assess, or if FABU has already been completed to create a new FA form manually for that person so that they will be assessed with the correct assessments on that form which will drive the results you want to the FAR screen.
When running FABU, the batch takes a long time and then has a status of PROCESS_IDLE
Due to the length of time this process is running, the batch can sometimes crash midway through and show you on the batch details screen as having a status of PROCESS_IDLE. If you run the FABU report for the batch ID for those COMPLETED, you will be able to see those persons in the list who that batch did manage to get around to creating a new FA form for.
You can verify that by taking a service user from that report, visiting their Person Summary and Documents screen, and you will see that the new FA form is in that screen (when you open the form it will say at the top the words 'Assessed by automatic uplift (FABU)', and visiting the FAR screen that the new assessment results have populated there.
If from your batch you had a completed count of 2052 those would have produced as described above for those persons, and if you had a pending count of 2206 still remaining on the crashed batch then our advice is to terminate that batch and kick off a new batch. As the 2052 persons from the initial batch had forms and results created, FABU skips any person who already has the form. Therefore, by kicking off a new batch, FABU would just process any remaining people who were pending (providing you don't deliberately exclude them from the batch run).
When running FABU, I have noticed my Portal forms have not come through
Customers who use Portal may notice that when running FABU in testing or running FABU in live that portal forms may not come across to Mosaic straight away. The forms should come through once you have completed running FABU. This may take a little longer than expected please give it a few hours depending on the volume of forms published during this period.
We would advise to keep an eye on the morning reports sent by PPL as well as checking the front end of portal the following morning to confirm these forms have all come through. Please make Portal users aware of this where possible, look out for any Portal forms that have not come through after FABU testing as above, and log a case for the support team to review where this has occurred and still not arriving.
Multiple errors in the Framework logs relating to invalid characters
An example of this would be
'ERROR uk.co.corelogic.mosaic.application.finassess.service.form.FinancialAssessmentResultsRecorder - The amount specified: Not Assessed contains invalid characters.
ERROR uk.co.corelogic.mosaic.application.finassess.service.form.FinancialAssessmentResultsRecorder - The amount specified: Not Applicable contains invalid characters.'
As FABU makes a list of all the service users that you have chosen to include from the outset of the batch it then goes about looping through each service user one by one to create a Form.
For Assessments that a service user has ticked on Section 1 of their form to be assessed on there will be a value that drives to the Section 9 assessment results that is inserted into a table called mo_form_contrib_assessments as a value.
The errors that look like the ones above are the Assessments that are not ticked for assessing the service user and there for the Service User in their FA Form's Section 9 Assessment Results comes out as 'Not Assessed' for example.
This value is also put in the table mentioned and next to it will have a status_code of FAILURE which is ok as it was not being assessed for and so this isn't wrong in the form, but it just appears as an error in the logging but nothing to be concerned with.
The FABU report is not returning results or is timing out
We are aware that in some cases users may find difficulty when running the FABU report.
We are aware of a scenario where the Manual Assessment Flag is set to 'Yes' or 'No' that the report may return empty but does return results when the option is set to 'All'.
You may also have issues with timeouts or has an error screen that refer to 'Data Sources' which can occur for a number of reasons. For time outs, the system in general may be working at high load due to workers' usage, so try other times of day also and if your site is set up for log shipping then try and avoid the times that this process will be adding additional load to the system by it's very nature.
If you do see any of the above are still an issue, please raise a case with us to investigate further, describing the situation, the parameters, and the environment you are using.