[OPEN-ILS-GENERAL] Negative balances and void payment types
Dan Wells
dbw2 at calvin.edu
Wed Mar 5 17:10:02 EST 2014
Mike and Kathy, thanks for taking the time it took to craft your thorough responses. It really helps outline many of the areas of contention.
I want to point out, though, that my current branch doesn't do quite what is stated in Mike's email. There are really three ways we could go when applying the new logic:
1) Always* do voids ("old" way)
2) Do voids where you can, adjust where you need to ("mixed" way)
3) Always* do adjustments ("new" way)
My current code lets you pick between 1 and 3, rather than go the extra mile and try to be context sensitive (the "mixed way). (*It also lets you set a different "always-ness" for lost vs overdue, if desired.) Not saying we can't or shouldn't work in a direction where the code is context sensitive, but it seemed like early adopters were putting a high value on "sameness" of the transactions, so the first crack went that route.
Also, I want to highlight something else about my branch which I noted in one of my long comments on the LP bug:
" c) * The one place where the code now always "adjusts" (never voids) is for overdue->lost behavior. Overdue fines are adjusted to zero (if the option is on), not voided. I think this makes sense logically (they still happened, we are just not charging for them), and it makes it much easier to accurately reinstate these fines if the lost item is returned (if *that* option is on)."
Basically, I believe that "voiding" overdues when marking an item lost is a grey area for our technical definition of void (especially if plan to possibly reinstate them), so I took it the other direction in that one case. This is primarily an implementation choice, and not particular crucial to the discussion, but since it is used in a couple of Mike's examples, I wanted to point it out.
Thanks again,
Dan
More information about the Open-ils-general
mailing list