/
Round IV - Post MVP

Round IV - Post MVP

Jun 28, 2020

Audience and Goal

The primary audience for this document is the Capacity Planning Team. The goal is to communicate collectively at a higher level what these libraries need to go live that is beyond the Round III - MVP requirements, to identify possible workarounds that we might be able to share, and to identify specific critical path items that could either create a significant obstacle or enable some creative solutions.

Workarounds

We need to think concretely about what workaround might be viable, acknowledging that our available local effort is finite. Might we think about some of this functionality as: we need to do X, and we can step back from the full feature as long as we have Y plus local effort.

Needed functionality

All functionality implemented in Round II & MVP

Performance

  1. Ability to load 1,000,000 - 5,000,000 records in a reasonable period

  2. Ability to operationally load (including match, and merge) records in a reasonable period (50,000-100,000 records)

  3. Circulation performance at acceptable rates for check-in, check-out, renewal. (3 items per second or better.)

Upgrade in place

  • Ability to upgrade without having to reload all the local data

Custom Fields

  • Ability to store custom fields in the LDP

Improved Search

  • Further improved call number search and sort

  • Call number search outside of inventory 

  • Improved or fielded user searching

  • Normalized searching for title/call number

Metadata Management

  • Batch and global updates

  • Exports (generalized beyond basic exports in Round II and MVP)

  • Batch delete of inventory records

  • Transfer holdings and items (i.e. transfer holdings to a different instance record, transfer items to a different holdings record) https://folio-org.atlassian.net/browse/UXPROD-137

  • Data import: more sophisticated matching and overlay

  • Data import: import of delimited files

  • On-the-fly records https://folio-org.atlassian.net/browse/UXPROD-1057

  • Minimal PO information visible in Inventory UXPROD-1925, UXPROD-1995

  • Migrate Analytic and Bound-With data

Acquisitions Requirements

  • Financial transaction accounting https://folio-org.atlassian.net/browse/UXPROD-2295

  • Fiscal Year Rollover capability https://folio-org.atlassian.net/browse/UXPROD-1149

    • Several of us think we go live with the promise this will be complete with plenty of time for testing before first FYRO.

  • Print Serials Management:  Automated generation of pieces based on prediction pattern logic.  This feature is required by institutions that manage large volumes of print subscriptions and need the system to automatically created expected pieces with receipt due date. Current FOLIO functionality requires manual generation of pieces which will negatively impact staff productivity, and thereby, services to patrons. https://folio-org.atlassian.net/browse/UXPROD-194

  • Batch loading of Orders and Invoices

    • Some work expected as early as Q3

  • Managing external financial transactions with campus financial accounting system.

    • Best if workflows can happen in FOLIO, exporting results is the easy part, could do locally if API supports

    • Would need support from FOLIO for getting data out and updating with incoming from campus financial

    • Chicago-specific details below.

Donor recognition and tracking - touches multiple modules

Resource Access

Documentation

Chicago Gaps

This section is meant to facilitate discussion. This includes items that are intended for development but we are concerned could slip.

Some gaps may appear more than once as they affect different areas.

Big Issues

Cross-app entanglement between Orders and Inventory: Orders links to Inventory at all levels: items, holdings, and instances. The consequence is that moving an item to a new holding in Inventory now much account for and update that linking data in Orders. We had this problem in OLE and it consumed a lot of resources. Our position:

  • Orders should link to the lowest relevant level of the hierarchy, item for print or holding for e-resources, and use that to get to the instance when needed.

  • This might prompt some changes to the Inventory API to better facilitate accessing instance by item or holding.

Some features cannot be worked around, but there may be some critical component that would be enabling of workarounds outside of FOLIO. In Imports, if we could configure the protection of fields on a per-tenant and content-sensitive basis, that might allow us more flexibility. For sites with remote storage or automated storage systems, a storage retrieval request could enable those integrations.

Functional Areas

Acquisitions

  • Fiscal Year Rollover (no Q): https://folio-org.atlassian.net/browse/UXPROD-1149

    • We think we would be okay going live without FYRO provided it is complete in time for 6 months of testing before our first FYRO. But we would need that 6 month testing window.

  • Donor information (Q3): https://folio-org.atlassian.net/browse/UXPROD-1018

  • Financial Transactions (Q2) https://folio-org.atlassian.net/browse/UXPROD-2295

  • Import/export fund updates (blocker? Q3) https://folio-org.atlassian.net/browse/UXPROD-199

  • Import Orders/Invoices from MARC (Q4, do we think this is in jeopardy for MVP?)

    • Must be able to process Orders in batch

    • Must be able to process Invoices in batch

    • We have automated 80%-90% of our order and invoice loading, cannot manually absorb.

  • Managing external financial transactions with campus financial accounting system.

    • Invoice workflow: create, review, confirm totals, vendor number correct for external system. 

      • Approval step - formal approval that invoice can be sent to Accounts Payable.

      • Acknowledgement step - receive transaction number (i.e. check no.) from external system

    • Other workflows (largely for foreign currency) - if reviewd would still be in Pending state so could adjust amounts according to actual exchange rates used(labor savings and would simplify reporting)

    • We need some way to do this, whether though external app that we maintain locally, or within FOLIO. Better up through approval step if in FOLIO. After that, just need to export or pull results somehow.

      • We are submitting payments electronically to Accounts Payable.

    • See:

