© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
Hi Dan and Remington,
Sorry for the delay with testing again. We've loaded Remington's most recent branch and I re-produced the steps that I followed to produce the error cited in #1. There is improvement, but we're still left with a $.05 fine on the record. Here is what we did:
1. The transaction had accrued 1.75 in overdue fines before it was automatically set to lost back in 2012. The overdue fines were voided, and the patron was assessed with a $22.00 lost fee.
2. I added a $10 cash payment for the transaction today.
3. I then checked in the lost item. The following happens:
a. $1.75 in overdue fines are reinstated (library has restore overdues on lost item return enabled)
b. We get an adjustment payment of $13.75 (I'm assuming this is the $12.00 left of the lost book fee + the $1.75 in overdue fines.
c. An overdue fine of $.05 is generated at checkin time. Above, I referred to this as a stray fine, but, after spending more time on some of our other billing development projects, I now realize that Evergreen typically applies the last overdue fine at checkin.
The patron is left with a $.05 fine on their record from that last overdue fine that was generated. Since the patron had paid $10 to the lost book fee, I would expect that the patron wouldn't have any other charges remaining from this transaction.
Also note that this library has the 'Lost Checkin Generates New Overdues" enabled, but no new overdue fines were generated at checkin. In this example, it doesn't make a huge difference because the patron has already paid above and beyond whatever fines would have accrued, but I am going to do some further testing to see what would happen if the patron had only paid their initial overdue fines and if they would ultimately be assessed the new fines on the lost item return.
What I really think is missing is a really good set of use cases that define all of these different twists and turns for a transaction that then describes which fines/fees a patron should ultimately be assessed given a certain set of library settings. That's something MassLNC could work on if it helps this code move along.