2021-04-26 Resource Access Meeting Notes

Date

Attendees

(OLD ACCOUNT) Erin Nettifee

Elizabeth Chenette

Thomas Trutt

Marie Widigson

Sharon Wiles-Young

David Bottorff

julie.bickle

Brooks Travis

Mark Canney

Monica Arnold

Christine Tobias

Andrea Loigman

Erin Weller

lisa perchermeier

Andy Horbal

Martina Tumulla

Rameka Barnes

Robert Scheier

Kimie Kester

Laurence Mini

Cheryl Malmborg

Rebecca Pernell

Cornelia Awenius

Joanne Leary

mey

Jana Freytag



Discussion Items

TimeItemWhoDescriptionGoals/Info
2minAdministrivia


20MinBatched fee/fine notices


UXPROD-2252 - Getting issue details... STATUS  - the ability to send batched fee/fine notices


10MinPatron photos

Importing patron photos in user records

UXPROD-36 - Getting issue details... STATUS


10MinPointing ProcessallGeneral discussion and special pointing for RA topics?

Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached

Reasoning

Link to supporting materials

Comments

e.g. loans, fees/finesNamee.g. Q4 2018, Q1 2019Clearly stated decision
  • Because...
  • Because...
e.g. mock-up, JIRA issue




























Notes:

Darcy is not available for today, but she will be here for Thursday’s meeting and we’ll discuss batch fee/fine notices.

TOPIC 1 -- David Bottorff (UXPROD 2252) multiple fee/fine charges or actions (pay, waive, transfer, error, or refund)

The batching of various fee/fine notices. UXPROD description is misleading. This also includes the original creation of the fee if you auto-bill items that are lost. Most ranked this as R1, and it got ranked as R3. The backend estimate was XXXL (wondering if this is still considered a correct estimate – 30-45 days). For Chicago this is a big problem because it could mean when 200 items age to lost, then 200 emails are sent to a single patron. In the case institutions that charge both lost item replacement fee and lost item processing fee, this means the patron would actually receive 400 emails (one for each item).

Should this issue be split:

  1. Single batch overnight process like aged to lost. Wouldn’t want email notice for a payment to be an overnight job because that email is needed right away.
  2. Session “receipt type” notice – where patron needs notification acknowledging they’ve paid (action taken on a fee) also returned an item and fee was then waived

Erin agrees that batching aged to lost could be a separate feature (seems like check in/check out/ and courtesy)

Second how we treat pay/waive/transfer/error/refund (action take on existing fees)

This JIRA scheduled for Juniper but fallen off, not currently associated with a release date

David’s suggested workaround is to create a separate overdue notice template that goes out right before aged to lost happens -- telling patron we will be billing you for items ($X per item). Refers patron to their My Library account for details.

Suggestion was made for the RA SIG members to consider adding points to this issue for it to be addressed in Kiwi. Duke is allocating almost all points (Kiwi) to metadata management features.

David talking with Darcy and Julie who says, “including more than one action within a charge is straightforward, it is including more than one fee/fine charge on a notice, there’s no way to batch them unless instead of triggering on the charge we change the way these are processed into overnight batch notices but want to ask RA SIG before assuming that would work for all.”

Initial charge for most things should work well – overnight is probably soon enough. But if patron paid for 6 books, business use there of session notice email being sent at end session.

Perhaps initial thin thread would be separate emails sent right away OR one email sent overnight.

Thomas Trutt suggest batching every hour for payments or forgives. But brings up the question How long do batch processes take?

With checkin there’s a session concept, but with fees/fines action – no session concept? It would need to be created.

Concern for Cornell, Texas A&M, Chicago, Duke, and most likely others.

If you suppress all notices and send a generic message – go check your account, you would still get multiple notices for each transaction. Suppress all, create a custom report that does all notices separately.

Create a final overdue notice – sent as 200 items on one notice – you have now been charged for some items that have been declared lost. Please return or renew your items. Please see your account for addition info on titles and fee amounts.

Courtesy/overdue notices are batched, and do include multiple items.

Fee/fine notices are not batched

Discussion about when specifically you would send this notice (an after due date notice).

Brooks Travis notes: This assumes that all the items are using the same notice policy – 200 items could have multiple notice policies at play (3 different notices grouping the items by notice policy being used)

Do we need a token that’s more like a total? “Your total now owed is . . . “Fee/fine balance token for notices wouldn’t be a bad idea. What is your current balance and what is the total of these transactions that are being batched?

David was on the actions but not the charges. Others mention that it seems too late to get this into a release soon. We could try to get it into Kiwi.

