Serials Receiving - Overview of decisions/discussion at Chicago
- Receive directly in Inventory
- Managing the location of Unbound issues
- Managing public display
- Keeping appropriate notes
- Migrating existing POs
| | Current process: - Use OLE for serials receiving. No predictive check-in
- Chicago current staffing and volume:
- Serials Management Services: has two FTE in receiving, handle unbound periodicals, invoices series, and basically anything that is a continuation
- 1.5 FTE at Law, plus specialists in East Asia
- OLE Serials Receiving Records: over 26,000
- about 7000 have no receipts at all
- about 66,000 "public display" received pieces marked for public display
- Show unbound/bound location
- Not currently using our library system for claiming purposes, not using ILS for claiming
- Demonstration of Serials Receiving Record in FOLIO
- Bound/unbound location
- Status: currently received/not received
- Lots of notes for different purposes
- claiming never fully implemented, but it was going to use a date based on item last received
- Caption information for how receipts should be recorded
- Receive/receipt history of pieces
In FOLIO: - Will not receive serials using the Receiving App
- Will receive straight on the holdings record in Inventory
- we will lose some data compared with what we have now
- Until Receiving provides a link between receiving non-item pieces and inventory, we will wait to use Receiving
- Anticipate that our discovery system, VuFind, will continue to provide access that way
- In FOLIO, we have to decide whether to have the unbound issues on the bound holdings, or if they should be in a separate holdings record
- Decided to put on the same copy as the bound location record
- Adding a note for Unbound location
- This is not validated against our location codes, so we'll have to periodically review and clean up
- This is display in Vufind
- Want to use the Unbound location for label printing
- Will map notes from SRR in OLE to notes in FOLIO
- includes the number of SRR
- Includes the purchase order number
- OLE will continue to exist in an archive to look things up for reference
- Receiving will be done on the holdings record. Can only enter piece information, will lose receipt date and who received the item
Comments - Duke has "traveling serials:" unbound location, temporary current location, and then older permanent location - may need to track this movement through notes
- FOLIO will not resort to show receipts in current order, which means they will not display in order and will make it more difficult for claiming
- Predictive check-in makes spot-claiming "by eye" much easier
- Duke: when renewals happen, we check receipts to claim issues that haven't been received
-
UXPROD-2373
-
Getting issue details...
STATUS
relates to connection between holdings and receiving
- This connection will need to be made in order to allow for receiving to happen in the receiving app
- This will also allow for Orders to be updated if items/holdings are moved in Inventory
- Without knowledge of inventory items being connected to acquisitions, this can lead to data corruption
- Moved holdings and items will also result in incorrect reporting, as PO/POLs still associated with original inventory records.
- Mount Holyoke: you could put expected pieces on the holdings record; you would want a way to indicate that something is not yet received
- Cornell: could create a spreadsheet of expected items and batch load that information into the receiving app - could be functionality that a group of libraries could fund - would provide similar functionality to predictive check-in
- Mount Holyoke: ways to receive items that don't have content in inventory, FOLIO should support this.
- Chicago: receiving in inventory in part because we receive some items that we don't have POLs for (e.g., free stuff, federal depository).
- Duke: if we circumvent the receiving app, and just use inventory, what happens will the PO still behave appropriately? - may depend on how the order is set up (is it associated with a piece? Is receipt required?)
- Container record could help with avoiding dummy records
|