Floating collection (UXPROD-4969, UXPROD-816)

Owned by Charlotte Whitt
Last updated: Oct 30, 2024
3 min read

Floating collection is defined as a group of items that are not housed permanently at a specific library, but are shelved at the library where they were most recently checked in. Floating collections are used to decrease transportation of items between libraries and to reduce manual handling, transit time, shipping expenses and/or traffic emissions.

For an item that is part of a floating collection, the item's library is changed whenever the item is checked in at a different library. The item belongs to whichever library last checked it in for shelving.

If a book that is part of library A:s collection is checked out at library A, and then checked in at library B, it will not be returned to the shelves of library A, but instead, its new home is library B.

Current state:
Circulation in FOLIO does not support Floating Collections. Around 30% of Linköping University’s physical items are part of their floating collection. 65% of check outs come from items in the floating collection.

Implementation of floating collection support

The support of floating collections is enabled with a single change to the data structure: A new boolean property, isFloatingCollection, which is added to the location object in Inventory Storage, as shown in the entity-relation diagram below.

The floating process then happens in mod-circulation at check-in, all based on whether the location.isFloatingCollection flag is set to true on the item’s origin location and on any of the locations served by a remote check-in service point.

Screenshot from 2024-10-26 20-11-20.png
mod-inventory-storage, new property in location

 

If an item has an effective location with this flag set to true, and if the item is checked in at a remote service point that is associated with another location that also has the flag set to true, then the item can “float”, that is, it can switch location instead of being put in transit back to the origin service point.

The check-in process in mod-circulation will look for the isFloatingCollection flag on the effective location of the checked-in item and it will look in the check-in service point for a serviced location that is also a floating collection that the item thus could be relocated to. If one is found, then that location will become the item's new effective location, technically by setting the item's temporary location to the new location.

Additional notes:

  • If the item’s effective location is not a floating collection, then the usual logic will apply, for example by putting the item in transit back to its home service point if it’s checked in at different service point.

  • If the check-in service point has no locations that are defined as a floating collection, then the usual logic will likewise apply.

  • If there’s a request on the item at another service point, then the item will not float through the check-in service point to a new location, but, rather, the usual logic will apply, putting the item in transit to the service point with the request.

  • If the check-in service point has more than one location defined as a floating collection, then the check-in logic will arbitrarily pick one of them and relocate (float) the item to that. This obviously suggests that each service point should only have one floating collection defined. The back-end module storing service points and locations (Inventory Storage) does not enforce that, though.

  • When the item changes location at check-in, then the pick slip context will be populated with the institution, campus, library, and location of the new location instead of the corresponding location units of the previous location.

Further developments?:

There are no currently known use cases for multiple floating collections per service point, say, for different floating collections for different material types. The solution with one floating collection per service point could be extended to support multiple collections, though, presumably by defining float groups, that the participating libraries/service-points were aligned on. Implementing “float-groups” or “float-circles” on top of this solution would likely be a fairly simple undertaking, adding a float group property to the location in mod-inventory-storage and tweaking the new float logic in mod-circulation.