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:
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â
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:
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â.
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.
Again, in a self renewal situation, more information in the error message is needed.
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
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
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.
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?
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.
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.
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, @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
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
