[Koha-bugs] [Bug 27080] Add --statute-barred-fees option to cleanup_database.pl to purge all fees where the item has been returned and the fee is older than the given number of days.

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27080

--- Comment #23 from Joonas Kylmälä <joonas.kylmala at helsinki.fi> ---
(In reply to Timothy Alexis Vass from comment #20)
> (In reply to Joonas Kylmälä from comment #19)
> 
> In the other situations "Renewed" and "Lost", it is different. Then the debt
> has been handed over to "Kronofogdemyndigheten", which is the Swedish
> Enforcement Agency.

What about RESERVE_EXPIRED fees? In Finland those could become statute barred
depending on whether the library reminds the customer about the fees:
<https://www.kirjastot.fi/forum/sakot-vanhenevat-kolmessa-vuodessa-135cf5>. I
think also RENEWED fees could become statute barred in Finland in the case
where the item was just lost for 1 day and patron went to library then
immediately and wanted to renew the book, and has been renewing it ever since
so the status is still RENEWED 3 years later.

> 
> > - Depending on your answer to the above question, would it make sense to
> > make the name of this option something more generic, like --unpaid-fees?
> 
> The only thing that makes sense is to call it --statute-barred-fees because
> that is exactly what it is. They are not --unpaid-fees, they are not
> --expired-fees, they are not --old-fees, they are fees that have been barred
> according to ruling statutes.

The problem with using statute barred term is that the legal definition and
usage of this option might vary by the region/country and library (if they have
different processes in place that prevent some things getting statute barred
like in the Finnish example above). How will the user know which country's
definition is being used? It is not good idea to do one statute-barred for each
country/region because it will make the program complex by having to adapt to
each case.

> > - The code is now not in a function, i.e. cannot be tested. Would something
> > like Koha::Account::Lines::statute_barred (depending on the scope of this
> > function maybe a different name) sound good to you? Then you can call
> > ->delete or ->count on those and the code will look super cool in the
> > script, wouldn't it? :)
> 
> Easy to maintain, simple code is preferred.
> I would suggest removing all this insane complexity and do database
> maintenance in the database, such as:
> CREATE EVENT cleanup_statute_barred_fees ON SCHEDULE EVERY 1 DAY
> DO
> DELETE FROM accountlines
> WHERE date < date_sub(curdate(), INTERVAL 1095 DAY)
> AND status = 'RETURNED'
> AND amountoutstanding > 0
> 
> Quite seriously, if you want to make it redundnantly complex because you
> find that interesting, you are free to make it happen.

My goal is the same, easy to maintain and simple code. Easy to maintain for me
means we have tests, then any modifications to the search method can be done
without testing manually all the places where it is being used. Maybe it is a
bit overkill, what do others think? Other benefits of using a function is that
now we can document the statute debarred fines in a standard way in the perldoc
that goes along with it. As for simple, I find
Koha::Account::Lines::statute_barred->delete simpler/easier to understand than
the call the search with multiple params, the same goes with the statute_barred
function definition: I will find it easier to understand the reasons behind
RETURNED, amountoutstanding > 0 when these are documented right next to the
lines of code in question either using variables or the perldoc. When this is
in a function we can also reuse this code in other places in the future.

-- 
You are receiving this mail because:
You are watching all bug changes.