2023-03-17 Acquisitions Meeting notes

Starting with Topic #81 ( André Hohmann) and then #83 and continue

André Hohman (Dresden):  We want the ability to deprecate values in Settings that are no longer active across FOLIO.  Martina Schildt mentioned that this functionality already exists in the Licenses app.  For PO number Prefix, they use the year as a prefix and they want to deprecate prior years so colleagues won't accidentally apply those prior years.  They don't want to delete these values since they are in use.  Similarly, Acquisition Units.

Owen Stephens 9:19 AM
We support deprecation for license terms and agreement supplementary properties (I think since Morning Glory) although this is something we’ve had to implement specifically for those properties - it isn’t a general method that can just be used. Note that this is for a property (like a custom field) rather than for a value that a property can take. Deprecated reference data values is something that makes sense to me though.

From Joe Reimers in chat: Is there still a need to be able to search on those? Disable for new, keep available for searching

• From Owen in chat: For the deprecation we’ve done in Agreements & Licenses we’ve assumed that you might want to search on them, but we mark them as deprecated

Dennis: We don't allow deleting them to avoid data correction.  It makes perfect sense that you might want to stop using a value.

Owen: In licenses the deprecation is at the term level which is more like deprecating a field. If you were to create or edit a license after deprecation, the term will no longer appear in the drop-down list. If you've already assigned a term, it would be labeled as "DEPRECATED" in the UI.  In Search it will also show it as deprecated, so you can search by and view the values, but they are clearly indicated as deprecated.

Owen asked whether the prefix changes every year? Yes - André reported.  For migrated data they don't want to show the prefix from prior years.  

Dennis asked why they apply the year as a prefix. André thinks Sven from Leipzig might know.  The accession numbers are also structured this way.  Sven thinks it's to get a grip of when the order was placed - it's a very usual thing for them to use the year as a prefix for data values.  Dung-Lan reports that Skidmore also uses a prefix controlled vocabulary.

Dennis asked whether a user would ever use a prior year's value.  At any given time, the only non-deprecated value is the current year.  André confirmed that this is the case.  Dennis explained that identifying a default value would make sense so the user doesn't have to choose a value from the list.  André will take that suggestion to colleagues at Leipzig.

Owen Stephens 9:33 AM
From experience I definitely would support cleaning up as far as you can before you migrate the data… I once had to do a system migration where in the past a librarian had decided to classify all missing books into “sheep” and “goats” (a biblical reference https://www.bbc.co.uk/bitesize/guides/zgqjgdm/revision/5)

Dennis asked whether having a default value would be helpful for others? In chat:

• Dung-Lan Chen 9:39 AM
  Set up templates to have the prefix designated in the orders however you'd like
• Sara Colglazier (MHC/5C) 9:40 AM
  As long as a default is not mandatory

 Owen Stephens 9:37 AM
Acquisition Methods would seem more similar to our scenario with License Terms - you might change the list occasionally but it seems like it would be much rarer case

Dennis:  If other institutions can share use cases when a default would be helpful, that would help this feature. Dennis will create a story after Andre as a chance to consult with Leipzig and get back to him

Topic #83 John Banionis (Villanova)

Villanova implemented FOLIO at winter break, looking for a way to extract the list of transactions from FOLIO.  They've created their own solution using LDLite and DBeaver to get what they need, but it seems like having this native in FOLIO would be useful for others.

John shared his screen and suggested that providing more information on the transaction list at the top level would help.  The user has to click into the transaction row to see full details. The description would be helpful to see, for example.  

Current view of transaction list:

They exported the data and enhanced it to include the following columns 

• Transaction date
• Fund code
• Type
• Amount
• From
• To
• Source
• PO/Inv. Line no.
• Description/title
• Received title 

Dennis: Does this spreadsheet list this for all funds? How did you create this spreadsheet?  

• John: No - this is for one fund.  Our library tech team used DBeaver which looks at LDLite (updated nightly with data from FOLIO)

Dennis: What are the use cases for why you needed this?

• John: It's helpful for selectors to see at a glance what has hit their budget and to see the details without wanting to click all over to get that information.  This is for our internal budget owners to view this at the fund/budget level.

Kimberly Smith - if something was fund coded to the wrong fund accidentally it would be very easy to find it if this were available.