Loan Policies: Renewing on Fixed Due Date Schedule

Basic loan rules functionality is now in place so we are beginning to work through the nuances of how loan policy settings impact loan due dates etc. These questions are primarily directed at the members of the Resource Access SIG who helped design the loan rule and loan policy functionality, but input from others is more than welcome.

Loan policies can have a Loan profile of Fixed, Rolling or Indefinite. When Fixed is selected, the administrator must select a Fixed due date schedule (e.g. Quarter, Semester etc) for the system to reference when calculating the due date for the loan. This is straightforward for the original loan due date. Logic for calculating the original loan due date is documented in UICHKOUT-66.

Where this gets a little tricky is with renewals. When a loan profile is Fixed, we also reference a Fixed due date schedule for the renewal period. The default we have defined is that the renewal period will be calculated using the same Fixed due date schedule as the original loan.

Let’s consider the following scenario:

• Loan policy associated with Loan X has:
  – Loan profile = Fixed
  – Fixed due date schedule = Semester containing multiple date ranges including this one:
  ---- Date from: January 1, 2018
  ---- Date to: June 1, 2018
  ---- Due date: June 10, 2018
• Loan X checkout date was on February 22, 2018 which, according to the date range above means the original due date is June 10, 2018
• Loan X is renewed on March 15 which, according to the date range above, means the due date is unchanged

Questions:

1. If renewing Loan X on March 15, 2018 doesn’t change the due date, should we disallow the renewal? This would mean:

• Renewal is not recorded as a loan action
• Renewal doesn’t count against the number of allowed renewals (assuming there are not unlimited renewals allowed)
• We’d want to message the user with something like “Renewal not allowed at this time”

2. If Loan X is checked out on a date which is not covered by a date range in the selected Fixed due date schedule, am I correct to assume we should prevent checkout and display a message such as, “Due date cannot be calculated from loan policy: . Please check the loan policy before re-trying check out.”

Screenshot: For reference, this screenshot shows many of the settings mentioned above:

image660×668 16.2 KB

For question 1:

• I think the response should be as you describe. We’d want something a bit more specific in the message. (e.g. renewal would not change due date).
• • You’d want permissions & override to allow for a manual change to allow for exceptions or force the count.

For question 2:

• Again, I think the response should be as you describe and the message might be a little clearer as “Due date cannot be calculated from loan policy: Date range not set for this loan policy”.

1. I agree with Andrea, it would be nice to give the patron more information on why there is no renewal in a self renewal situation. The more info the better! I do like the idea of it now affecting the renewal count unless the library wants that.

2. Again, in a self renewal situation, more information in the error message is needed.

However, I defer to those who do this.

Thanks @andrealoigman and @DebLamb! I’m now thinking the following for the messages:

1. If the check out date for Loan L does NOT fall within a date range in Fixed due date schedule F:

• Check out is prevented and error audio alert should sound
• An error modal popup should display reading:
  – Header: Item not checked out
  – Body: Item can’t be checked out as the loan date falls outside of the date ranges in the loan policy. Please review Loan Policy X before retrying checking out.
  – Buttons: Okay

2. If the renewal date for Loan L does NOT fall within a date range in Fixed due date schedule F:

• Renewal is prevented and error audio alert should sound (do we want this with renewal as well as with checkout? @mac609_lehigh?)
• An error modal popup should display reading:
  – Header: Header: Item not renewed
  – Body: Item can’t be renewed as the renewal date falls outside of the date ranges in the loan policy. Please review Loan Policy X before retrying renewal.
  – Buttons: Okay

3. If the renewal does not differ from the previous due date:

• Renewal is prevented
• An warning modal popup should display reading:
  – Header: Header: Item not renewed
  – Body: Renewal at this time would not change the due date.
  – Buttons: Okay

I agree with your conclusions about question one with the expectation that the error message would be specific and informative. e.g. “Item not renewed: Renewal at this time would not change the due date.” Also, an audio alert should sound for a desk operator.

