Page Comparison

...

Overview

Introduce new item resolution capabilities that increases the volume of OpenRS borrowing and the speed of item delivery to patrons. Other item resolution capabilities will better balance the distribution of item requests for suppliers.

In the first release of new item resolution capabilities, OpenRS will allow requests on items with holds and, items that are checked out.

In a subsequent release, two additional capabilities will be introduced. One is to prioritize item resolution by preferred suppliers. The other is to use automated request balancing to provide more even distribution of item requests to suppliers.

All request capabilities must be compatible with one another and yet must stand independently without reliance on any other resolution factor. A set of rules and the ordering of those rules is intended to funnel down to the item which best achieves the goal(s) of the capability. For the first release, the order of rules will remain static. For the subsequent release, it is yet to be determined whether static or dynamic ordering will be required.

Scope

Releases

Requirements, implementation and deployment are staggered by release and grouped by customer.

Release 3 will meet the delivery of MOBIUS contractual development:

Release 6 will meet the delivery of GALILEO contractual development:

Functionality

Item resolution factors

Following are the item resolution factors corresponding to each capability. The list includes existing and new capabilities by release:

• Circulation status (existing)

• Geographic proximity (existing)

• Loans (release 3)

• Holds (release 3)

• Preferred suppliers (release 6)

• Auto request balancing (release 6)

Rules

Loans and holds

The following rules ranked by order of evaluation are intended to support the goals for each capability:

• On-shelf ranks above loans, ranks above holds 

• When all items are loaned, the item due soonest is selected 

  • Overdue items are not resolvable.

• When all items have holds, the item with the least number of holds is selected. 

• If a library system is unable to supply an item count of holds because the platform does not support it (e.g. Polaris), rank items from that library lower than other libraries that are able to provide hold count.

• When all item resolution determinants are equal (e.g. all items on-shelf) and geographic proximity is enabled, use geographic proximity to determine which item is selected to place the request

  • If no other resolution determinants are enabled, choose an item at random.

Preferred suppliers and auto request balancing

• When preferred suppliers are also enabled, use a preferred supplier from the same group. 

• If more than one supplier in the same group, use geographic proximity OR load balancing to make the selection 

• If a preferred supplier is not found, and more than one supplier is outside the preferred group, use geographic proximity or load balancing to make the selection

Acceptance Criteria

• When an item is not selectable…

• When an item…

...

Additional References

Item resolution requirements

Availability Date Scenarios for Resolution Ranking

Filter and Sort / Pool and Rank

...

1. Item is from borrowing library’s preferred supplier group

2. Item is available (on shelf)

3. Item is currently loaned

   1. due soonest

4. Item has holds

   1. fewest holds

5. Geographic proximity

Technical Notes

...

Resolution strategy

How re-resolution should work with preferred supplier and load balancing features

Previously included in the context of DCB-1411 (Ian Ibbotson)

Currently org.olf.dcb.request.resolution.PatronRequestResolutionService has a method resolvePatronRequest which is called once in the flow. This story will cause re-execution of this method.

...

In this way resolution strategies are entirely isolated from the re-request process.

Sort order

Previously posted in #dcb-requirements

Ian Ibbotson

"As a developer" I think it over complicates the work to separate out on shelf from holds. We should blend the two.

1. Due date is not a good guide to availability-date once queue depth is > 0 because it's the return date of the current loan so it gives no indication of when future loans may be returned. All of these concepts should be blended into "AvailabilityDate" which

   1. defaults to now() if the item is on shelf,

   2. due date if the item is on loan but hold count is 0, or

   3. due date + ( default loan period * hold queue depth) for queue depths > 0.

2. The "Default" system wide sort order will be [ "availability-date" ]. The system works by sorting by availability date desc and them choosing the first item available from a supplier not already tried.

3. Libraries need to be able to configure the sort criteria for their patrons. On a per library basis in the admin app the sort order can be changed for an institution. Sort order is a list of criteria which includes availability-date and the following fields:

   1. geo-distance from pickup library to lending library

   2. supplier-group priority (1,2,3,4,5..) Each library will configure it's preferences

Libraries will be allowed to choose the order - so [ 'availability-date', supplier-group-priority, 'geo-distance' ] - would give items on shelf priority and within that supplier group and then geo distance.e.g.

DueDate - Supplier Group - Geo-distance
01-Jan-2025 - 0 - 1.356
01-Jan-2025 - 0 - 6.4
01-Jan-2025 - 1 - 34.6
01-Jan-2025 - 2 - 10.4
01-Feb-2025 - 0 - 2.5

Tim Auger

Are you saying that availability-date is something that libraries could choose sort independently or just Supplier Group and Geo-distance? It seems that you are saying that all would be configurable by supplier library.

Ian Ibbotson

Well - we might not want to allow the first sort criteria to be selectable - but thats a UI thing - backend its all part of the same mechanism yes

Increments

Preparatory refactor: preserves existing behaviour

1. Change resolution strategy to sort only and not select (chooseItem)

   1. Move manual selection out of resolution strategy and into resolution service

2. Introduce availability date (setting as today (at start of process) for available items)

   1. what is the impact on

      1. request diagnostics

      2. shared index / availability reporting

   2. how do we expose this to DCB Admin? do we need to?

3. Reorganise resolution to

   1. sort by availability date,

   2. then by resolution strategy (eg, geographic distance) (as tie-breaker)

   3. then choose first ordered (handled in Change resolution strategy)

Verification: should work the same as now. Regression testing on parity basis.

Support requests on checked out items

4. Add consortial settings to enable or disable requests on checked out items

   1. [add DCB Admin option for consortial setting for requests on checked out items]

5. Change selection filter to include checked out items

6. Set availability date to due date for checked out items

Support requests on items with holds

7. Add consortial settings to enable or disable requests on items with holds

   1. [add DCB Admin option for for requests on items with holds]

8. Change selection filter to include items with holds

9. Increase availability date based on hold queue and default loan period

10. Compensate for lack of hold count data from Polaris

Add diagnostic and configuration support

11. expose due date and hold count in request errors

12. expose due date and hold count in live availability

13. expose due date and hold count in DCB Admin shared index

14. [add consortial setting for loan period (days)]