2024-05-10 Acquisitions Meeting notes


May 10, 2024



Aaron Neslin

Kathleen Norton

Okay Okonkwo

Alissa Hafele

Kimberly Pamplin

Owen Stephens

Ann Crowley

Kimberly Smith

Sara Colglazier

Catherine Tuohy

Kimberly Wiljanen

Sarah Kees

Daniel Welch

Kristin Martin

Scott Perry

Dennis Bridges

Linh Chang

Susanne Gill

Dung-Lan Chen

Lisa Maybury

Susie Skowronek

Dwayne Swigert

Lisa Smith

Sven Thomsen

Heather McMillan

Lucas Moder

Sylvia Hamann

Heiko Schorde


Timothy Nelson

Jean Pajerek

Masayo Uchiyama

Victoria Anderson

Joe Reimers

Nancy Pelis


John Banionis

Nina Stellmann




 Discussion topics












  • Housekeeping -

    • Reminder - vote for acq-sig-topics (more info see agenda of Jan. 16 under Housekeeping if you haven't done it before)

    • Take a look at "Inventory, Item record. Make item material type optional" before next Acq SIG meeting (May 14) if possible as it'll be on the agenda for next Tuesday

    • Planning for FYRO discussions - feedback

    • Next scheduled meeting, Tuesday, May 14, at 1 pm Eastern


  • Is anyone having random problems in Acq that are hard to diagnose

    • Scott. have had similar experiences, most are fixed by the refactoring happening in Q

    • Variety of things, usually stem from po’s that are closed, then reopening, then closing them. Always edge cases. so finding them deliberately can be challenging.

    • Kristin: Made a decision to never unopen an order. When we try to edit a po and get a note that it’s a protected field, they seem to be tied to the identifier in some way.

    • Dennis: Need to start a wiki page to collect these unique issues. Product ID, and transaction problems have been fixed

    • Kristin talked about how past decisions on their workflow can get affected and cause problems in new releases. Mention strict validation rules.

    • Sara Colglazier 8:08 AM
      The problem is that *fix* is not quite the right word, it is more like patched. And there is residual fallout that then there is no way over time to keep track of and understand

      Sara Colglazier 8:15 AM
      Absolutely, about invalid ISBNs!

    • Lisa Smith, Mich State 8:18 AM
      Mich State runs into the invalid prod ID issue regularly

  • Sara: How over to account for discrepancies that get fixed by hosting, and it causes problems on what they see.

  • Dennis: One of the developers, Damien, gave a presentation on API transactions changes. It’s worth watching to understand how everything is working in the background.

  • Kimberly Wiljanen 8:20 AM
    if there is no qualifier, but a vendor 

  • Sara Colglazier  to  Everyone 8:22 AM
    Thank you! That would be helpful to watch.

  • Lisa Smith, Mich State  to  Everyone 8:22 AM
    I hear you, Sara.  We worked really hard creating so many groups, and I don't trust them yet.  We spend a lot of time recalculating funds.  I'm really hoping to get into Quesnelia before too much damage is done in Poppy...

  • Dung-Lan - Place to record problems and document odd things you see

    • Dung-Lan Chen 8:26 AM

    • Dennis Bridges 8:30 AM
      Thanks so much all I need to drop. 

    • Joe Reimers (EBSCO)  to  Everyone 8:30 AM
      I need to drop for another meeting

    • Scott Perry (UChicago)  to  Everyone 8:33 AM
      The invalid identifiers sometimes causes approval of an invoice to fail.  Our hosting provider repairs it so we can pay.
      Invalid isbn for example

    • Sara Colglazier  to  Everyone 8:34 AM
      We have a workaround thing we do re: invalid identifiers.

    • Owen Stephens 8:34 AM
      It looks to me like the code handles some isbn edge cases but not others

    • Sara: Since she catalogs she turns 035’s into 036’s…. she went through her process….

    • Owen Stephens 8:36 AM
      There’s some code that looks like it has a way of identifying invalid ISBNs and putting them on the order line as an invalid ISBN product ID type. So possibly the solution here isn’t relaxing the validation but rather making sure that the “invalid ISBN” cases caught are much more comprehensive

    • Kristin Martin 8:37 AM
      And if they are coming from MARC, you do need to edit them.

    • Kimberly Wiljanen 8:37 AM
      Including OCLC numbers

    • Lisa Smith, Mich State 8:38 AM
      Mich State unopens the order, and removes the troublemakers from the POL and reopens the PO.  We sometimes copy/paste info into the receiving field if we want a record of it.

    • Kimberly Wiljanen 8:39 AM
      There's plenty of spaces in between the $a and the $c

    • Sara Colglazier 8:39 AM
      010, 022, 020 + $q, 024, 028, 035, 998 [for us at least] … possibly others that I a forgetting

    • Kristin Martin 8:40 AM
      What is the use case for orders to validate ISBNs?

    • Sara Colglazier 8:41 AM
      I may prefer the 024 or 028 and there may not be a 020 at all

    • Owen Stephens 8:42 AM
      It looks like the validation used is the same (there is a common set of utilities to validate ISBNs. But possibly the way you get to a validatable ISBN (e.g. removing qualifiers) is different which sounds like it might be causing the problem here. But I’m guessing a bit based on reading the code right now

    • Kristin had added this as implementer's topic #143

  • implementer's topic #143

  • ISBN validation and order creation errors

  • In the orders app, there is fairly strict ISBN validation. Vendors, when supplying preliminary order data (or even full cataloging) often don't meet the validation standards. This has become a problem for us in particular with multiple records rejected when loading a file of orders because the ISBNs don't meet validation. Some examples:

    • Qualifiers placed in the 020 $a like (ebooks)

    • Multiple ISBNs all placed in the same 020 $a

    • Truly invalid ISBNs where the check digit is wrong

    We'd rather get these records loaded, with the incorrectly formatted or invalid ISBNs - that's the data the vendor provided. Instead, we have to create routines to clean up the ISBNs or remove them altogether. Is there a reason for why ISBN validation is so strict in Orders? Inventory doesn't seem to care. Can we relax ISBN validation rules so that these types of issues can be accepted?

  • Sara: I believe Inventory is not having validation, but orders is.

  • Owen Stephens 8:42 AM
    It looks like the validation used is the same (there is a common set of utilities to validate ISBNs. But possibly the way you get to a validatable ISBN (e.g. removing qualifiers) is different which sounds like it might be causing the problem here. But I’m guessing a bit based on reading the code right now

  • Susanne Gill (BVB) 8:47 AM
    It's easier for the Vendor to get the correct order with the correct isbn. i mean the correct book

  • Sara Colglazier 8:49 AM
    Susanne, it would depend on what direction you are working. If you are pushing orders from your system to the vendor, absolutely, but if it is ...

  • Susanne Gill (BVB) 8:49 AM
    In Bavaria that is the way :-)

  • Sara Colglazier 8:50 AM
    We do not

  • Kristin Martin 8:50 AM
    At Chicago, generally, we are using vendor order databases so the orders are placed. We haven't got a workflow to push orders out of FOLIO.

  • Susanne Gill (BVB) 8:51 AM
    We have a lot small local Vendors
    and I'm for the ISBN validation

  • Kimberly Wiljanen 8:51 AM
    Some of the vendor databases receive early information from publishers and the ISBN may be incorrect at that point

  • Aaron: Looking at the possibility to be able to disable validation in orders

  • Sara Colglazier 8:52 AM
    That would work for me.

  • Aaron There is a split between North American library workflow and some of the European ones. The order of things are done and the value of the ISBN in the order. So it sounds like if the ISBN validation could be disabled on a tenant by tenant basis that would work for everyone without disrupting anything.

 Action items