https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21727
--- Comment #13 from Tomás Cohen Arazi <[email protected]> --- (In reply to Martin Renvoize from comment #12) > Also to note.. the only use case that exists so far for this method is the > adjustment of the non-definitive 'FU' type accountline which is a 'still > incrementing' charge. > > I think the majority of accounts should be handled by other methods adding > credit/debit pairs and only 'non-definitive/in-progress' incrementing fines > should utilise this method.. > > One such incrementing fine I could think of perhaps wishing to use this in > the future that might make sense would be the introduction of a more > granular lost item charging scheme that acted as a buffer to 'overdue' and > would charge at a different rate whilst the user either found the item or > the system decided it was well and truly lost. (in such a case I would > expect an LU accountype to get paired with the existing L type). I would add the fact that this fee is either a fixed about (by itemtype) or the one specified in the lost item itself. On the second case, that value can get easily outdated compared to real bookseller prices in a changing world, so having a way to adjust that value makes sense in a future. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
