[OPEN-ILS-GENERAL] Negative balances and void payment types

[Mike Rylander]

Thanks, Dan.

I see where my thinking went astray.  I was imagining (as a final
implementation) a design where we leverage the payment-by-billing-type
code to walk backwards through the line items of a transaction,
voiding anything with no payments  (where appropriate) until we hit a
billing with a payment, at which point we have to start using
balancing credits.  So, I was jumping to a version of your (2),
basically.

I think I agree with your assertion about overdues being adjusted
instead of voided -- that really is a "credit the patron" situation
which is separate from both credit (not card) and forgive payment
types.  Un-adjusting those billings when the item is found would
probably be best done as a void of the adjustment from a logical
standpoint, but simply deleting them might be easier to deal with.
Obviously, credit-style payments are the only kind that should be
"delete-able", so perhaps a new level in the inheritance hierarchy
would be in order, which could also serve as the level at which the
billing link might be added to those credit type payments.  And now
I've digressed far into implementation details and should stop (on
this thread, at least) ... but, suffice it to say, I do certainly see
an internally self-consistent and manageable path forward to address
not just the specific issue of negative patron balances, but a host of
currently-circuitous workarounds and oddities with complex billing
situations.

My misunderstanding (and belief that (2) would be the ideal) aside,
and addressing your branch specifically with regard to the core point
of this discussion, I maintain that reimplementing "void" is the
primary danger -- for the reasons I listed up-thread -- and I really
want to see if my belief that your adjustments to Jason's work fill
the needs of MassLNC.  I'm pretty confident that they will, even more
so now that you've clarified that the "adjust" behavior does
effectively replace the current void behavior.

Again, thanks, Dan and all!


On Wed, Mar 5, 2014 at 5:10 PM, Dan Wells <dbw2 at calvin.edu> wrote:
> 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



-- 
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com