Re: [Koha] [Koha-devel] RFC: Modification to Fines System
En su momento, tajoli escribió:
Dear Kyle Hall,
On Thu, 1 Oct 2009 08:47:52 -0400, Kyle Hall <kyle.m.hall@gmail.com> 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 Koha need to track total payments against individual fine payments?
I don't know if libraries needs to track payments in this way. In Italy, as standard, we don't use fines. We put days of embargo on user or we ask to pay the value of book if heavily damaged or lost.
But if you do the work, read the MySql documentation here: http://wiki.koha.org/doku.php?id=en:development:dbschema http://www.koha.it/local--files/working/koha303_schema.zip
I'm sure that there are errors, and to have a prefect idea on how the system work, read the code of the API. A one person previous said, there are lacks on constraints, unique keys, indexes.
And please write here any error you find in the docs, I will update them. And also any update on the tables.
Bye Zeno Tajoli
Hi there !... I want to jump into this thread because, as the italian libraries, argentinian libraries don't use monetary fines but a suspension period (an amount of days depending the itemtype or the borrowertype, etc.) Since we began using Koha, back in version 2.2, we had to 'do something' to use Koha and change 'fines' to 'suspensions' and reflect that in the system. I'm sure each Koha implementation here at Argentina has it's own way to implement this (via new local tables, scripts,etc) I was able to implement this feature by "missusing" the accountlines table, adding a local variable, changing a bit mancredit, maninvoice templates and adding some code to fines.pl and some C4 modules.... This "Frankenstein" has been working very well over this years... but the thing is that it would be a lot better if something like this could be included into Koha... so a library could select the type of system to use (monetary fines or suspension days) in System Preferences. So .. If some changes are to be made to the Fines System, I wanted to add my 2 cents so maybe this changes can made it to the system too Best regards -- Ing. J. Martin Longo Depto. Gestion Informatica SID - UNCuyo http://sid.uncu.edu.ar
That sounds like a good feature, but I certainly don't fully understand how your system works, or how it interacts with the fines system. I would suggest opening a bug in bugzilla to request the feature be added. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Thu, Oct 1, 2009 at 6:54 PM, Martin Longo <jmlongo@uncu.edu.ar> wrote:
En su momento, tajoli escribió:
Dear Kyle Hall,
On Thu, 1 Oct 2009 08:47:52 -0400, Kyle Hall <kyle.m.hall@gmail.com> 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 Koha need to track total payments against individual fine payments?
I don't know if libraries needs to track payments in this way. In Italy, as standard, we don't use fines. We put days of embargo on user or we ask to pay the value of book if heavily damaged or lost.
But if you do the work, read the MySql documentation here: http://wiki.koha.org/doku.php?id=en:development:dbschema http://www.koha.it/local--files/working/koha303_schema.zip
I'm sure that there are errors, and to have a prefect idea on how the system work, read the code of the API. A one person previous said, there are lacks on constraints, unique keys, indexes.
And please write here any error you find in the docs, I will update them. And also any update on the tables.
Bye Zeno Tajoli
Hi there !...
I want to jump into this thread because, as the italian libraries, argentinian libraries don't use monetary fines but a suspension period (an amount of days depending the itemtype or the borrowertype, etc.)
Since we began using Koha, back in version 2.2, we had to 'do something' to use Koha and change 'fines' to 'suspensions' and reflect that in the system. I'm sure each Koha implementation here at Argentina has it's own way to implement this (via new local tables, scripts,etc)
I was able to implement this feature by "missusing" the accountlines table, adding a local variable, changing a bit mancredit, maninvoice templates and adding some code to fines.pl and some C4 modules....
This "Frankenstein" has been working very well over this years... but the thing is that it would be a lot better if something like this could be included into Koha... so a library could select the type of system to use (monetary fines or suspension days) in System Preferences.
So .. If some changes are to be made to the Fines System, I wanted to add my 2 cents so maybe this changes can made it to the system too
Best regards
-- Ing. J. Martin Longo Depto. Gestion Informatica SID - UNCuyo http://sid.uncu.edu.ar
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On 10/02/2009 01:13 PM, Kyle Hall wrote:
That sounds like a good feature, but I certainly don't fully understand how your system works, or how it interacts with the fines system.
I think theres two separate issues one is that fines themselves require more information (counter staff can never have too much when facing a disputing customer) and better handling. The other is that the current circulation rules need more flexibility so that you can include fines (including increasing fine rates) and/or suspensions and possibly other penalities (large man with big stick visits patron?). Colin -- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
Here's the roadmap I have planned out. I'll put this on the wiki if anyone would like me to. Step 1) accountlines.accountno becomes the primary key. Payments reference fines paid via accountno_paid. ( I've already written this and sent a patch ). Step 2) Create a 'payments' table, to store each original payment amount. Add foreign key to the accountlines table. Step 3) split the accountlines table into two new tables. 'charges', and 'payments_applied'. Get rid of amountoutstanding. How does that sound for a long term goal? Before I can proceed further, can anyone explain in detail what the accountoffsets table is for? I need to get rid of the sub that fetches the next accountno. It's harmless to leave it there, but it really should be depricated. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 2, 2009 at 8:50 AM, Colin Campbell <colin.campbell@ptfs-europe.com> wrote:
On 10/02/2009 01:13 PM, Kyle Hall wrote:
That sounds like a good feature, but I certainly don't fully understand how your system works, or how it interacts with the fines system.
I think theres two separate issues one is that fines themselves require more information (counter staff can never have too much when facing a disputing customer) and better handling. The other is that the current circulation rules need more flexibility so that you can include fines (including increasing fine rates) and/or suspensions and possibly other penalities (large man with big stick visits patron?).
Colin
-- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2
http://www.ptfs-europe.com _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On Fri, Oct 9, 2009 at 8:54 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Here's the roadmap I have planned out. I'll put this on the wiki if anyone would like me to.
Step 1) accountlines.accountno becomes the primary key. Payments reference fines paid via accountno_paid. ( I've already written this and sent a patch ).
No, we should create an entirely new primary key (say, "line_id"), to avoid the problem that accountno might already have conflicting values in it, blocking the DB conversion to primary key or forcing data to be dropped in the process. I think the overdue script will be unchanged. The options and configurations for fines/debar are all exposed already. --joe
That makes sense. I'll have to modify my patch for that. FYI, if anyone is interested, this work is available at http://koha-plus.git.sourceforge.net/git/gitweb.cgi?p=koha-plus/koha-plus;a=... if anyone wants to monitor it. Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Fri, Oct 9, 2009 at 10:57 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
On Fri, Oct 9, 2009 at 8:54 AM, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Here's the roadmap I have planned out. I'll put this on the wiki if anyone would like me to.
Step 1) accountlines.accountno becomes the primary key. Payments reference fines paid via accountno_paid. ( I've already written this and sent a patch ).
No, we should create an entirely new primary key (say, "line_id"), to avoid the problem that accountno might already have conflicting values in it, blocking the DB conversion to primary key or forcing data to be dropped in the process.
I think the overdue script will be unchanged. The options and configurations for fines/debar are all exposed already. --joe
It seems that maybe the overdue script should, instead of creating fines, call a new subroutine that decides what should be done ( ie create fine, suspend account, etc. ). Kyle
I think theres two separate issues one is that fines themselves require more information (counter staff can never have too much when facing a disputing customer) and better handling. The other is that the current circulation rules need more flexibility so that you can include fines (including increasing fine rates) and/or suspensions and possibly other penalities (large man with big stick visits patron?).
Colin
-- Colin Campbell Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 208 366 1295 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2
http://www.ptfs-europe.com _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
participants (4)
-
Colin Campbell -
Joe Atzberger -
Kyle Hall -
Martin Longo