Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • U.S. daylight saving time started Sunday, March 12. Please check & adjust FOLIO meetings time on your calendar if applicable
  • Orchid bugfest runs thru March 17, please participate if you can
  • Next meeting - Tuesday, March 21, at 1 pm Eastern
  • Martina Schildt's presentation re: "Claiming levels requirements analysis" postponed until Tuesday, March 28
  • Appinteraction_crossapp group will meet on March 22 from noon - 1 pm Eastern to discuss printing in FOLIO.  The group is collecting printing use cases and requirements here
  • Seeking a volunteer to take notes for today's meeting
    • Julie Brannon volunteered to take notes, but missed some of the comments made during the PC update as she got this note/minutes page opened.  Please refer to the meeting recording for full details of that update.
  • New member introduction: John Banionis is joining this SIG representing Villanova University.
 :05PC updateKristin Martin
  • From 2023-03-16 meeting:
    • Revised FOLIO terminology being reviewed by councils, and will be added to wiki, docs if affirmatively approved.
    • Next Tri-Council meeting is on 4/13 - will look at Evaluation Process for New FOLIO Functionality. These are open meetings, so all are welcome
  • 2023-03-09: SIG updates - this link provides a good opportunity to see what's going on around the community.

Kristin described the FOLIO councils and let the group know about upcoming elections and that there will be a call soon for new members 

Dennis mentioned the idea of having a BugFest champion to increase engagement in BugFest. 

  • Kimberly had volunteered to serve in that role during the next BugFest.  This involves reposting notifications about BugFest for Acq SIG and keeping the group up to date.
  • Dennis asked Kristin if this concept should be brought to the PO Council.  Kristin agrees that this could be a role that other SIGs would find useful.  She's willing to bring this forward as a role where SIG members can get more involved without serving as a convener.
:16Implementers TopicsDennis

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

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.

  • Kristin Martin (University of Chicago; she/her) 9:49 AM
    Agree - it's really hard to pointpoint a PO in the transactions table.
    How did you put the spreadsheet together? LDP?
  • Kimberly Smith  to  Everyone 9:51 AM
    I agree that being able to download transactions with more detailed information at the fund level within the budget area would be awesome.  I would want expense class to be in the data or at least available.
  • Sara Colglazier (MHC/5C)  to  Everyone 9:51 AM
    I could really use this! with whether it is also received etc
  • Ann Crowley  to  Everyone 9:52 AM
    We are using LDP to capture this information, one for expenditures and one for allocations and allocation changes
  • Scott Perry (UChicago) 9:53 AM
    The LDP has derived tables that can help with this, avoiding the need to work with the JSON.

Dennis: It's a performance problem to add a lot of this data into the results list.  The order id and other info isn't stored in that module and requires a call to another module.  This is a recurring problem and is why we have the third pane view so that we only make the call when you click on a result.  We have a pattern for export, so if we can't show it in the result list we could provide an export to CSV that contains all the needed fields.  They'll create a feature for this and folks can add their thoughts to it.

And that is why then being able to get it out to look at and review/browse is that more important!
Scott Perry (UChicago)  to  Everyone 9:55 AM
I think it is true throughout the finance app that inclusion of more detail would be helpful (a list of funds, for example with balances so you don’t need to click through).
Dung-Lan Chen 9:56 AM
+1 to Scott 

Sara: Has a question about the description field - she doesn't know how to put data into that field?

  • Dennis: When you do an allocation or transfer the description field is available to populate. For orders or invoices we aren't pulling a description,so the field is blank for expenditure and encumbrance transactions.
  • Please add it to the Implementers Topics list that you want to be able to edit the description field on a transaction so we can have further discussion on this.

Next meeting is on Tuesday, March 21 and an agenda will hopefully be posted prior to the meeting, if possible.