The negative balance settings are being applied even if no existing setting,

Bug #1593815 reported by Steve Callender
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

I have tested this on 3 different 2.9 setups and what I am seeing with these new negative balance settings, is that they are being invoked even when they are not being used.

For example, a patron has an item to go lost by means of the action_trigger MarkItemLost reactor.

The system finds the btype 1 overdues successfully.
It finds the circ.void_overdue_on_lost is true.
It checks for bill.prohibit_negative_balance_on_overdues which is not set at all. (Not at any level)
It checks for bill.prohibit_negative_balance_default which is also not set at all.
It checks bill.negative_balance_interval_on_overdues, and it's not set either.
It checks bill.negative_balance_interval_default and it's not set.
Then it checks for voided bills and after that starts applying the account_adjustment payment to 0 it out.

So I'm finding this new feature is running when there are no settings being used.

IT looks like this is the code from CircCommon.pm but the issue is not standing out to me,

    my $billids = $e->search_money_billing([$bill_search, {idlist=>1}]);
    if ($billids && @$billids) {
        # overdue settings come from transaction org unit
        my $prohibit_neg_balance_overdues = (
            $U->ou_ancestor_setting_value($circ->circ_lib(), 'bill.prohibit_negative_balance_on_overdues')
            ||
            $U->ou_ancestor_setting_value($circ->circ_lib(), 'bill.prohibit_negative_balance_default')
        );
        my $neg_balance_interval_overdues = (
            $U->ou_ancestor_setting_value($circ->circ_lib(), 'bill.negative_balance_interval_on_overdues')
            ||
            $U->ou_ancestor_setting_value($circ->circ_lib(), 'bill.negative_balance_interval_default')
        );
        my $result;
        # if we prohibit negative overdue balances and all payments
        # are outside the refund interval (if given), zero the transaction
        if ($opts->{force_zero}
            or (!$opts->{force_void}
                and (
                    $U->is_true($prohibit_neg_balance_overdues)
                    and !_has_refundable_payments($e, $circ->id, $neg_balance_interval_overdues)
                )
            )
        ) {
            $result = $class->adjust_bills_to_zero($e, $billids, $opts->{note}, $neg_balance_interval_overdues);
        } else {
            # otherwise, just void the usual way
            $result = $class->void_bills($e, $billids, $opts->{note});
        }
        if (ref($result)) {
            return $result;
        }
    }

I tested this on 2.10.2 and using only the settings to void overdues when marking an item lost, and none of the negative balance settings, my bills were not voided but instead they had had a payment applied with the note "System: OVERDUE REVERSED for Lost Materials Processing".

So it looks like something is wrong here and bills are not being processed correctly. They definitely are not behaving the same as pre-2.9 without any change to the settings being made. In my testing, I am not able to get it to not apply a payment adjustment.

Steve

Tags: circ-billing
Revision history for this message
April Durrence (april-durrence) wrote :

Thank you for submitting this bug report, Steve! I wanted to report further that the Library Setting "Restore overdues on list item return" also no longer works because these account adjustments are now processed as payments rather than voids. The overdue fines that are owed on a lost item that is later returned are not added back to the patron account as a bill, as intended by a "true" value in this Library Setting.

Revision history for this message
April Durrence (april-durrence) wrote :

That should be Restore overdues on lost item return

Revision history for this message
Dan Wells (dbw2) wrote :

Thank you for these reports. I can't respond completely at this point, but I can point out that at least some of what is being experienced and reported are intentional changes.

In order to make certain events workable, the new code is designed to never rewrite history. As such, the system no longer "unvoids" billings, as there is no clear record of how a bill ended up as it did (we were, in essence, making something un-un-happen).

In other words, we had been managing with two different concepts acting as one: real voids (i.e. "this never happened") and pseudo-voids (i.e. "this happened, but we're going to say it didn't, unless something else happens in the future which changes our mind"). When processing a bill in retrospect, you can't tell these cases apart, and that is a real problem. The overdues "voided" on lost item return clearly fell into the pseudo-void side, as many libraries do restore these on lost item return.

At this point, the setting certainly needs to be renamed to reflect the new means, but the end result (as intended, at least) should be equivalent. I can't recall what made it into the release notes, but I recognize these changes do need to be communicated better as well.

Viewed as a timeline, libraries using these settings should now see the following:

1) Overdue fines are charged.
2) Item goes lost.
    - Lost fees applied according to setting.
    - Adjustment applied to offset existing overdues.
3) Item returned.
    - Lost fee voided.
    - New overdue fine generated in amount of previous adjustment.

There are also notes applied explaining why each event happened.

So, all that said, are there reproducible steps which result in a clearly incorrect balance? The changes are complex, so I'm very aware there may still be cases where things do not turn out as planned. There were compromises which had to be made, but the intention was always that the same settings would result in the same end balance pre- and post-2.9.

Revision history for this message
April Durrence (april-durrence) wrote :

