Highlights of the PC meeting are contained in the minutes.
Please consider submitting a proposal to the Technical Services IG
Question regarding starting Orders from Inventory - will return for a future discussion follow up with Dennis Bridges and Martina Schildt and Charlotte Whitt from App Interaction Discussion
Owen: I’d be really keen this isn’t just solved for Inventory + Orders - as there is also the Agreements Orders link and other scenarios where you want similar behaviour
We did have a discussion around app interaction about this concept of being able to create things “mid-process” where you needed to bridge from one app to another
Working on EBSCO Usage Consolidation on integration via the eHoldings App.
View usage and cost information for a given year
Information contained within a summary table - cost and usage will be coming back from EBSCO Usage Consolidation (currently all data is external)
gathers info from the invoice app (and fund codes)
Package Cost
Total Cost
Cost-per-use at the package level
What is the best way to get the connection between the invoice and the package, etc IDs?
Agreement line stores the EBSCO kB IDs (that is how the cost info is tied back into what is seen here)
the EBSCO scenario might be simpler because the consolidated usage and the journal ID is already made
Usage consolidation (source of the cost in EBSCO, or from FOLIO)
Question about usage - going through FOLIO to EBSCO and back (or will it be duel entry)
Today, this info is manually loaded into the EBSCO usage consolidation service
May need to be duplicated entry until phase 2 development
Owen S from the chat ("The other aspect is the UI aspects in Agreements - I think Leipzig’s vision is to have the data that you have on-screen here (or similar data) displayed in the Agreements app - I think we’d want to try to have a unified approach in Agreements to this, no matter where the CPU data is coming from")
Comment from Annika (Yes, Owen, we should definitely try to make the Agreements integration open for re-use by Khalilahs approach in Phase 2.)
From Aaron in the chat (we may have circumstances where cost per use data cannot be shared between libraries in the consortium, so if it is on the agreements app we would need teams like function )
The connection needs to be there via the PO line
title in package info
This will show cost per use (% of budget, etc)
Each institution chooses what type of usage they want to see (info button examples)
Phase II will get information from Acquisitions to display information at the title-level
Title level cost at the titles table
EBSCO considers usage tied to the title, not by the package (the connection to the package is not made by EBSCO)
Comment from Owen S in chat (That’s also the assumption we make in the Agreements internal KB - the platform is tied to a version of the title, not the package )
Sara asking about really wanting to know for usage by each title subscription
Some changes in EBSCO usage may come to better connect title specific usage
chat text saved here (lots of questions and comments came up):
platform subscription, cost, cost per use (Sara wants this connection, but it does not exist)
But, the manual connection can be made
Comment from Owen S in chat (For the Agreements internal KB, the resource that the Agreement covering is what we call the “PCI” - which is a Title on a Platform in a Package )
from Owen S. (I definitely understand that when you calculate CPU you want to be doing that on the basis of the cost of particular usage, not your total title cost across your total title usage )
Discussion over the ongoing need to clarify what is prioritized
EBSCO is doing this work for the eHoldings app
phase 1 is finished (are thinking about phase 2)
Own S in chat (But I would also stress that we can make decisions about what is displayed to whom - so I don’t think it is necessary that everyone sees this data even if it is available to some staff as appropriate - and that should be a tenant level decision )
eUsage is complex (so more surely awaits in this area)
We don't want to promise too much as this develops
