Dedrems are generated at claim Submit... then regenerated each time the claim valuation changes:
during claim (batch-)processing,...
Today the dedrems re-creation don't deletes the dedrems for services/items switched to rejected status by reviewer.
Claim processing should delete/recreate all dedrems.
As we have reviewed the legacy code for Nepal, the dedrems are not ‘re-created’ but updated (there are no duplications). Also, the dedrems are blocked at the claim submission only in Nepal, and is not the case in the Master Version.
can you confirm this?
The process_dedrem that comes from the uspProcessSingleClaimStep2 actually does DELETE FROM tblClaimDedRem WHERE ClaimID = @ClaimID and proceeds to recreate it.
In the original code, the dedrem was only created in the claim process step but we added this to the claim submit step. Nepal had a customization in place to delete the dedrem before that step2. This allowed claims that had been rejected and would therefore never have reached step2 not to have a blocked dedrem entry.
Rather than relying on that deletion, I tried to integrate the dedrem update when the review is delivered.
I still have some doubts on the exact case and how it differs from the suggested solution. I’ll update accordingly shortly.
I changed the assignee and state of this ticket. Please confirm the right values.
Puru’s original issue is that they had a customization in place as highlighted here:
The RtnStatus 2 from step 1 is when all the claim items and services have been rejected. In the stock version and the current openimis, it won’t go to the next step and therefore won’t delete/insert dedrem. However, since dedrem was already computed when the claim was submitted, the dedrem is still present even though the claim was rejected and therefore the insuree has blocked amounts.
However, while investigating this issue further, I have identified another issue that is preventing the rejected claim from being properly rejected and deleted from dedrem. I’m updating the PR with it.
I have updated the PR. After adding another test, I was able to identify that the issue was not only about deleting the dedrem but also the fact that in those circumstances, the second validation of the claim on at process step 1 was in fact resetting the review rejection to PASSED.
The validation was taking `claim.rejection_reason = None` as default and going through all items and services regardless of their status.
I have added the test illustrating those issues and fixed the validation. was able to verify that it worked.