The second question is more complex. I’m not clear about what you mean by “not covered by date range”. Do you mean dates from June 2-9? It seems those dates should still use the fixed June 10 due date.
Do you mean dates before January 1? It seems another default loan profile policy should be used.
In many cases we will use rolling (calculated) due dates throughout the semester but with a fixed end date like June 10; so there may be a combination of rolling and fixed due date policies. For example:

---- Date from: January 1, 2018
---- Date to: May 11, 2018
---- Due date: Rolling 30 days.
---- Date from: May 12, 2018
---- Date to: June 10, 2018
---- Due date: Fixed June 10, 2018

So, if the checkout date is out of range for the fixed date profile, the default (rolling) policy will be used.
If there is truly no default loan policy which would apply then the error modal (with the audio event) should appear. Perhaps a date selector should be presented as well to provide the operator the opportunity to pick a due date (depending upon permissions). Hope this is on point to your questions.Thanks.

The logic is fine. The messages need refinement. We say something like ‘Items not renewed because due date would not change.’

An override is needed if a fixed due date has not been loaded. Checkouts need to continue while the error is corrected.

Thanks @mac609_lehigh. Question 2 from the original post is about the scenario when a check out (or renewal, for that matter) is initiated on a day that falls outside of all defined date ranges in the associated Fixed due date schedule (FDDS). If the FDDS is properly set up, this shouldn’t happen, but, it could happen if the administrator responsible for setting the FDDSs made a mistake. I think this is really an edge case.

But just so we’re clear, here’s the scenario: Suppose you try to check out an item on July 15, 2018 and the loan is covered by a Loan Policy X which is itself associated with the “Semester” fixed due date schedule shown below. As you can see, July 15, 2018 isn’t covered by any of the date ranges and so it will be impossible for FOLIO to calculate the due date. The proposal here which folks seem to agree with is that, in this scenario, we prevent the loan (or renewal) and throw an informative error message. Does that work for you?

image1365×536 17.5 KB

Of course, not all loan policies will reference Fixed due date schedules. Many will have rolling profiles and we also have the possibility to use a combination. If you want to refresh your memory on what we specified for the Loan policies, you can find the metadata document here and wireframes here.

Thanks @cmalmbor. Can you elaborate on what the override would do in this case? I was assuming that, when the due date can’t be calculated, an error message would pop up, the item would not be checked out and the circ desk worker would just close the popup and put the item that can’t be checked out aside. If they wanted to go get a supervisor to fix the Fixed due date schedule, they could do that, or they could just proceed with the rest of the checkout session or move onto the next patron.

If we took this approach, I don’t see why an override would be needed.

Were you picturing something different?

Cate,
I was thinking both of the situation where no fixed due date was loaded and where no loan policy is found. It is not always possible to quickly remedy the situation. It is bad public relations to make a patron wait because of a staff error.

I think we something like what OLE provides which is a window where an authorized person can enter a due date and time when the system cannot calculate a due date.

I will attach an example

image1680×1050 190 KB

For question 1:
Personally I prefer an UI that does not encourage impossible actions. Therefore renwal (button, checkbox in list) should be “grayed out” and perhaps explained by a short message. The message could be displayed “nearby” or when hovering over the item.
If calculating the renewal state beforehand is too expensive, the “error” approach is a possible remedy.

Again, belatedly, I agree that renewing an item where the due date would not change should behave in the way described–,message that the renewal will not change the due date, no change to the renewal counter.

It’s important to remember that such messages need to also be available via APIs, NCIP, SIP2, etc. so that renewals by patrons via discovery layers, self-checkout machines, etc. will provide the same message.

The error message for failed renewals is particularly important (and not necessarily calculatable in advance) because of things like discovery layers, self-checkout, etc. as well as the ubiquitous “Renew All” option.

Could the messages be customizable to some degree, at the tenant level perhaps?

