Date

in scope: automatic renewal for fixed due date loans and rolling due date loans (hourly loans not clear yet)
out of scope: not a process to batch editing due dates, not an improvement in performance for large numbers of renewals in UI
automatic renewals need to follow all other policies and circ rules in use
possibly a obstacle or might be a future bug: count of renewals gets incremented, even if automatic renewal was not successful and due date didn't change.

Further discussion:

Generally in the requirements we should define how the scheduling of these automatic renewals should be working, what the schedule it should be based on (due date?) and how granular it should be designed. Would there be a scheduling for automatic renewals immediately at check out?

Regarding the notices, an automatic renewal should be the triggering event for a notice sent out. Best case would be two different notices available: a successful renewal notice with all the loans renewed, listed with the new due date and a unsuccessful notice with all the loans not renewed listed and (maybe) the reason why not renewed, since this is already working now and returned via API (like recall, max no of renewals reached, membership expired etc.).

Should the process be a scan every night? How many attempts to renew should be taken, if a renewal fails?

It could be defined that automatic renewals runs x days before due date and if it fails it should take x attempts until due date (every x days) and even until x days after due date.

Still this whole automatic renewal process would be a question of performace. Since it’s a batch process it should be happen in the night/not in service hours, but before the process of sending out notices happens. Especialls if there are thousands of renewals like in UChicago, which takes several hours. We need to figure out what would be an acceptable impact on a production system.

David says, the automatic renewals are not only a service to the customers, but also saves a lot of staff time.

How are we dealing here with loans that don’t have a due date (like faculty) or when there are really long loan periods like a decade?

Generally we need to see what developers say about the requirements for automatic renewals and when it comes to system rearchitecturing…

Use cases for more than one renewal run once a day: Magnus explains, ULi runs it twice a day, one in the morning and one in the evening and if a renewal fails in the morning, there is another try in the evening. This is useful especially for short term loans, but he considers this as not neccesary and just a nice to have.

Actually the automatic renewals make no real sense for short term loans, because then a longer loan period could be applied in the first place.

How could hourly loans be excluded from automatic renewals?

In some cases the process needs to be costomizable, when the renewal should be earlier than ususal, like for Christmas and New Year. There should be settings for exceptions.

Until this could be implemented, Susan says she is using bulk edit twice a year to renew due dates. Cheryl says, UChicago are using an SQL query which selects all loans with due date x and with an API call the renewals are done. A file with eventual rejections is returned. Cheryl also notes, this is a little tricky, since there need to be specified parameters for the SQL query.

In case a membership expiration date is before a due date, this needs to be excluded from renewal.

Bulk edit also might look into circulation concerns, but there seems to be no timeline for that yet.

What if the calenders need to be renewed? What if a service point is closed? This needs to be dynamic in the automatic renewal process, too.

Browser not supported