Comment 87 for bug 1198465

I've run the latest code through my series of tests. For reference, the test scenarios are available at http://wiki.evergreen-ils.org/doku.php?id=qa:billing_test_cases. The code is looking great! I only encountered problems with one test (more on that below.)

I can confirm that the code now no longer has trouble with generating new overdue fines on a lost checkin. Looking back on the six issues I identified back in comment 52, number 1 has been fixed, number 2 was user error on my part, and number 5 was a UI issue that I think can be addressed at some time in the future. This leaves us with the following remaining issues which I'll list in order of importance:

1 - Manually voiding a partially-paid lost transaction continues to produce a negative balance when the "Prohibit Negative Balances" OU setting is enabled. This test is the one mentioned above where I did not have success. Although the interface provides an alert saying that the entire bill will be voided, I think people will expect that the "prohibit negative balance" setting means no negative balances will be produced in any situation.

2 - We prefer not to use the label "adjustment payment" for adjustments that are made when a lost item is returned. Our concern is that staff will see the word "payment" and think an actual payment has been issued. Our preference is to use something like "adjustment" or "account adjustment." I would love to hear what other Evergreen sites would like to see here for a label.

3 -We don't like the way the prohibit negative balance settings interact with the interval settings. With the current code, if a library wants to only allow negative balances for 30 days after payment is made, they must enable the "Prohibit Negative Balances" setting and then set the interval setting to 30 days. I think most users will think "prohibit" means prohibit in all cases and that the interval settings would be used when the negative balances weren't prohibited. It would be more intuitive if the interval settings worked when the prohibit settings were either Unset or set to "false." In either case, we should probably provide some guidance on what needs to be done in the description for the interval settings.

FWIW, I don't think any of the three above issues are deal breakers for putting the code in. However, since we do have time until the beta cutoff, it would be great if we could make it a bit more intuitive for the users.

Thanks so much Dan! Despite the three issues I identified above, I want to reiterate that, overall, everything looks great. I'm very excited to see this code make its way into 2.9!

Kathy