[Koha-devel] RFC: Modification to Fines System

[Wagner, Jane]

I can't find the correspondence or the bug report right now, of course, but a week or two ago there was some discussion of separating the fines display into stuff that's currently outstanding and stuff that's been paid.  That would seem to tie in nicely to the comment:

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

Jane Wagner
Library Systems Analyst
PTFS Inc.
Content Management and Library Solutions
6400 Goldsboro Road, Suite 200
Bethesda, MD  20817
(301) 654-8088 x 151
jwagner at ptfs.com


-----Original Message-----
From: koha-devel-bounces at lists.koha.org [mailto:koha-devel-bounces at lists.koha.org] On Behalf Of Kyle Hall
Sent: Wednesday, September 30, 2009 12:01 PM
To: Joe Atzberger
Cc: koha-devel
Subject: Re: [Koha-devel] RFC: Modification to Fines System

> 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
>
>
_______________________________________________
Koha-devel mailing list
Koha-devel at lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel