Page Comparison

PC Updates

• Minutes
• Implementation timelines
• Interest in ERM

Discuss posts of Interest:

• ISBNs

• FOLIO release "aster" is coming out in 01/2019. PC discusses implementation plans for FOLIO.
• Go live is pushed from 2019 to summer 2020 by Chicago, Cornell, Texas, ... but ERM could work as partial implementation.
• German libraries: Leipzig, Dresden, Freiberg, Bremen, ZBW, Lüneburg do plan to go llive with ERM as soon as possible
• Stakeholders meeting on Tuesday next week for more information
• ERM: clarification about requirements - work by Ian and Khalilah to be put in Jira
• How to push development forward in the working groups? Martina, Martina, Kristin will work on that
• ERM: new development: outcome of the Sheffield meeting are planned to be shared
• Ian: more work and detailed requirements will be put into JIRA to have a better overview and full understanding
• Ann-Marie: will give us an overview about the ISBN discussion next week - please view and participate in the discuss post in the left column

• http://folio-snapshot.aws.indexdata.com/
• Vendor app:
  
  • contact information with multiple contact people
  • manage contact information in the vendor record
  • Do we need a contact module?
  • Bug fixes are in focus of developement  recently but analysis looks at the enhancement regarding "contact app"
  • wiki: "vendor module entities"
  • enhance managment of contact details, like emails, phone numbers
  • Vendors = organizations (content provider, platform or access provider): can we match the entries from ERM orgs and vendors?
  • Vendors will have this requirement regarding organizations to be used in other apps like ERM / eHoldings - shift for the module
  • vendor organizations with different rolesVendor organizations with different roles
  • Option: a vendor is not necessarily an institution sending invoices (paying / non-paying vendors) - needs to be indentified by a key (checkbox)
  • Validation check of vendor names before loading data
  • Reporting needs: show me open orders of exactly THIS vendor
  • Authority control for vendors?
  • But: vendor file shouldn't be the area for contact management - vendor will remain as is (no merging)
  • Contact app as second option
  • Contacts: information is technically not merely stored but referenced to
  • Store all contact data in one place with option to control the data (authority control / normalization) and assign  the data in the apps (like vendors in acq) where they are needed in th role that is assigned to the type of contact = reference to contacts apps from different other apps
• Orders:
  • What will be able to delete in an open order?
  • bugfixes, developement goes on
  • PO number: prefixes, suffixes:
    • systems offers an ascending number by default that can be editied by adding a prefix or suffix or a total own number
    • POL will inherit this PO number added by '1 / '2 and so on
    • PO number is a whole string after saving (incl. pre- / suffix)
• Receiving:
  • creation of backend stories is nearly finished
  • Development in focus
• Invoicing:
  • Review mockup for invoicing next week in small group
  • Next step: backend stories
• Finances:
  • Enhancements from UAT need to be implemented
  • Not in focus recently
  • Open for Q2 - partly ???
  • After Chalmers (not necessary for them)
  • No recommendation to do beta testing in libraries at the moment - just general checks (Chicago is interested)
• Subscriptions:
  • defiend as ongoing orders with checkin instead of receiving
  • be part of orders
  • renewals information is available
  • no extra module
  • standing orders with no defined intervall? Workflow for finances management? Publication pattern?) Have a review next week (Ann-Marie)
• Comment Virgina: have a use case test on the full ACQ system when it is more mature to see if it works in whole.
• There are already use cases defined - shall we use them for that approach?
• Ann-Marie:
  • Data import: work with Filip for matching details: what the vendors delivers against FOLIO files
  • Matching in action! But no prototyp yet
  • MM SIG: refining bibliographic MARC mapping
  • for inventory / holdings records
  • Developer:
    
    • Current sprint was 3 weeks long / holidays
    • last sprint of aster
    • clean up of data loader / import (EPAM team)
    • file extention settings and control over
    • jobs, match, action profiles will be built in Q1
    • MARC bibliogaphic profile in Q2
    • ISBN issues in discuss post (Q1)
    • Marc bibliographic records are now stored in inventory → move them to the new source record storage for multiple use: starts next week in a working group
  • Source record storage will become "source of truth"
  • This weeks forum will take place later and announced
  • Codex in MM SIG yesterday - shall we have that in ERM subgroup too?
    • has huge impact on ERM and ACQ!
    • ERM is involved in Codex? 
    • What is the goal of the codex presentation?
      • Feedback of TC?
      • Codex a solution in search of a problem?
      • Codex should be discussed in RM SIG, too, because it covers a lot of functionalities
      • from chat: Von Ann-Marie Breaux an alle:  04:02 PM

        I have to leave, but I agree - I would want a presentation here in RM SIG, but not until we know that this is a path that we'll actually be taking  - so after Tech Council"

      • Ian: We should do this after the TC's feedback

Chat:

Von Ian Ibbotson an alle:  03:01 PM

Thanks dennis - is that included in the search by name?

- it's more about that function than the data I think - maybe I just didn't normalise the name or something?

Von Ann-Marie Breaux an alle:  03:04 PM

Hi Ian: aliases are included in the seach by "all" and search by "alias" but not (currently) search by "name". For a good example, try searching by ybp, which is an alias for GOBI Library Solutions

Von Ian Ibbotson an alle:  03:07 PM

Ok - we can definitely try the name search first and if that fails to match, an alias search second - do you think that would work?

actually that might be better for us as we then know we have a non-preferred term if we match on an alias