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
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
> 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
Indeed, if everyone is on board with his idea, it would be an easy
connection. Payment -> Fine -> Item
Kyle
http://www.kylehall.info
Information Technology
Crawford County Federated Library System ( http://www.ccfls.org )
On Wed, Sep 30, 2009 at 10:54 AM, Wagner, Jane wrote:
> Not directly
Not directly related to Kyle's idea, but one of the needs we've seen
relating to fines is a better description of what the payment is for.
Having Koha just say "Payment, thanks" doesn't tell staff two weeks
later what the payment was for. We've been planning to look at
amplifying that description;
Kyle,
Sounds good to me.
This suggestion seems like it could have some powerful long-term potential. By
modifying the system in the way you suggest, it would be possible to expand the
kinds of payments patrons can make to include arbitrary services (like
printing, ILL, class registration fee
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
13 matches
Mail list logo
