Page Comparison

...

Overview

The primary driver in determining item resolution is speed of delivery.

Factors used to determine item resolution are:

• Circulation status

• Loans

• Holds

• Geographic proximity

Rules

• On-shelf ranks above loans, ranks above holds 

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

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

• When all item resolution determinants are equal (e.g. all items on-shelf) and geographic proximity is enabled and preferred suppliers are not enabled, use  geographic proximity to determine the item for resolution 

• 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.

Additional References

Item resolution requirements

Availability Date Scenarios for Resolution Ranking

Filter and Sort / Pool and Rank

...

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)]