Books likes the idea of splitting it up – fee fine actions (paid, waived, etc.) versus accounts

For more info on this, see Considerations for Data Migrations --fees and fines https://folio-org.atlassian.net/wiki/display/FOLIOtips/Considerations+for+Data+Migration+-+Fees+and+Fines

Cornell charges no processing fees or overdues except recalls, and says aged to lost workaround will work for them.

Separate declared lost notices – your borrowing privileges have been blocked.

Unclear how the timing would work. Overdue notice and aged to lost go at what time? Overdue notices go the same day as aged to lost?

Could use the overdue batch emails and change text to: “this has aged to lost” Sequence based on the number of days from the due date.

Overdue fines happen at check in (at the moment of return).

Feature for German libraries for incremental fines (those go out in real time? Yes) overdue fine creation notices is a session batch from what Darcy said last time:

  • Check in notice = batch
  • Fine creation notice = batch

Renew wipes out fines if you send waive email because that is also 200 notices

JIRA 1684 batching overdue notices. Closed and done. This one is not overdue fine creation notice

For legal requirements, German libraries need system to charge a certain amount after one week and send a notice of that charge. They want to run an overnight process once or twice per week to see which patrons should be billed when they are overdue.

Goldenrod options due date/time trigger, can be batched, processed overnight (https://docs.google.com/document/d/1BO4HgW4d8gah6dpozpnucJ1zulfkBA2ASdL7HXuzZEo/edit# - Goldenrod documentation)

Fee/fine notice are not batched

In workaround scenario, you would never send overdue fines returnes notice only send due/date time trigger notice and use the template to say what you need. And direct patrons to their account on webpage for the amount. Due date time trigger notice no access to tokens.

Need input from Darcy so that we can discuss splitting this JIRA out.

Not trying to get this working for IRIS

TOPIC 2 -- David Bottorff next topic – Patron photos

UXPROD 36 (David will add a comment to this.) In UI there’s a place for photos, but not place to put the photo. If there was a place to put the photo would RA SIG want to be able to display the photo at check out? Especially now when many institutions pushing self-checkout and may not handle cards. Duke built something to support multiple ID types, Stanford also uses multiple IDs. We have a really old mock that shows the placement of a pic: https://drive.google.com/file/d/1plwbtSSkDJ2v1FiJQBkF3vw1Q-jTD8kn/view?usp=sharing Kimie says she would be happy to create an updated mockup based on current FOLIO and then including the placement of the pic.

TOPIC 3 – Rameka Barnes question about the pointing process for other institutions.

What RA topics are others assigning points to?

Duke assigning points to 4 issues:

  • Ability to freeze patron record
  • 2 dealing with requests
  • Items status history

Brooks says it is difficult ranking R1 and R2 to assign points. For them even the R1 and R2 equal about 200 features. A team at his institution will meet on Wed to look through them and prioritize to add points.

Chalmers will give points to Requests Title-Level Requests (Complete) UXPROD-1796; Fees/Fines Future Fees/Fines: Delete fee/fine data after interval set by institution UXPROD-2646; Loans Circulation statistics for item on item record UXPROD-1327; Loans Automatic renewals UXPROD-2375; Requests Requests: Anonymization of closed requests UXPROD-1041; Requests Search Requests by Instance ISBN UXPROD-2107; Requests Make Hold Shelf Expiration Date Respect Closed Library Days/Hours UXPROD-1636.

Chicago, is assigning points to metadata management. They have a significantly smaller staff, and have leveraged auto processes with previous system, so they need those features.

Cornell, has an implementation team, prioritizing now: 2252 , 10 points; 120 Bulk edit (20 points); 2062 retaining custom fields data after anonymization (10 points).

Duke not planning to anonymize when they go live. Waiting for those features to be implemented fully before putting these into use. Not being avail. Anonymize on request for patrons who complain.

Chicago not anonymizing.

Erin added this to https://folio-org.atlassian.net/wiki/display/FOLIOtips/Alternatives+for+Features+Still+In+Development

Right now, aged to lost emails send one by one, and are not batched. They also send one by one for lost items and replacement costs.

The workaround is to use a notice with a date/time trigger (which does batch and send overnight for multiples) and send a notice the day an item goes aged to lost, telling the patron that the items have aged to lost and directing them to a webpage to see the charge. Then, do not send an aged to lost notice.

As of Iris, the scheduling of aged-to-list processes is up to individual hosting providers, so the timing of this is up to the individual school. Ideally you would have the item age to lost shortly before the fake aged-to-lost notice is batched and sent.