I strongly agree with Cheryl about the need for appropriate staff to be able to perform an override checkout if no rule can be found. This should be controlled, of course, by permissions.

Thanks @cmalmbor. How does the authorized user trigger this override window so the due date can be set manually?

Thanks, @dbottorff. I think the messages could be configurable, but probably not for v1.

The fact that these messages will display to patrons when checking out or renewing on their own is interesting. It seems like the wording you’d would differ for those scenarios. For staff, you might want to include, “Please review Loan Policy X before retrying renewal” while, for patrons, that wouldn’t make sense.

I guess FOLIO could generate two error messages, one for operators and the other for patrons but, again, it seems out of scope for v1. Can the discovery layers be made to display a message that differs from what is supplied by FOLIO?

I may be wrong, as others are more expert than I am, but I don’t believe VuFind, our discoery layer, supports displaying anything other than the system error out of the box. I would say if messages cannot be configured in V1 we should try to come up with language that will be “good enough” in all scenarios if possible.

Can we double check on this? Because making messages that work in both the patron and staff scenarios will significantly limit their usefulness to staff and would go directly against the specificity @cmalmbor, @andrealoigman and others were asking for.

Folks with 3M self checkout stations should weigh in on this, but I know that our install of VuFind simply displays the error message released via the API. If we can have two messages, one for staff and one for the SRU, that would be fine. I can check with our staff, but I imagine VuFind doesn’t support this natively and would require custom development by the institutions using VuFind. I’ll check.

David W. Bottorff
Head of Collection Management and Circulation
The University of Chicago Library

Cate, I’ve confirmed with our staff who develop and support out local VuFind instance that string substitutions can be expensive in terms of system resources and page load time, so generally it’s something we avoid doing. I’d be really curious if others have different messages depending on whether something is staff facing or patron facing.

David W. Bottorff
Head of Collection Management and Circulation
The University of Chicago Library

Cate,

Tod Olson, our Systems Librarian, contributes the following:

I’ve been through many iterations of catalogs and tweaking messages for local use. It is much better if the public message in the underlying ILS can be configured, that usually leads to better re-use. The other possibility would be for the error responses to contain both a code and a message, and we could somehow provide a lookup service for our custom message. If the error comes back as structured data. Just groveling text is rotten, and having to transform the text outside of the ILS is not optimal. Local configuration is preferable.

-Tod

David W. Bottorff
Head of Collection Management and Circulation
The University of Chicago Library

Thank you @dbottorff and @tod. After discussing further with development, the plan is to take the following iterative approach:

• Iteration 1: Hard-coded error messages tailored to FOLIO operators (such as those described in UICHKOUT-66 and UICHKOUT-67)
• Iteration 2: Add hard-coded error messages tailored to patrons
• Iteration 3: Create Settings pages for tenant customization of both types of messages

We still need to work through the details of iterations 2 and 3 so I am creating a feature for the analysis work here: UXPROD-266

Thanks @cmalmbor. I wanted to follow up on this. Can you (or anyone else) talk me through how the override window is triggered? For example, let’s assume that check out fails because no loan policy is found. An error message displays to the circ desk worker. They go get their supervisor so they can override and allow the item to be checked out by manually specifying a due date. How does the supervisor trigger the ability to override? Do they need to enter their username and password or a special code somewhere?

Cate,
If the operator currently logged in does not have override privileges, an authorized operator logs in using their username and password and does the override. The unauthorized operator then needs to log back so that override privileges don’t remain in effect.

Thanks, Cheryl! This makes sense.

It’d be great if the operator coming across these messages had a way to alert someone higher up to go and look at the policies (assuming they didn’t have permission to fix it themselves). Not sure how to make that work though.

I think we’ll have some good descriptive text in the error message telling them why the checkout failed and what policy it was associated with. This would be the staff-facing message (we will implement a more generic patron-facing error in a later iteration). Then we would also offer the ability to override and enter a due date manually (assuming you have permissions to do that). Does that work?