[Koha-devel] RFC: Modification to Fines System

Kyle Hall kyle.m.hall at gmail.com
Wed Sep 30 18:00:46 CEST 2009


> 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?

> 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. ) 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.

> Ideally, we also create an "accountlines_paid" table where fine lines that
> have been paid completely and ALL their associated payment lines are copied
> over, such that accountlines only holds unpaid, current fines.  hah.

Sounds good.

> The main impediment is that these revisions are non-trivial, and legacy data
> cannot be reliably "upgraded".  So the restructuring would have to be timed
> and coordinated appropriately.

Indeed. As a programmer, my instinct has always been to rewrite a
system from scratch, using my understanding of the current system to
write a completely revamped and improved system. However, in a case
like this, I cannot see a good upgrade path, unless we kept both the
old, and new fine systems simultaneously. I cannot imagine the mess
that would cause. That is why I think this is a good start. It adds
new possibilities while not breaking anything.

Kyle

>
> On Wed, Sep 30, 2009 at 10:03 AM, Kyle Hall <kyle.m.hall at gmail.com> wrote:
>>
>> Here is my problem, and my proposed solution.
>>
>> One of our libraries is requesting a breakdown of payments by day, by
>> account type. That is, they want a report the gives the total amount
>> paid for Late Fees, for Damaged Books, and for Lost Books. Apparently,
>> they have separate money accounts for each.
>>
>> In Koha as it stands, there is no direct way to connect a payment to a
>> particular accountline that was paid.
>>
>> The least invasive idea I have is to add a new column to accountlines
>> ( say, accountno_paid ) for payments. Each payment would then refer to
>> the fine or charge that it was paid against.
>>
>> The largest difference, is that instead of one large payment that runs
>> down the amountoutstanding field for a number of charges, the total
>> payment would need to be broken down into a series of smaller
>> payments, one for each accountno paid on.
>>
>> For example, suppose that a borrower has 3 items with and overdue fine
>> of $5.00 each, and the borrower is paying in full. The current version
>> would create a payment line of $15, and then set the amountoutstanding
>> to $0.00 for each of the 3 accountno's. The revamped system would
>> still set the  amountoutstanding to $0.00 for each accountno, but
>> would create three separate payment lines, one for each of the 3
>> accountno's, and the accountno paid on would be stored in
>> accountno_paid.
>>
>> I don't think this would break any existing reports or functionality.
>>
>> Does this sound like a reasonable solution? Or have I missed something
>> that may solve my problem without code?
>>
>> Thanks,
>> Kyle
>>
>> http://www.kylehall.info
>> Information Technology
>> Crawford County Federated Library System ( http://www.ccfls.org )
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha.org
>> http://lists.koha.org/mailman/listinfo/koha-devel
>
>



More information about the Koha-devel mailing list