Hi Dan,

Counteracting negative balances is a marvelous initiative and we are very much in favor of it, so thanks to everyone for all your work on this code. I appreciate what you are saying about "pseudo-voids", which are really a kind of contingent adjustment to billing that may or may not remain in effect. That is why I think that the account adjustment should be a negative billing adjustment, not counted as a payment.

The main problem we are seeing with the new system is that, rather than remaining in the billing section of the Full Details screen, the account adjustments are showing as payments in the patron account - both in the Full Details screen and in the Payment History. This makes it appear to library staff that the patron has paid something on the account and is causing confusion. I would contend that these account adjustments firmly belong in the billing section because they are an adjustment to billing, not any sort of payment. That change could make all the difference.

Revision history for this message
Dan Wells (dbw2) wrote :

Thanks for the clarification! That makes a lot of sense.

We've developed a view locally which shows both billings and payments on a single timeline, and we like it. Is that something you would be interested in seeing? I keep too many irons in the fire sometimes as it is, but knowing there is interest can sometimes bump these things up the priority list.

Revision history for this message
Terran McCanna (tmccanna) wrote :

Dan, I'd really love to see what you did with the single view - even just a screenshot with identifying info blocked out would be great!

Revision history for this message
Jason Etheridge (phasefx) wrote :

I'm going to throw this here, but I can open a new bug if desired. If you Adjust to Zero on a billing on an open circulation, it will prematurely close the transaction (set xact_finish).

Revision history for this message
Dale Rigney (drigney) wrote :

This might be a new bug also, but it related to the issue at hand.

Here is what I see on v29 when you backdate a lost item during checkin:

Viewed as a timeline:

1) Overdue fines are charged (to include the over fines generated for on the day the item is marked lost).
2) Item goes lost.
    - Lost fees applied according to setting.
    - Adjustment applied to offset existing overdues.
3) Item returned with a backdate of the day before (i.e item returned in overnight bin).
    - Lost fee voided.
    - Creates overdue fee fee
    - New overdue fine generated in amount of previous adjustment.
4) Backdating is applied and voids fines dated after the backdated checkin date. This is the new Overdue fines generated in the amount of the previous adjustment and the last overdue fee generated on that day.

This ultimately causes an amount owed to the patron.

Revision history for this message
Kathy Lussier (klussier) wrote :

Adding a link to related bug 1671856, which proposes changing this behavior. April, I would be interested in hearing your thoughts on the proposed change.

Revision history for this message
April Durrence (april-durrence) wrote :

Adding my comments here and in bug 1671856 to say that Bill's argument seems sound to me that the behavior for all the different "void" scenarios should be consistent, either always use void or always use account adjustment.

The issue I continue to have with the account adjustment feature is that it displays as a payment in the patron account. That is not a factual or true representation of the transaction since no payment was ever made (and certainly not by the patron) which causes significant confusion and frustration on the part of staff, since they would have to go deeper into billing to recognize that an account adjustment is in play.

Revision history for this message
April Durrence (april-durrence) wrote :

These automated voids still seem to be functioning in addition to the account adjustment feature, which means that patrons are credited too much when fines are voided in addition to the account adjustments for a double credit, causing an incorrect reduced amount owed or a negative balance on the patron account. The account adjustments have the addition drawback of being mischaracterized as payments.

Here is a recent patron transaction that demonstrates the problem automated behavior:

8/12/17 – Patron checks out a book
9/2/17 – Item is due, but not returned
9/3/17 – Overdue fines of $ .25/day begin to accrue up to a total of $8.75
10/15/17 – item is marked LOST, $16 billed to patron (cost of book) and $8.75 in fines voided
11/13/17 – Item is returned by patron - $16 lost billing voided and $8.75 in fines reinstated
11/14/17 – Item marked damaged, patron billed $16 for cost of item; overdue charges voided again because replaced by damage billing

At some point in this process, the account adjustments also occurred, meaning that the patron received an unwarranted additional offset of $8.75, leaving an outstanding balance of $7.25 instead of the correct amount of $16. Therefore, patron only paid $7.25, when she should have paid $16. Because the account adjustments show as a payment, the patron’s Bill History inaccurately shows a $16 total payment.

I don't know if the negative balance settings would have made a difference in this case, since no negative balance was created due to the amount owed. The billing and account adjustments occurred before our recent upgrade from 2.9.4 to 2.12.7, so I am unsure if the behavior would be the same in 2.12.

Revision history for this message
Kathy Lussier (klussier) wrote :

Hi April,
I would recommend filing this issue as a new bug. I think the best way to tackle the billing problems is if each issue is identified in its own bug since it makes it easier to track which ones have been addressed and which ones remain.
Kathy

Revision history for this message
April Durrence (april-durrence) wrote :

Okay, will do. Thanks, Kathy!

Dan Wells (dbw2)
tags: added: billing
tags: added: circ-billing
removed: billing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.