Is it ok if we enable Ability To Pay validation for Reserve creation or is it only for Payment. Any performance or upgrade issues if we invoke Ability To Pay validation for Reserves in Claim Center?
In our project ATP validation is done before Reserve creation itself.
If I understand the requirement correctly, it is to not create reserves unless the Exposure/Claim is at the ability to pay validation level, one approach could be invoking the exposure.validate(false) function in the Rule Condition while creating reserves. It's important to wrap this invocation in a try/catch block to handle cases where lower validation levels are not being passed.
It's worth noting that this approach may have some impact on performance since the validation rules will be executed twice for each entity. Although the impact on the out-of-the-box (OOTB) configuration is minimal due to the efficiency of the rules, it could be different for customers with more complex validation logic. The impact on upgrades should not be a concern since this would be invoked from Reserve Rule condition.
That said, the requirement itself seems a bit unusual. It's possible that it is driven by integration or reporting needs. If that's the case, it might be more appropriate to check the AtAbilityToPay flag in those specific areas rather than invoking the validation rules twice.
Considering the potential impact on performance, it's worth discussing alternative solutions that might better align with the specific needs of the integration or reporting requirements.