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