...
Question | Status | Conclusion | Comments | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Can we limit to 0xx and 9xx fields? |
| Probably OK | Devs need to confirm if MARC-MARC matching capabilities can be expanded, e.g. 924$a to 924$a | ||||||||||||||
| Any different considerations if the match-from and/or match-to field is repeatable? |
| so long as matches to single instance, holdings, or item, should be able to update | From: If copies ordered at the same time, but on separate POLs (for different acq units or locations) To: Instance linked to multiple orders, Holdings linked to multiple orders Is an item ever linked to multiple orders? A-M asking on Acq channel Needs to try each of the froms (if multiples) Needs to try each of the tos (if multiples) | ||||||||||||||
| Confirm appropriate test cases for E-to-E automated tests |
| See use cases above Test 1: POL, Instance source = FOLIO, update all record types Test 2: POL, Instance source = MARC, update all record types Test 3: VRN, Instance source = FOLIO, update all record types Test 4: VRN, Instance source = MARC, update all record types Add negative test cases - no matches or multiple matches | |||||||||||||||
| Do we need to break out vendor ref number types, like we do for Identifiers? |
| For now, do not break out the different vendor ref number types; if use case arises in the future, consider breaking out, similar to how the Instance identifiers are broken out | |||||||||||||||
| Can we remove some unused match data elements? |
| Leave for now; as users test more of the match elements in the future, correct or amend on a case-by-case basis, Besides, that enlarges the scope of this feature | |||||||||||||||
| Match on POLs with which statuses? |
| Per Christie, would want to be able to choose the POL status for successful matches Per Raegan, this is not a scenario that comes up for them | Open = OK to match Pending = DO NOT MATCH Closed = Maybe sometimes If multiple are matched (like the same VRN in Law and Main order, leading to the same Instance, but different holdings and items), stop if multiple matches. Or maybe use location as a submatch to get to the right holdings/item Christie: would be rare to want to match based on a closed PO, especially if it has cataloging implications and could result in accidental overlay of previous cataloging. Same for Jennifer E, Leeda, Dung-Lan A-M to talk with Devs on Friday - would it be more complexity to take status into account when matching? a little more, but infrastructure already there Maybe have 4 matching options POL with status = Open POL with status = Open or Closed VRN with status = Open VRN with status = Open or Closed | ||||||||||||||
| What about multiple copies? |
| It may be that we can only do 1 instance/holdings/item update until the multiples feature is developed | Right now, can only create single instance, holdings, item from an incoming MARC Bib. What happens if you're trying to updating multiple holdings or items from the same MARC Bib (if you have multiple holdings/items HRIDs) (find the feature for updating multiples from the same MARC Bib) Write a couple tests to see what happens when trying to update more than 1 item or holdings from the same MARC Bib
|
...
- Data Import job profile:
- Match POL to Instance UUID
- Single match: Update Instance (and Create/Update SRS MARC Bib)
- No match or Multiple match: STOP
- Match POL to Holdings UUID
- Single match: Update Holdings
- No match or Multiple match: STOP
- Match POL to Item UUID
- Single match: Update Item
- No match or Multiple match: STOP
- Match POL to Instance UUID
- mod-inventory hits mod-orders endpoint to find a POL's related Inventory UUIDs (only for Open, or possibly Open/Closed, not Pending POLs)
- If found, follow related Action and Field mapping profiles for SRS MARC Bib create/update and Inventory record updates
- Questions for SMEs:
- would the workflow sometimes be finding the instance and then creating (instead of updating) the holdings and item?
- Jenn C - for orders from previous system, creating items during receipt, but that's a time-bounded situation (migration)
- Similar for Dung-lan
- would the workflow sometimes be finding the instance and holdings and then creating (instead of updating) the item?
- would the workflow sometimes be finding the instance and then creating (instead of updating) the holdings and item?
- Questions for SMEs:
...