Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

...

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
RequestsTBD

If you mark an item declared lost, claimed returned, missing, withdrawn and there are open requests on the item:

  1. There should be a popup letting you know
  2. There should be a link to the requests app (pre-filtered to show the relevant request(s))
  3. You can then move the request to another item or cancel it
  4. You can also use the requests csv report periodically to check for items with status declared lost, missing etc with open requests to catch any that might have been missed in this process

JIRA feature has been created: 

Jira Legacy
serverSystem JIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-2411


Requests

Delivery requests side bar convo:

  • Delivery requests have no service points (they have requester addresses)
  • When you check in a delivery request at any service point:
    • The system prompts you to check the item out to the requester
    • If you decline to do that, the request will stay in "Open - Awaiting delivery"
  • There is no notion of In transit for a delivery request
  • There is no notion of a delivery request fulfillment service point -
  • It sounds like folks would like to have the request status In transit until it gets to a fulfilling service point and, only when it gets there, to have the check in trigger check out to the requester
  • This would likely require flagging service points that can do delivery and some way of knowing which items should go to which delivery service points for fulfillment?
  • Cate will put this topic on the RA SIG agenda document for future discussion



Notes 

Holly Mistlebauer - 

  1. Fine/Fees Refund Button - Discussion on whether or not to remove the "Refund" button on the Fines/Fees history page.  Should the "Refund" button be treated the same as the "Error" button which is used selectively and only available in ellipses. Holly asked how many libraries do refunds on a regular basis.  Some libraries do give refunds on a regular basis.  Question asked if access to do refunds can be set in permissions to allow designated staff to handle refunds.  
  2. Manual Charges for Fines/Fees - Discussed need to identify manual charge fee/fine type for actual cost for developers and the need to add "Default" for Fee/Fine types using default notice(s). Through lengthy discussion it was determined that Holly will develop a demo to show at the next meeting to show how the table works.
  3.  Refunding fees/fines impact on Fee/Fine Details - Discussed refunding for two types of transactions, refund to the patron and a Bursar refund. Suggestion made to change wording of "refund" to "credit" to show amount credited to the patron or to Bursar.  Concerns expressed on how the credit will show on the patrons account in the end.  Holly will update for the MVP version and present changes at the next meeting. 

Cate Boerema - 

...

Reminder for everyone to look at Holly's video on using manual fee/fine charge table.

Holly Mistlebauer—Refunding fees/fines process

--Holly walked the group through a slide deck explaining how the refunding process will function for Round II implementers (Summer 2020), Round III (December 2020), and where we’d like it to be for Round IV implementers (Summer 2021) (Refunding fees/fines process)

--Holly will take the basic process forward to the Round II implementers to ask if this will meet their initial needs.

--Holly/Andrea are calling for volunteers for a sub-group for to determine needs related to the refunding process and institutional accounting going forward to Round IV. People may contact Holly or Andrea to sign up to be on this subgroup. Meetings on this sub-group most likely won’t start right away.

Cate Boerema—Request handling when item is marked declared lost, withdrawn, or missing

--Deck for discussion: https://docs.google.com/presentation/d/1T6D4W3tfswLnyrd61LWPHNcOFVL82-T5JA8CZBssPwk/edit?usp=sharing

--When marking an item declared lost, claimed returned, missing, withdrawn, but there are open requests on the item, the group suggested a pop-up that prompts staff for further action related to the request. Possibly with a link to the request (not MVP) so that the request could be canceled or moved to another item. Additionally, the in-app requests report would be another way to catch any requests on lost, claimed returned, missing or withdrawn items.

--When items are checked in with active delivery requests on them, FOLIO checks the item out to the requester to fulfill the delivery request, then the item is mailed out to the requester. A few group members were concerned that the item was checked out to the requester but may then need to be sent to the location that will mail it out for delivery. In transit is not used with delivery requests currently because there are no service points associated with delivery requests. This topic was flagged for future discussion by the RA SIG group.

Holly Mistlebauer—Discuss RA related MVP slippage PO MVP Feature Status

--Tabled until Monday