I thought myself through this a bit and have some additional thoughts and
It appears the system isn’t taking into account that a 0$ payment could be
either a valid payment (where the entire amount would go to a deductible) vs a
straight up denial with reason. The difference between these is
A- An actual payment would reflect a $0 payment with an adjustment for the
B- A denial would only reflect a $0 amount absent of any adjustments as it
hasn’t been processed and have a reason for the denial.
In the case where it would not (B), it was my impression that when the “rsnd”
box is ticked it then allows the follow up field to be populated to reflect the
denial reason and when this happened the system would not mark that payment as
being paid but re-queue it to being unpaid and due. In looking at the walk
through it becomes evident that the “rsnd” box is not the mechanism that
triggers a bypass and appears to do nothing more than allowing the Follow Up
field to be populated.
I don’t know how the back end of this is constructed to say what the intention
of the rsnd/followup section was meant to do, but linking these actions might
prove to be a solution for both Ins1 and Ins2 scenarios. All this to say is
absent of affecting other areas that might be connected to these functions in
the code (ie;what might break elsewhere from re-arranging this).
As an additional thought, it might be a good idea to create a button that
directly allows a manual resetting of which insurance is queued up for payment.
The current work around of going to posting of payments and manually changing it
is rather an obscure route.
My observers @juggernautsei
I have spent the better part of a night looking through the code to see if I could follow the logic. I can to a point and then it grows cloudy.
Still looking for the trigger that sets the value of the bill_process.
It is not as straightforward or documented.