[Koha-devel] RFC: Modification to Fines System

[Joe Atzberger]

On Wed, Sep 30, 2009 at 12:00 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:

> > I studied (and ranted) on fines several times previously.  You have the
> > right idea.  One important thing to realize is that you need a primary
> key
> > in accountlines.  There is no way for the table to refer back to itself
> > without it.
>
> I always thought of accountno as the primary key to the table, though
> it is not marked as such. Are there cases where accountno is used more
> than once?
>

The accountno is smallint(6) with no constraints.  It is not guaranteed
unique, and it is not even indexed!  It cannot be used as a substitute for a
true primary key.


> > I also think that in the proposed structure, maybe "amountoutstanding"
> > should go away completely, since the data will be represented by the sum
> of
> > the line and any payments against that line.
>
> I vote to keep amountoutstanding, it has it's uses. Our previous ILS,
> as well as Koha, support incremental payments (
> C4::Accounts::recordpayment, had to add a new field and script to make
> use of it. )


This is not dependent on the data representation having an amountoutstanding
field.  The same information would be represented by combining the amount of
a fine with any payment lines that reference it.  In fact, that will be the
authoritative version of the amount still owed, right?

Since you would still have the information, what are the arguments for
keeping that "amountoutstanding" field in the fine line that represents the
subtotal of payments made against it?  Mainly performance and some
simplicity, since you don't have to requery the table or build a nested
query to calculate the amountoutstanding value.  But it produces a
maintenance problem, since when you insert a payment line, the fine line
also has to be updated.  All the operations that adjust either have to touch
both, and operations on at the database level would be so error-prone as to
be impractical.

I would prefer that the fine line, once in the table is NEVER updated (i.e.,
updated as little as possible, ideally NEVER), and that the authoritative
version of how much is outstanding is the ONLY version.  That makes a more
atomic, auditable process.  Multiple incongruent representations of the same
data leads to the kind of mess seen in early versions of Koha fines.


> Many of our patrons will pay a portion of their fines
> each visit. So, in the case that a borrower had a single $10 fine and
> made two $5 payments a week apart, there would just be two payment
> lines with an accountno_paid line that refers to the original $10
> fine. The upside is there is no work needed to leave it in.
>

It sounds here like you are mostly agreeing with me.  I'm not saying get rid
of amountoutstanding features, just make sure we pick one consistent data
model.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20090930/dbf07a16/attachment-0003.htm>