Comment 22 for bug 1198465

Hi Dan,

Thank you for the feedback and for taking the time to review the code. I do appreciate the time that was put into the testing since I know it is a hairy area to dive into.

I was able to confirm the two bugs you found. I'm not quite sure what happened with the lost-then-returned-items that did not create negative balances since I know it worked in previous testing, but I'm sure it will be easy enough to fix those two bugs.

In terms of the larger questions you raise, I'm not sure I agree with the idea that these transactions should be considered "credits" or that the previous void logic needs to be maintained. In our opinion, the previous void logic was flawed in the sense that it was an "all or nothing" deal. As Ben mentioned in the previous comment, we have huge issues in public libraries where some kind of payment is already applied to a fine or a fee before the system attempts to void the entire transaction. The void logic needs to be smart enough to know when the entire fee needs to be voided and when just a portion of the fee needs to be voided, and Jason's code does that.

My preference is to maintain the "void" terminology because, as you mentioned, void means "this didn't happen." The situations that cause these void payment types to occur are still situations where libraries want to say "this transaction shouldn't have happened." These are not cases where libraries are saying "we believe you deserve something." We use and will continue to use forgive payments for those situations. When a lost item is returned, we want to say that those lost fees should never have happened and are "voided", even if it now is only a portion of the original lost fee. If an item believed to be checked out to the patron is found on the shelf, what remains of those overdue fines should be "voided" because they shouldn't have happened.

If the consensus is that we need to use another term in place of "void," I strongly suggest that we do not use the word "credit." We already have patron credits in the billing system that can be used as a payment type. Using the same term for two entirely different things is confusing for the end user.

I'm looking at this as an end-user and not as a developer or an accountant, so I may be missing something. However, I also find that Jason's code actually improves the end-user's ability to maintain a history of the voided transactions. When a lost item is currently returned to the library and there are no negative balance scenarios, the billing transaction simply disappears from the patron's record. If a patron, who has received the bill, then pays for it or brings it to the circ desk with a question, the circ person can't easily pull up the patron record to see what happened with the bill. With Jason's code, we continue to see the transaction in the patron's bill history with the last payment type clearly identified as voided - http://www.screencast.com/t/iPd7mbcFGfO. If we pull up full details, we clearly see that the void happened because of a returned lost item - http://www.screencast.com/t/7zgMIiQqu. In the past, we only saw that information in cases where a negative balance was applied.

Is there a way we could have partially voided bills and fines without using a void payment type? Perhaps. However, the idea of a void payment type was shared with the community long before the work started. When contracting with developers, MassLNC strongly encourages them to share their plans with the community ahead of time precisely because we want to avoid situations where we need to rework the underlying approach after the coding has been done. It's much easier to set a common direction for the code if concerns are raised at the start of a major project before time/money has already been invested in the original approach.

In looking at this bug report, the original bug report where the void payment type was mentioned https://bugs.launchpad.net/evergreen/+bug/1009049, and the e-mail that Jason sent to the Evergreen list http://georgialibraries.markmail.org/thread/rbz6atf7j2zhe2k3, I didn't see any concerns about using a void payment type. I also did a very rudimentary search of the IRC logs, but the only log I found that mentioned void payment types was a general +1 from berick - http://irc.evergreen-ils.org/evergreen/2013-07-12.

I understand that you don't necessarily see the flaws to an approach until it is implemented, but I just mention this because it puts a contracting agency in a difficult spot when fundamental changes are requested later in the process.

For #3 in your last comment, I may be misunderstanding the suggestion, but it sounds like you are suggesting that we use the current void logic in all cases except those where a negative balance may be produced. In that case, would we be using the existing void logic for any lost items that are returned except in those cases where a) a negative balance would be generated and b) the OU doesn't allow negative balances? If so, we would be using older void logic for some lost-and-returned-items and using a "something-other-than-a-void-or-credit" payment type for other lost-and-returned-items? I think this could be a usability issue, especially for those newcomers to Evergreen who don't know the history of voids in the system.

Once again, Dan, I do appreciate the feedback you've given thus far. I don't want my comments to be seen as criticism of the feedback. I fully support the approach Jason has taken, and I just want to make sure that the benefits I see in this approach are clearly articulated.

Thank you!
Kathy