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 jwag...@ptfs.com -----Original Message----- From: koha-devel-boun...@lists.koha.org [mailto:koha-devel-boun...@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.h...@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@lists.koha.org >> http://lists.koha.org/mailman/listinfo/koha-devel > > _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
