Functional Changes
We have continued to enhance our Revenues Process Orchestration functionality and the following updates are available now.
Change of Address
1) Intelligent Account Calculation Routines
As a part of constantly seeking to innovate and provide maximum automation we have significantly enhanced our capabilities in terms of automatically calculating accounts following the changes made by forms.
Background
When making automated updates to Northgate there are two functions that are important in the context of automating calculations. These are both powered by an API called Bill Account. The two functions are:
- BillAccount - Calculate
- BillAccount - Bill
By calling these one after the other it is possible to automatically calculate the amount of council tax due following the change and then set the account to prepare a bill for issue which changes the status from Calc_Due to Bill_Due in Northgate.
Doing these activities ensures that a customer accessing their account in OneVu can see an account balance that reflects the change they just reported immediately afterwards.
New Settings
To provide more control over the use of this functionality there are new settings.
There are two new settings related to change of address. These settings are council specific but need to be set by IEG4 staff.
Setting 1 - CoaBillingEnabled
If this is set to True, the calculate bill and generate bill steps will run wherever an account is terminated/created.
If this is set to False, the calculate bill and generate bill steps will not run wherever an account is terminated/created.
IMPORTANT
The default is False
As IEG4 set this setting, please indicate your preference when requesting the release.
Setting 2 - FailProcessDueToBenefits�
If Benefits is present on an account, a separate update is required in the benefit side of things to ensure the bill issued is accurate. This is handled in two different ways by councils.
- Some councils want to create an exception in this scenario, which requires human intervention
- Other councils automatically suppress billing where benefits is present and internal pre-existing processes handle this prior to the bill being issued.
This setting is to cater for these two scenarios.
If this setting is set to True, it will result in an error being set on the final stage of the process if the account has benefits present upon it. This error can then be used to change update made to the document management (EDMS) system. I.e. if no benefits present set the document code to COA, which the EDMS automatically completes/files. If benefits present set the document code to COA-BENSEXCEPTION, which the EDMS pushes to a work tray for an officer to review.
If this setting is set to False, the process will:
- Skip the Bill Account - Bill stage AND
- Complete the process as normal
The reason it skips the Bill Account stage is in this scenario the council is suppressing billing where benefit is present. If we tried to generate a bill it would error, as a result of this suppression, which we do not want.
IMPORTANT
The default is False
As IEG4 set this setting, please indicate your preference when requesting the release.
See Appendix A - for details of how different scenarios are handled.
2) New Suppression Type - Benefits
A new suppression type has been created which means that it is possible to suppress a council tax account when a move takes place where benefits is in place. This means that one can suppress those accounts where benefits are in place but nothing else if necessary/desired.
3) Address look up
A new address look up, integrated to Northgate in real time, has been added for any places where an address needs to be provided. For example when entering a forwarding address.
Removing the need to manually type the address out/enter it incorrectly etc.
4) Moving Within - Carry Forward Single Person Discount
On a move within the council area there is
i) An outgoing property
ii) An incoming property
The API that ends the first account on the outgoing property and opens a new account on the income property provides the means to carry forward a discount from the old property to the new account.
Because we want to actively manage this we were not using the CarryForwardDiscounts functionality.
However, it transpired that if you do not provide:
false
The API's default behaviour is to set this value to true. Therefore if a person had an SPD on the outgoing property, it would carry this over the incoming property EVEN if there were two occupants on the incoming property.
Therefore this update includes a change to ensure that SPDs/Discounts are NOT carried forward, which can cause the above issue.
5) Moving Out - Effective Dates
An important issue was identified where a person selling their property would have their liability ended from the date they moved out and not the date they sold their property if they moved out earlier.
This has been corrected so the liability is terminated from the date of sale when moving out of the property as expected.
6) Moving Out - Family Members remaining
A new scenario has been catered for. When a person says they're moving out but family members are remaining, the form will ask who they are and create a new account with them liable upon it.
7) Moving Out - Tenant remaining
A new scenario has been catered for. When a tenant says they're moving out but a tenant(s) are remaining, the form will ask who they are and create a new account with them liable upon it.
8) Moving Out - Not selling tenant(s) moving in
A new scenario has been catered for. When an owner says they're moving out but a tenant(s) are moving in, the form will ask who they are and create a new account with them liable upon it.
9) Moving Out - Contact Details
A new function has been added so that when a person moving out has provided new contact details, we:
a) Check to see if those details are already known i.e. they match what's held
b) Only append these details to the person not the details that were already held on the account.
10) Moving Out - Still Liable
It was noticed that where a person moved out but was still liable. E.g. an owner that moved out but had not sold the property and instead rented it out at a later date. The scenario was not handled fully and instead terminated their liability from when they moved out.
A correction has been so that an owner remains liable. Unless of course a tenant has moved in etc. where the liability will be ended when the tenant becomes liable.
11) Moving In - Void Prevention Change
In an earlier release we added a function designed to automatically link someone moving in to the void account if there was one currently in place on their property. This should have ONLY done this if the person was moving in on the same date as the VOID account started. Whereas the new account was being started from when the VOID account started irrespective of when they became liable.
We have therefore changed this to work as expected. I.e.
If a person states they became liable on the same date that a VOID account exists, we will update the VOID account.
If a person states they became liable on a later date that a VOID account exists, we will create a new account from the date they became liable.
12) Moving In - Occupancy Discounts
It was found that where:
- a tenant moved in AND
- where their property was furnished AND
- they moved in after the date their tenancy started
We would award an empty / unfurnished discount rather than the necessary empty furnished category.
This has been resolved in this release and now the correct empty and furnished discount category will be applied.
13) Moving In - Under 18s
It was found that where one adult and one 16-18 year old was added the customer was not awarded a Single Person Discount.
A change has been made to ensure that a single person discount is applied if only one occupant is over 18.
14) Moving Within - Tenant becoming an owner before their tenancy ended
A scenario was discovered that meant that if:
- a tenant of the old address became
- the owner of a new address prior to the end of their tenancy I.e. there was an overlap
- the landlord of the old address was made liable on the tenant's account for the overlapping period.
This has been resolved in this release.
15) New Address Look Up
We have enhanced the address look up control and this now behaves in a better, more modern, manner.
The current (now previous) version means that when you click to search for the address a loading screen is presented and each of the results are spread across pages in sets of 10 addresses:
This meant if there were 100 addresses the user might have to navigate between 1-10 pages depending upon their house number. Clearly not an ideal user experience.
Plus, the address look up was relatively slow, even when the API call was not that slow.
The new version works more smartly, as the search button changes to say 'Searching' when it is clicked:
And the a single list containing all address results loaded below when they are retrieved from the back office system. As you can see this removes the issue of having to navigate through multiple pages:
16) Improved Performance
We have enhanced how logic in the form works so that page loading and dynamic behaviours are quicker.
Single Person Discount
1) Intelligent Account Calculation Routines
As a part of constantly seeking to innovate and provide maximum automation we have significantly enhanced our capabilities in terms of automatically calculating accounts following the changes made by forms.
Background
When making automated updates to Northgate there are two functions that are important in the context of automating calculations. These are both powered by an API called Bill Account. The two functions are:
- BillAccount - Calculate
- BillAccount - Bill
By calling these one after the other it is possible to automatically calculate the amount of council tax due following the change and then set the account to prepare a bill for issue which changes the status from Calc_Due to Bill_Due in Northgate.
Doing these activities ensures that a customer accessing their account in OneVu can see an account balance that reflects the change they just reported immediately afterwards.
New Settings
To provide more control over the use of this functionality there are new settings.
There are two new settings related to change of address. These settings are council specific but need to be set by IEG4 staff.
Setting 1 - SpdBillingEnabled
For any SPD process where billing is applicable, if this is set to true, the calculate bill and generate bill steps will run where required
The transfer credit step is not controlled by this setting as it’s not new functionality.
IMPORTANT
The default is False
As IEG4 set this setting, please indicate your preference when requesting the release.
Setting 2 - FailProcessDueToBenefits (This is the same setting as for COA but not every council has both forms)
If Benefits is present on an account, a separate update is required in the benefit side of things to ensure the bill issued is accurate. This is handled in two different ways by councils.
- Some councils want to create an exception in this scenario, which requires human intervention
- Other councils automatically suppress billing where benefits is present and internal pre-existing processes handle this prior to the bill being issued.
This setting is to cater for these two scenarios.
If this setting is set to True, it will result in an error being set on the final stage of the process if the account has benefits present upon it. This error can then be used to change update made to the document management (EDMS) system. I.e. if no benefits present set the document code to SPD, which the EDMS automatically completes/files. If benefits present set the document code to SPD-BENSEXCEPTION, which the EDMS pushes to a work tray for an officer to review.
If this setting is set to False, the process will:
- Skip the Bill Account - Bill stage AND
- Complete the process as normal
The reason it skips the Bill Account stage is in this scenario the council is suppressing billing where benefit is present. If we tried to generate a bill it would error, as a result of this suppression, which we do not want.
IMPORTANT
The default is False
As IEG4 set this setting, please indicate your preference when requesting the release.
2) New Suppression Type - Benefits
A new suppression type has been created which means that it is possible to suppress a council tax account when an SPD takes place where benefits is in place. This means that one can suppress those accounts where benefits are in place but nothing else if necessary/desired. This can be done separately for each SPD scenario.
3) Real-time check on account start date
Sometimes people applying for an SPD say they want the discount from a date before the account was even open.
Therefore, prior to this release, when we attempted to automate the SPD we were told by the back office council tax system that the account is not open on the date the SPD is being applied for. Causing the process to fail.
We've introduced a new function, which will automatically check whether the person's account is open on the date from which they want to apply for the SPD. Meaning the customer is alerted to this prior to submitting the SPD and are able to correct the date to be from or after the date they became liable.
4) Recovery checking when cancelling an SPD
When a person cancels an SPD (and therefore someone has moved in), the account in place is terminated and a new one created in the name(s) of the people moving in and the current resident. As this new account will always have the recovery stage of Bill, it will be possible to set up a Direct Debit.
Prior to this release there were circumstances where we prevented a DD being created on the new account owing to recovery checks taking place on the account that is terminated. This has now been enhanced to not do this check here and thus enable DD to always be set up.
5) New Address Look Up
We have enhanced the address look up control and this now behaves in a better, more modern, manner.
The current (now previous) version means that when you click to search for the address a loading screen is presented and each of the results are spread across pages in sets of 10 addresses:
This meant if there were 100 addresses the user might have to navigate between 1-10 pages depending upon their house number. Clearly not an ideal user experience.
Plus, the address look up was relatively slow, even when the API call was not that slow.
The new version works more smartly, as the search button changes to say 'Searching' when it is clicked:
And the a single list containing all address results loaded below when they are retrieved from the back office system. As you can see this removes the issue of having to navigate through multiple pages:
Form Versions
The following are the latest versions of the integrated revenues forms that complement this version of the Revenues Orchestration API 1.1.
Change of Address
The Latest Form Version Number needed is: 3.3
Single Person Discount
The Latest Form Version Number needed is: 1.3
Direct Debit
The Latest Form Version Number needed is: 2.3.8
Discounts & Exemptions
The Latest Form Version Number needed is: 1.0.13
Appendix A - COA Settings
This appendix walks through different COA scenarios and the behaviours that take place in the process based upon the way the settings have been configured.
1) Move in – incoming property (there benefits not possible)
Where someone moves in for the first time there is no benefits so the end of the process of moving them in will do these three steps:
|
Calc Bill |
|
Gen Bill |
|
Add notes |
2) Move out
Where someone moves out the behaviour is different dependant upon whether this setting:
FailProcessDueToBenefits
Is True or False
This table shows the behaviour after all other activities have taken place where it is set to the two different options:
|
False – No Benefits |
False - Benefits |
True - No Benefits |
True - Benefits |
|
Calc Bill |
Calc Bill |
Calc Bill |
Calc Bill |
|
Gen Bill |
|
Gen Bill |
|
|
Add notes |
Add notes |
Add notes |
Add notes |
|
|
|
Suppress |
Suppress |
|
|
|
|
Cause fail |
NB - the Suppress stage will only occur if the council has also chose to suppress all move out processes or those where benefits are present.
3) Move within
Where someone moves within the council, the behaviour is different dependant upon whether this setting:
FailProcessDueToBenefits
Is True or False
This table shows the behaviour after all other activities have taken place where it is set to the two different options:
|
False – No Benefits |
False - Benefits |
True - No Benefits |
True - Benefits |
|
Outgoing property |
|||
|
Calc Bill |
Calc Bill |
Calc Bill |
Calc Bill |
|
Gen Bill |
|
Gen Bill |
|
|
Transfer Credit |
|
Transfer Credit |
|
|
Incoming property |
|||
|
Calc Bill |
Calc Bill |
Calc Bill |
Calc Bill |
|
Gen Bill |
Gen Bill |
Gen Bill |
Gen Bill |
|
Add notes |
Add notes |
Add notes |
Add notes |
|
|
|
Suppress |
Suppress |
|
|
|
|
Cause fail |
NB - the Suppress stage will only occur if the council has also chose to suppress all move within processes or those where benefits are present.
Appendix B - SPD Settings
This appendix walks through different SPD scenarios and the behaviours that take place in the process based upon the way the settings have been configured.
1) SPD - Should have always got
Where someone applies for an SPD because they always should have had one, the behaviour is different dependant upon whether this setting:
FailProcessDueToBenefits
Is True or False
This table shows the behaviour after all other activities have taken place where it is set to the two different options:
|
False – No Benefits |
False - Benefits |
True - No Benefits |
True - Benefits |
|
Calc Bill |
Calc Bill |
Calc Bill |
Calc Bill |
|
Gen Bill |
Add notes |
Gen Bill |
Add notes |
|
Add notes |
|
Add notes |
Suppress |
|
|
|
Suppress |
Cause Fail |
NB - the Suppress stage will only occur if the council has also chose to suppress all SPD (Living Alone already) processes or those where benefits are present.
2) SPD – someone moved out / died / moved in
Where someone:
- applies for an SPD because someone moved out/died
- cancelled their SPD because someone moved in
The behaviour is different dependant upon whether this setting:
FailProcessDueToBenefits
Is True or False
This table shows the behaviour after all other activities have taken place where it is set to the two different options:
|
False – No Benefits |
False - Benefits |
True - No Benefits |
True - Benefits |
|
Old account |
|||
|
Calc Bill |
Calc Bill |
Calc Bill |
Calc Bill |
|
Gen Bill |
|
Gen Bill |
|
|
Transfer Credit |
|
Transfer Credit |
|
|
New account |
|||
|
Calc Bill |
Calc Bill |
Calc Bill |
Calc Bill |
|
Gen Bill |
Gen Bill |
Gen Bill |
Gen Bill |
|
Add notes |
Add notes |
Add notes |
Add notes |
|
|
|
Suppress |
Suppress |
|
|
|
|
Cause fail |
NB1 - the Suppress stage will only occur if the council has also chose to suppress all of the above SPD processes or those SPD processes where benefits are present.
NB2 - these are separate scenarios but logic for these are the same