More match point for POLIs with on-order item templates (including Item Template ID)
We would like the ability to match POLIs with on-order item templates on more data points, specifically shelf location, statistical code, and call number prefix. I expect that this means there would need to be extra fields to enter the POLI, and that would work out fine if that enabled the item records to be created accurately.
Our libraries use different shelf locations, statistical codes, and call number prefixes for items within the same collection. When placing an order, items are created from the on-order item templates, and only match on 3 data points: assigned branch, collection, and material type. These match points are insufficient to create accurate item records, and staff must manually change stat codes, shelf locations, and call number prefixes. This has long been a pain point for our libraries.
This also causes some conflict within the consortium and among libraries because we get requests to create new collections to accommodate the ability to have different on-order item templates populate the item records. For example, libraries want to create very specific collections such as Cooking, Travel, or Gardening, because they shelve these items separately from the regular nonfiction, or they have unique call number prefixes. This has become more common as libraries look to highlight different areas of nonfiction and reorganize shelving. We also have libraries using genre stat codes for Fiction and Movies, and designated languages for titles in the Foreign Language collection. Children’s materials are especially challenging as there are many different sets of items that have a different shelf location or call number prefix, but are essentially all part of the same collection. It does not make sense to create new collections for these very specific designations simply to facilitate the ordering and cataloging workflows. Having unnecessary collections is confusing to patrons as well because if one library is using a cooking collection, that is not representative of the entire cooking books that would be under the nonfiction collection in other libraries.
-
Sarah St. Martin commented
This is related to this request:
https://ideas.iii.com/forums/951742-ils-polaris/suggestions/46812364-more-match-point-for-polis-with-on-order-item-tempEssentially there needs to be a way to identify different on order item templates using the same collection (but with other information that differs) when creating a PO that does not make use of vendor records imported with 970 information. Staff either have to change the items after, or manipulating the bibs by adding a 970 tag to make use of different templates using the same collection. Both of these methods require extra manual work.
-
Sandy Homuth commented
This is a helpful suggestion!
-
Rachel Fischer commented
Not all vendors provide 970 fields in on order records. Some frequently used vendors, like Amazon do not provide on order records. When releasing a PO, Polaris frequently uses the wrong item template to create the item record. This is a common occurrence for libraries that have many item templates for each collection and material type combination. Staff frequently need to create the on order bibliographic record for material types like videogames because the bibliographic record doesn't exist when the PO is made. When the wrong item template is used, it causes acquisitions staff to have to manually correct the item record. This can take time. If a drop-down menu were added to the POLI for the item template, the correct item template would be chosen for these types of materials. It would save staff less time to correct the item record, and would improve patrons' access to these types of materials.
-
Beth Lane commented
This is a good idea for stats on manga versus graphic novels, and things on display.
-
AdminWes Osborn (Admin, Innovative) commented
Just throwing this out here in case anyone sees this and is unaware, but the 970 $h allows you to match on a specific template name rather than the rather unwieldy combination of other codes. I might like to see the length of the $h expanded from 10 characters to allow for more unique template names especially in a consortia environment where the first 3 or 4 characters of the template name are typically the library abbreviation.