Ability to stop Financial regeneration process on benefit case suspension and un suspension

Hi Manisha,

We have reviewed your enhancement suggestion.

Based on the information provided, our understanding of your request is as follows:

You are requesting that a configuration option is provided in product that can be used to stop the financial regeneration process for benefit product delivery cases when the cases are suspended and un-suspended.

In product when a case is suspended and then un-suspended, aside from the potential initial adjustment of the financial components at the time of case suspension based upon the value of the 'curam.miscapp.payuptosuspendeddate' application property, no financial regeneration or creation of payment correction cases occurs until the case is once again activated.

We have also not been able to recreate the issue you are seeing due to the nature of the product you have configured.

Based on the above, we are closing this request and do not plan to take any further action.

Thank you for taking the time to share your ideas with us. We are committed to involving our users in building our product roadmap and appreciate your suggestions.

Regards,
Sheryl Brenton, SPM Product Management Team

Hello Sheryl,

Thank you for taking time to look into the request. I have outlined responses to your questions below, please let me know if you need anything else from my end.

(A1) I had asked for a configuration because we seem to have a defect 'unwanted creation of overpayment and underpayment' on case suspension and un suspension respectively. I have also created a PMR for this defect WH00012454.

We do not pay pro rated benefit amount based on payuptosuspendeddate property for our custom benefit product(hence we have set the property 'curam.miscapp.payuptosuspendeddate' to 'NO'.) with only a yearly pattern defined. It's a one time benefit payment to be paid out in 2 installments and thus, we have 2 financial components defined to be paid out in 2 installments/payments that are governed by benefit product rules in our custom implementation.

Since we have turned off property 'curam.miscapp.payuptosuspendeddate', we think it should also stop financial regeneration process on case suspension. OOTB code flow that's invoked on case suspension is:

ProductDelivery.suspend -> MaintainProductDelivery.suspendProductDelivery -> Performs suspend function and also does RegenerateCaseFinancialsFactory.newInstance().submitForDelayedRegeneration1 and this is the part where we could have a configuration to not regenerate case financials when project doesn't need them.

(A2) As described on A1 above, OOTB code flow regenerates case financials and creates unwanted overpayment case.

We had a similar OOTB issue that was fixed in the past - https://www.ibm.com/support/pages/apar/PO05944 but it doesn't seem to be working when we have multiple financial components.

We do not have any customization involved in this processing.

(A3) Product rules determine when the client is eligible for each component using the submission of the application for the first installment and then the application for the second installment as evidence.

Hi Manisha,

We have reviewed your enhancement suggestion and require more information to properly understand the issue you are trying to support.

(Q1) When you say that "you would like to know if it is possible to have a configuration to be able to stop the financial regeneration process for a benefit product case since you do not have a business need to run financial processing at the time of case suspension and un-suspension.", can you provide more information as to what processing you want to stop?

Below is information on what currently happens in product when a case is suspended and then un-suspended. Aside from the initial adjustment of the financial components at the time of case suspension that is based upon the value of the application property, no other financial regeneration occurs until the case is once again activated, so we would like to understand more about the business requirement that you have that you feel isn't met by the existing functionality.

(1) We adjust the financial components in line with the environment variable 'curam.miscapp.payuptosuspendeddate'. The comment associated with this environment variable is as follows 'Determines if payments should be issued up to the date of suspension when a case is suspended. Otherwise, no payments will take place after the case is suspended.' The default value of this environment variable OOTB is YES.
(2) Secondly, we can continue to make evidence changes on the case. The determinations and case decisions will be updated in line with these updates to reflect the latest eligibility and entitlement, but the financial components will not be updated. Nor will we create any over/under payments. Once we un-suspend the case (which returns it to Open), we can approve and activate it again. This will create up to date financial components as well as any outstanding over/under payments.
(3) Thirdly, the following notification is sent to the case owner when a suspended case is reassessed - 'Reassessment could not be completed on case <123> as it currently has a status of 'Suspended'. The product type is and the name of the primary client is .

(Q2) In relation to your comment of "This is unexpected and while we can work on figuring out the root cause for creation of these unwanted payment correction cases", can we confirm that you have identified that the overpayment and underpayment cases are being created as a result of specific customizations you have made rather than being created incorrectly as a result of OOTB processing?

(Q3) Could you provide us with the specific configuration details of your product in order to better understand how you have implemented a product with a yearly delivery pattern that is a one time benefit payment, but paid out in 2 installments using 2 financial components?

For example, have you set it up something like having 2 components (1st installment payment; 2nd installment payment) and then the product rules determine when the client is eligible for each component using the submission of the application for the first installment and then the application for the second installment as evidence in some manner?

Please provide the requested information within 30 days so we may proceed with our evaluation. If we do not hear from you within that timeframe, we will have to close the request due to insufficient information.

Thank you very much,
Sheryl Brenton, SPM Product Management team

Note: We have improved your RFE experience and transitioned to an Ideas Portal provided by our trusted business partner Aha!
Additional details can be found here.

Hi,

Thank you for taking the time to share your ideas with us.
We are committed to involving our users in building our product roadmap and appreciate your suggestions.
We will review the information you have provided and get back to you within 30 days.
If additional details are required in order to complete our evaluation, we will send you a request for more information.

Thank you,
Sheryl Brenton, SPM Product Management team
Note: We have improved your RFE experience and transitioned to an Ideas Portal provided by our trusted business partner Aha!
Additional details can be found here.