[Koha-devel] RFC: Modification to Fines System

[Michael Hafen]

On Wed, 2009-09-30 at 15:37 -0400, Kyle Hall wrote:
> > I think the simplest way to manage fines would be to have one table for
> > invoices, and a separate table for credits.  Figuring the amount
> > outstanding would be a (relatively) simple sum of a union query.  And
> > nether table would ever be touched for updates.
> 
> That could easily be step 2, after this is complete.
> 

I'm thinking about this a little more, and there wouldn't have to be
separate tables.  The point, as Joe said, is that the table(s) aren't
updated; only inserted into.

> > The trick to getting this to work is having a third table just for
> > tracking the association of credits to invoices.  If a payment is made
> > that is more than a single invoice, more rows would be inserted to
> > reflect that.  Similarly if many payments are made for one invoice, more
> > rows would be inserted.
> 
> Is there a reason that the payments table couldn't just have a foreign
> key to the invoices table? I assume it's required so a single payment
> can reference multiple invoices. That is a limitation of what I
> proposed. To make a single payment against multiple invoices in my
> proposal, it requires breaking that single payment into multiple
> smaller payments. Not hard to code, but I don't know what impact this
> has on accounting practices.

Foreign keys are always good, and would be applicable in any case I
think.


> > Moving to this sort of structure is the real hitch. It wouldn't be easy.
> > I imagine a couple queries, one to copy credit lines to the credits
> > table and one to copy fine lines to the fines table.  The
> > amountoutstanding column could effectively be ignored since it's status
> > should be reflected well by the tracking table.  The accountoffsets
> > table could be used to form the tracking table with minimal data loss.
> > If the borrowernumber,accountno combination isn't used for the key, then
> > a temporary column could be added to the accountlines table and filled
> > via an SQL variable to reflect what the key in the new table will be.
> > Ideally there would be no data loss because the accountoffsets table is
> > being used properly in all code.  I'm not an idealist.
> >
> 
> What is the point of the accountoffsets table? With all the work I've
> done, I've never once had to work with it.

The accountoffsets table is the tracking table.  I realize now that what
I've described isn't that different from what we have now.  Drop the
amountoutstanding column and add a key column, and you have it
basically.

The other difference is how to handle odd payments, which is where we
began.

The question of splitting the payment to better match the fines payed is
a good one.  Not splitting the payment represents what the patron did;
they brought in money and gave it to the library.  Splitting the payment
represents what the library did; they took the money and applied it to
fines the patron had.

The difference is a matter of accounting practices, which I don't know
that well.  For all I know an accountant would want both done.  Record
receipt of the whole sum, and have a separate table where the credit is
split and applied against fines.

> 
> Kyle
-- 
Michael Hafen
Systems Analyst and Programmer
Washington County School District
Utah, USA

for Koha checkout
http://development.washk12.org/gitweb/
or
git://development.washk12.org/koha