Provide easier extension of Bank Account and associated classes

Hi Garry,

We have evaluated your request and have determined that it cannot be implemented at this time.

The requirement while it may be used widely for your customer, is specific to your customer and is not something that any other customer would want/need so not suitable for adding to the ootbproduct.

Your request may be resubmitted for consideration after 12 months from the date of decline.

Thank you for your interest in the Cúram SPM product.
Shane McFadden, Cúram SPM Product Management team

To add more context, the initial customisation was also to add an additional boolean attribute ‘i-Movo' to the BankAccount dynamic evidence definition. i-Movo is a digital voucher system widely used in the UK. Adding a new Dynamic Evidence just to capture a single flag would have been unwieldily for case workers. The DynEvd customisation was done compliantly using a new version of the Evidence definition files.

Since OOTB there is a logical one to one mapping between the BankAccount dynamic evidence definition and the BankAccount entity, we then also added the additional boolean to the entity, which was done with both non-compliant Custom Entity extension and replace superclass on required methods

One example of our non-compliant customisation is in BankAccount entity autovalidate() method, in order that we can add ScotGov specific validations around imovo and the rest of the bank account data.

autovalidate() is called by both the insert() and modify() operations of BankAccount entity, which are in turn called by the underlying Evidence Framework on insert/modify/clone evidence.

Hence customising non-compliantly was the optimum option.

If we had gone with an option (1) of extending bank account Dynamic Evidence but 2 underlying Entities, we would have had to find a way to hook into the evidence framework and do double inserts/modifys when evidence changed - this can't be done compliantly. Also could lead to evidence broker issues as well.

Extensions to BankAccount seem to have been considered for the ‘IBAN' and ‘BIC' fields, as per https://www.ibm.com/support/knowledgecenter/SS8S5A_7.0.9/com.ibm.curam.content.doc/Participant/c_PARTMaintainingPersonProspectEvidenceBankAccounts.html.
We are looking for something similar, but generic, to allow additional flags and fields on Bank Account.

Hi Garry,

The following is a link to the compliancy guide where we document how to handle adding new attributes to entities:
https://www.ibm.com/support/knowledgecenter/SS8S5A_7.0.9/com.ibm.curam.content.doc/DevelopmentCompliancy/c_COMPDEV_Developing1EntityClasses1_605.html
Therefore can we ask why this approach isn't suitable or are you looking to add directly into the out-of-the-box entity?
It would also help if you could give us more information on the indicator mentioned; e.g. what is its purpose/use and where/how would it be populated?

Thank you,
Shane McFadden, Cúram SPM Product Management team

Hi Garry,

Thank you for your enhancement request.
We require some further analysis to determine whether or not this enhancement can be considered in a future release.
I will provide another response when our investigation is complete.

Thank you,
Shane McFadden, Cúram SPM Product Management team