Integrations

  • Discovery Layer

    • Export for Discovery Layer

      • Public (non-supressed) bibliographic records in MARC/MARCXML, must include holdings and item info

      • OAI-PMH? Bulk Exports? Where do the Round IV libraries fall on this?

      • @Michelle Suranofsky has started framing in an exporter with Java and Python versions:  https://github.com/folio-labs/export-marc

  • Storage systems

    • Storage Retrieval Requests

    • Ensure we can send send needed data to Storage system

Metadata Management

  • Edit MARC records in SRS (quickMARC, Q2): https://folio-org.atlassian.net/browse/UXPROD-2263

  • Global updates (no Q for in-place; export/transform/import is proposed workaround)

  • Batch delete of inventory records (no JIRA)

    • Needed to recover from bad data loads? (e.g. vendor sends file with bad data)

  • Batch Exports (Q varies by sub-feature?) https://folio-org.atlassian.net/browse/UXPROD-652

    • Might need more analysis to identify specific priority features

    • Use cases

      • Export to discovery layer (workaround for OAI-PMH), full exports and deltas

      • Export for OCLC, HathiTrust, and other forms of record exchange

      • Critical to workaround expected lack of global updates, will need to export, transform, and reload records in order to do records maintenance at scale

      • For more examples and details, see Export Use Cases

    • Central go-live needs

      • Export of bibliographic records in MARC and/or MARCXML based on selection criteria

      • ability to include holdings and items data with bib data

      • Schedule defined export jobs and launch as needed

  • Batch Imports (no Q) https://folio-org.atlassian.net/browse/UXPROD-47

    • There is a critical problem in the area of protecting bib fields from being written over. Currently there is some hard-coded functionality, but does allow for basing decisions on tenant-specific data, such as the presence of a library's OCLC code in a field. This needs to be configurable on a per-tenant basis, and the APIs should have an option to override this protection.

    • Exporting batch import profiles https://folio-org.atlassian.net/browse/UXPROD-2099

      • Early in OLE implementation is was very useful to export and import batch profiles, we could try something in test, move it to production, even exchange profiles between libraries.

      • Would not need a UI if we could do this through APIs.

  • OCLC Holdings https://folio-org.atlassian.net/browse/REP-252

  • Change Item Status (no Q) https://folio-org.atlassian.net/browse/UXPROD-1731

  • Item status - Not Available (Q4) https://folio-org.atlassian.net/browse/UXPROD-2127

    • What problem is this solving?

    • Straw man: To support discovery layer/Z39.50/ILL discovery (and possibly other cases), we need to the item APIs to include a flag that indicate whether an item is available. This information is used in discovery to set expectations for users. The flag would be computed from item statuses. A site would configure Statuses like "not charged" or "recently recently returned" to show up as available, and statuses like "charged" or "missing/lost" to be not available.  A more precise description might be "item available/not available flag".

  • Acquisitions details visible in Inventory (no Q)

  • Custom item statuses (no Q, Q2 for withdrawn items only)

  • Transfer items/holdings to another instance (Q3) https://folio-org.atlassian.net/browse/UXPROD-137

    • Should be trivial within Inventory, but needlessly complicated by Orders

  • Preview data import (Q3) https://folio-org.atlassian.net/browse/UXPROD-669

    • Ability to review import results before committing an import. Alternately, need a test system with current data (within one day) to run imports before running in production.

    • Question: is this meant to include previewing loads that would affect areas outside of inventory, like Orders?

  • OCLC - single record update (Q3) https://folio-org.atlassian.net/browse/UXPROD-211

    • Dealing with outside of main project resources

  • Normalized call numbers (Q4) https://folio-org.atlassian.net/browse/UXPROD-2002

    • The purpose of this feature is to generate and store a machine-sortable call number for the purposes of sorting lists such as Loans and Fees/fines. The machine sortable call number will also be available for inclusion in reports (both in-FOLIO and external to FOLIO).

  • Migrate analytic and bound-with data (Q4) 

    • https://folio-org.atlassian.net/browse/UXPROD-1856

    • Concern is that we can migrate the analytic and bound-with data as much as possible, so relationships are preserved for discovery. Full functionality is not the migration obstacle.

    • Workaround is to create dummy items - real item record with hand-entered barcode with special item state.

    • Currently use "dummy" items for Analytics, Bound-with, and volumes held in the Shared Print Repository and not circulated from the ILS. (100Ks of items)

Resource Access

Round IV - Post MVP

Cornell University

Five Colleges

Duke University

Texas A&M University

University of Chicago

hbz library

Shanghai Library