> 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
