Allow option to Forgive remaining balances instead of voiding/unvoiding all billings

Bug #1009049 reported by Jeff Godin
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Evergreen
Confirmed
Wishlist
Unassigned

Bug Description

The Evergreen system automatically voids billings in several places:

 * voids some/all overdues on checkins that
     - are backdated
     - are amnesty
     - involve a grace period
 * (configurably) voids overdues when an item is marked lost
 * (configurably) voids lost and lost processing fee when a lost item is checked in
     - (configurably) UN-VOIDS overdues on lost checkin

In addition to these system voids, users with appropriate permissions can void any billing.

Starting with a focus on Lost and Lost-then-found items, we'd like to have an option for the system to make Forgive payments for any remaining outstanding balance, rather than Voiding bills.

We'll then be interested to move on to amnesty/backdated checkin/grace period, etc.

This has several advantages:
 * By not voiding a paid bill, we avoid situations where a credit is now owed, where a library may have a policy of no refunds
 * By not voiding a paid bill, we avoid having payments be taken in for one billing type, then that bill being voided and the payments being used against some other billing type
 * Using a Forgive payment makes billing history much more "linear", and somewhat easier to follow
 * For "reinstate overdue fines on lost item checkin", we can re-bill the previously forgiven amount, rather than "un-voiding" previously voided overdue billings
 * Transactions which have had their bills voided won't "disappear" from staff interfaces

Possibly seen as disadvantages:
 * Transactions which have had their bills voided won't "disappear" from staff interfaces

 * When reporting on Forgive payments, you may now wish to exclude Forgive payments from your reporting where the note field indicates the Forgive was automatically applied
 * Some summary interfaces will show "total paid" including the Forgive payment(s), requiring either the addition of a column or the showing of details to note that it was a Forgive payment
 * If you limit forgive payment permissions, we may need to adjust some approach to permit system Forgive without granting manual staff Forgive

Again, starting with Lost and Lost-then-found items:

Currently, with the relevant options enabled:
 * Item is marked lost.
 * All overdue fines are voided
 * Lost bill is created for price of item (or a default if zero)
 * Lost processing fee is billed
 * Lost item is checked in
 * Lost and Lost Processing Fee bills are voided
 * Overdue fines are un-voided

Proposed, with the relevant options enabled:
 * Item is marked lost
 * Forgive payment is made for any outstanding Overdue fines balance
 * Lost bill is created for price of item (or a default if zero)
 * Lost processing fee is billed
 * Lost item is checked in
 * Forgive payment is made for any outstanding balance of Lost and Lost Processing Fee bills
 * A single bill is added for the total of any previously Forgiven Overdue fines

Revision history for this message
Jeff Godin (jgodin) wrote :

For those interested in poking at this:

The working repo from Dec 2011 is at working/lost_avoid_void -- http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeff/lost_avoid_void

We have the first part of this in production on 2.1.1. Branch with the changes is here: http://git.evergreen-ils.org/?p=evergreen/tadl.git;a=shortlog;h=refs/heads/tadl/lost_forgive_not_void

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Jeff,

Pursuant to our IRC conversation yesterday, I am hijacking your bug. I don't think the solution to the problems with voids is to allow forgive payments. I think the solution is to add a void payment type and apply void payments to bills. This can be done automagically by void code and by staff who may want to void only part of a billing.

I'm going to share something with the dev list later that expounds on your issues presented above and proposes the void payment as a solution.

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
summary: - Allow option to Forgive remaining balances instead of voiding/unvoiding
- all billings
+ Void Should be a payment type
Revision history for this message
Jason Stephenson (jstephenson) wrote :

In the interest of community, I'm giving your bug back. This is why I should not bug wrangle at 4:00 am.

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
summary: - Void Should be a payment type
+ Allow option to Forgive remaining balances instead of voiding/unvoiding
+ all billings
Revision history for this message
tji@sitka.bclibraries.ca (tji) wrote :

From the end user perspective, forgive payment and voiding bill are totally different. Generally speaking, forgive payment means libraries do not want to collect payment for valid billings. Voiding billing means the bills should not be created. Replacing voiding bill with forgive payment will mess up things for libraries that "genuinely" use Forgive Payment.

Tina Ji/Sitka

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Jeff,

I've also been looking into bill issues. I think you've stumbled on a partial solution to the problem. What I would suggest is that new bill and payment types of Void be created. These new types should not be made optional, but should become the way that bills and payments in the future are voided.

Further, I don't think anything should be voided or reinstated on transactions with xact_finish set. These should be treated as "closed accounts." I suppose that a setting could be used to reopen these so that those who really want to mess with things can do so.

The upgrade script should go through and create void payments for all bills with the void flag on, and then the void column dropped from the schema.

There are probably tons of settings and edge cases that would need to be considered, but that's the basics.

Let me know what you think. I'm perfectly happy to collaborate on the code with you.

Jason

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Jeff,

Is anything going on with this bug and my suggestions above? I want to take a look at your code as a starting point for some of the modifications that I've suggested.

Jason S.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

Pushed an updated version of the branch to collab. Looks like it needed a minor conflict resolution with a recent fix for closing transactions.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dyrcona/lost_avoid_void

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Revision history for this message
Jason Stephenson (jstephenson) wrote :

I am mangling Jeff's code to work how I think it should. After I've had a chance to try it out on my development vm, I'll throw that branch up in collab for comparison's sake.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

For anyone who wants to see what I've come up with so far my branch is avaialable here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1009049

and here:

http://git.mvlcstaff.org/?p=jason/ILS.git;a=shortlog;h=refs/heads/lp1009049

My branch is NOT tested at all at this point, and so is likely full of typos and such. I will likely not get to test until Tuesday.

I'm sharing it here for anyone who wants to see what I'm thinking, and if anyone wants to shoot it down before I get too far along.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

My branch has been tested at this point but is still incomplete.

I think we should have a conversation about what approach we want to take with voids.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

We have two possible implementations of something like this in the comments above. Jeff's is probably more complete than mine, though mine has nothing optional about it. Mine changes the way voids work by adding new payment types. I know some groups are putting together a RFP to have many billing issues addressed. I'm putting my work on hold for now.

Changed in evergreen:
status: In Progress → Confirmed
assignee: Jason Stephenson (jstephenson) → nobody
Revision history for this message
Jason Stephenson (jstephenson) wrote :

I have modified my above solution for inclusion in work done under contract to MassLNC. The above branches are not the current code. My code is being included in work done on bug 1198465.

You can find some additional details here:

http://www.sigio.com/evergreen/billing2013.html#voidpayment

and here

https://blueprints.launchpad.net/evergreen/+spec/billing-enhancements

Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
assignee: Jason Stephenson (jstephenson) → nobody
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.