2009/10/2 Kyle Hall :
> I just thought of a reasonably easy way to track both the payment made
> by a borrower, and the payment as applied to charges on a borrowers
> account. Let's start with the three $5 fine scenario again, which the
> borrower is paying in full.
>
> 1. A payment of $15 is made,
Dear Kyle Hall,
On Thu, 1 Oct 2009 08:47:52 -0400, Kyle Hall wrote:
> I just thought of a reasonably easy way to track both the payment made
> by a borrower, and the payment as applied to charges on a borrowers
> account.
[...]
> The real question is: is this necessary? Do any libraries using Ko
I just thought of a reasonably easy way to track both the payment made
by a borrower, and the payment as applied to charges on a borrowers
account. Let's start with the three $5 fine scenario again, which the
borrower is paying in full.
1. A payment of $15 is made, it is inserted with a new accoun
On Wed, 2009-09-30 at 15:37 -0400, Kyle Hall wrote:
> > I think the simplest way to manage fines would be to have one table for
> > invoices, and a separate table for credits. Figuring the amount
> > outstanding would be a (relatively) simple sum of a union query. And
> > nether table would ever
> I think the simplest way to manage fines would be to have one table for
> invoices, and a separate table for credits. Figuring the amount
> outstanding would be a (relatively) simple sum of a union query. And
> nether table would ever be touched for updates.
That could easily be step 2, after
> 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.
Is there any reason we can't change it to an int(8) and make it the primary key?
> This is not dependent on the data represe
Missed an edge case in my idea. If a payment covers all on one fine,
but not all of two fines.
I was looking at the accountoffsets table ( had to make sure it still
exists and is in use ), and realized what the amount column there is
for.
So have the same column, for the same reason, in the trac
I'm all in favor of simplicity. The specific case I have in mind is the
error on the circulation screen when a patron has fines, but the reports
is as good a reason for simplicity.
I'm not sure I understand Joe's proposal, so I'm going to go from
scratch with this idea. It's probably the same as
On Wed, Sep 30, 2009 at 12:00 PM, Kyle Hall 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 i
e 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 tab
> 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 tab
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 also think that in the proposed structure, maybe "amountoutstandi
> jwag...@ptfs.com
>
>
> -Original Message-
> From: koha-devel-boun...@lists.koha.org
> [mailto:koha-devel-boun...@lists.koha.org] On Behalf Of Walls, Ian
> Sent: Wednesday, September 30, 2009 10:41 AM
> To: koha-devel@lists.koha.org
> Subject: [Koha-devel] RFC: Modificatio
a-devel-boun...@lists.koha.org
[mailto:koha-devel-boun...@lists.koha.org] On Behalf Of Walls, Ian
Sent: Wednesday, September 30, 2009 10:41 AM
To: koha-devel@lists.koha.org
Subject: [Koha-devel] RFC: Modification to Fines System
Kyle,
Sounds good to me.
This suggestion seems like it could have some pow
550 First Ave., New York, NY 10016
(212) 263-8687
-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 10:03 AM
To: koha-devel
Subject: [Koha-devel] RFC: Modification to Fines
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
16 matches
Mail list logo
