2021-05-27 Acquisitions Group Meeting Notes

Attendees

Ann Crowley

Dennis Bridges

Dung-Lan Chen

@ dfowler

Diane Cannon

Dung-Lan Chen

@Frances Dotson

Heather

Jackie Magagnosc

Jean M. Pajerek

Julie Stauffer

Joanna Cerro

John Ballestro

Julie R. Stauffer

Kimberly Pamplin

@Masayo Uchiyama 

Michael Phillips

Natalya Pikulik

@Okay Okechukwu 

Rachel Sneed

@Sashirley

Scott Perry

Scott Stangroom

Shannon Burke

@Shyama Agrawal

@Steven Selleck

Susan Martin

@Suzanne Mangrum

TRINH BETHARD


Discussion items

Minute taker

@Heather Thoele


Announcements/Updates


  • WolfCon is next week. 
  • We will not have our regular meetings next week.
  • Might be able to do UA testing next week.  Have not yet updated ability to reopen or unopen orders. So maybe later in the week can test. 

Results of poll


A summary of results is added on the wiki page. Everyone was voting on different poll positions. Dennis added a summary of results. Did not disregard any votes. Results are based on a cumulative summary of votes. 

Next steps: Dennis will create small front end stories to address the missing columns, and the order of columns. Will make a change to the po and pol search results list adding different data points. Caveat, has to be possible. Will revisit if causes performance issues. Will be included in R3 story. 

Discuss order renewal integration details and what data is most valuable to update.

Related to expense class. 

Video: 13 minutes after the hour

Apply expense classes to orders and invoices through API Integrations

At the moment no way for Gobi to send expense class information. 

Inside of Folio may have expense classes associated with fund. Have to add expense class information after the order is in Folio. Goal is to make integrations easy to give folio fund and expense class information. 

Possibility - Force external systems to have two fields, expense class and fund code?

Decision, have a joint fund code, expense class list. To allow you to share the information with the 3rd party system and reflects the relationship. 

The list communicates all the codes as well as give the relationship. If can give to 3rd party system, they can present as one list, or separate. It becomes the choice of the 3rd party system. 


There are a few implications if we take this approach. 

Main one - your fund codes and expense class codes will not be able to have whatever special character we are going to use in them. Right now those fields will accommodate special characters. With this, will have to exclude certain characters. Example, if we use a semicolon as the separator, the semicolon will be excluded from use.  Does anyone use special characters as part of their codes?

  • From John Ballestro to Everyone:  12:25 PM A&M uses a dash
  • From Diane Cannon to Everyone:  12:24 PM UA uses /
  • From Susan Martin to Everyone:  12:38 PM And MTSU uses a "dash"
  • Scott Perry: Wants to keep things clean.

Dennis: They did check with vendors to see what characters they could not accommodate.  Leaning towards colon right now. 

Scott: Can they be handled as separate data elements?

Dennis: Yes, the other system can.  Trying to make things flexible to allow for any possibility.  To make it easier to share, trying to create an export that shows the connections.  This is just a way to show the codes, and their relationships.

Dung-Lan Chen - Each fund may have every expense class. 

From Suzanne Mangrum to Everyone:  12:34 PM
Question: Have you sent this one list plan to the GOBI back-end people? Has there been a discussion about the specifics that FOLIO could send and the specifics about the information that GOBI could return to the library?

Dennis: Yes, at this point we have primarily talked about special characters and how they will display. Gobi does have special fields and can display fund and expense class in separate places. However, they may not have the logic in place to choose fund code then narrow down expense class selection. 

Dennis: If currently using a character that becomes invalid, there will be a program in place to substitute it when it's transferred. 

Dennis: Just starting to create story implementation. Would love to get into R2, but not sure. 

Other implication, in the settings area. At the moment can create expense class without a code or an external extension number. The code field will have to become required. 

Dennis: Are there use cases where you may have an expense class and want to associate that value with the fund in general? Would this be problematic for anyone to allow this?

Susan Martin: I don't see as problematic and I can't think of a use case. 

Dung-Lan Chen: Not a problem for them either. 

Dennis: This is not something anyone would actively want to do? Just have general transactions against the fund?

Suzanne: Concerned about sloppy record keeping and having to clean up later. 

Dennis: Maybe a way forward is to keep it restricted in the UA, but not in the API. 

Ann Crowley: If you give flexibility of not applying expense class, you also give the ability to just leave it off even when they know they are supposed to use it. 

Dung-Lan Chen: Can there be a warning if it is left off?

Dennis: If we remove it as a requirement, that can be done. Right now will be keeping this as a required field since it doesn't sound like there is a use case. 

Dennis: There are not any concerns with each expense class having a unique code? If there is not a code, the name will be used as the code. At any point in time after migration, the code can be updated. 



Discuss order renewal integration details and what data is most valuable to update.53 minutes

Dennis: Would like some feedback around renewal and what we have done so far. 

He has outlined some of the problems they are having. 

Initial version, to allow 3rd party systems to update orders. 

Gobi can create orders, but does not update the order. 

With renewals, that is updating the order. 

Dennis will post in Slack to get feedback. 

Are there certain things you consistently update that are missing from the list?