2021-03-30 Acquisitions Group Meeting Notes

Owned by Heather McMillan
Last updated: Apr 05, 2021




Attendees

Aaron Neslin

Ann Crowley

Ann-Marie Breaux (Deactivated)

william.verner

Dung-Lan Chen

Dennis Bridges

diane.cannon

@Frances Dotson

Heather McMillan

Jackie Magagnosc

Jean Pajerek

Joanna Cerro

Julie R. Stauffer

Kimberly Pamplin

 @ Loyd Marmot

Martina Schildt

@Masayo Uchiyama

Michael Arthur

Michael Phillips

Natalya Pikulik

@Okay Okechukwu 

@sashirley

Scott Perry

Shannon Burke

@Shyama Agrawal

@Steven Selleck

susan.martin@mtsu.edu

@Suzanne Mangrum

Tracy Patton

tbethard



Discussion items

Minute taker@Heather Thoele

Announcements/Updates


susan.martin@mtsu.edu

 Ann-Marie Breaux (Deactivated)

Dennis Bridges

  • Susan:  Acquisitions will now be an open group. Please join new slack channel. Susan will be relying on the wiki a little more now.


  • Dennis: Bugfest: 

    • We currently have several unclaimed test cases in the Acquisitions area. There is an important one in Fiscal year rollover. Please look at the test cases and claim what you can.
    • If there are still unclaimed test cases, it’s worth cancelling Thursday’s meeting to give people time to test.
    • Anne-Marie has not put in EdiFact ones yet.
    • There are two weeks for testing this time, but please do not wait till the last minute.

EDIFACT demo from Friday - any comments or questions?  6 minutes after the hour

Ann-Marie Breaux (Deactivated)

Ann-Marie:

  • Are there any follow up questions? Do you want another demo that I can do when Dennis is out?
    • There are no questions from the group.
  • She did hear from Ebsco and they had some questions revolving around taxes and some of the more complicated adjustments.
  • Will be worked on in R2, if an import invoice line loads and does not match, it can not get the title and fund info from the line. Right now you need to delete what came in, then add the line manually. In Juniper, there will be the ability to  link/relink invoice lines to appropriate records.

Orders Results List: Apply Results list column.  UIOR-691 (17 minutes after the hour)

Dennis Bridges
  • In Orders, there are some new useful functions. Under Actions now can change the columns that display for search results. Is this valuable for workflows?
  • Dennis: This ability, to show or hide of columns, is one issue. Is this useful in other apps? Should this be a higher priority in other apps? To show or hide columns?
    • Scott: I love the concept. Is this preference stored at the user level?
      • Dennis: I think this is based on session. I think there are not yet user level preferences.
    • Tracy and Bill: Think Orders app should be a high priority.
  • Question: Can these lists be downloadable to Excel or .csv ? for further manipulation outside FOLIO?
    • From the orders app, you get the order and order line information. You can then export the list. (This is a test case is someone wants to claim this)
  • Dennis: It sounds like being able to hide (or show) columns is a useful function. Maybe start with orders, then finance and receiving as priorities.
  • Dennis: 2nd question: Can we take this opportunity to provide more in the search result list. (27 minutes after the hour)
    • There is a feature right now for search enhancements. We are working on improving the speed of searching and filtering. This might open opportunities on what we can display. Want to create a document to display current data points in orders and orders line, then rank what are the highest priority data points to see in a search result list.
    • Do we think it is worth reviewing these data points?
      • Yes – it is worth reviewing.
    • We need to implement search enhancements first, but after that should be able to add this.
    • Question: From Dung-Lan Chen to Everyone: 12:30 PM
      • When an user name/email entered in a PO line for notification, how would this information be connected to Circ. app, so Circ. can notify the user that the item is available for pickup?!
      • Ann-Marie: When acq places an order, if an item record is created at point of order, then the order staff can add a request to the item. Or they can tell a circ person to do it. When the item record status changes from On order (or In process) to Available, then the patron notice will be triggered
      • Bill Verner: Very important that this process be automated.
      • Ann-Marie: We've talked about it. Duke is also interested in it. To do that, we would need to store patron data in the POL, which we don't currently do. There is a requestor field, but it is not controlled. We probably would add a new (controlled) requestor field. Also concerns from Europe about patron privacy. So yes, it has definitely been talked about, but not resolved.
      • Scott Perru: There are concerns in the US about storing patron names long term as well which is what would happen if stored in the POL.
      • Suzanne Mangrum: We would also like a method to send alerts/email to requestors when ebooks are available.
      • Ann-Marie: Yes - we could perhaps only store the patron barcode or UUID, but that might still give you access (depending on permissions) to the complete user info
      • Scott Stangroom: perhaps you could do purges of user info in POL after certain period of time?
      • Martina: Having the choice to link to a user record or enter a name or number manually would be great.
      • Here's the Jira for automatically creating requests for newly ordered materials: https://folio-org.atlassian.net/browse/UXPROD-2565
    • Comment on what displays:
      • In order search results, the date listed is ‘last update’. Several people commented they would rather see the original order date, not the day the record was last updated.
      • Date ordered is the most useful information to see here.
      • Ann-Marie: One issue that is tricky is the difference between Order level data v order line level data. For libraries that have multi line orders, it gets complicated.

Discuss paying on fiscal year


Dennis Bridges

  • Now that we are able to roll over fiscal years and users can only pay for things within the current fiscal year. In the interface, you do not have the ability to choose what year to pay in.
  • When we pay an invoice, we create payments (or credits) against the funds.
  • It is possible to approve, then pay at some point later. It is possible that when you go to rollover from one fiscal year to the next, there may be approved invoices that have not been paid. Purpose: To later add the payment information.
  • If an invoice was approved in FY 21, and we lose track of it. Then in the next fiscal year, someone tries to click pay. Two possibilities:
    • Paid against the FY year it was approved in
    • Paid against new fiscal year.
  • In a previous discussion about this, we talked about creating the payment in the year the invoice was approved.  Is this in ine with expectations? That payments and credits are made against the FY in which the invoice was approved?
    •  At Duke, if we have a situation like this we would back the invoice out of the system.
    •  Several agreed with this.
  • Dennis: During FY Rollover, should there be a check for approved and not paid invoices?
    • Answer: Yes.
  •  Question: Are institutions separating the functions of ‘approve’ and ‘pay’?  Yes.

 Chat Questions/comments


12:32:02 From  Ann-Marie Breaux  to  Everyone : When acq places an order, if an item record is created at point of order, then the order staff can add a request to the item. Or they can tell a circ person to do it. When the item record status changes from On order (or In process) to Available, then the patron notice will be triggered
12:32:19 From  Dung-Lan Chen  to  Everyone : Okay, thanks, Ann-Marie!  Will this automated process be explored?
12:33:12 From  Bill Verner  to  Everyone : Very important that this process be automated.

12:34:13 From  Ann-Marie Breaux  to  Everyone : We've talked about it. Duke is also interested in it. To do that, we would need to store patron data in the POL, which we don't currently do. There is a requestor field, but it is not controlled. We probably would add a new (controlled) requestor field. Also concerns from Europe about patron privacy. So yes, it has definitely been talked about, but not resolved.
12:35:03 From  Scott Perry (he/him/his)  to  Everyone : There are concerns in the US about storing patron names long term as well which is what would happen if stored in the POL.
12:35:44 From  Suzanne Mangrum  to  Everyone : We would also like a method to send alerts/email to requestors when ebooks are available.
12:35:53 From  Ann-Marie Breaux  to  Everyone : Yes - we could perhaps only store the patron barcode or UUID, but that might still give you access (depending on permissions) to the complete user info
12:36:08 From  Susan.Martin@mtsu.edu  to  Everyone : +1 to Suzanne's ebook comment.
12:36:51 From  Scott Stangroom  to  Everyone : perhaps you could do purges of user info in POL after certain period of time?
12:37:08 From  Martina Schildt  to  Everyone : Having the choice to link to a user record or enter a name or number manually would be great.
12:37:50 From  Ann-Marie Breaux  to  Everyone : Suzanne/Susan - definitely would be a different process for materials without an item record, like eStuff.

12:42:07 From  Ann-Marie Breaux  to  Everyone : Here's the Jira for automatically creating requests for newly ordered materials: https://folio-org.atlassian.net/browse/UXPROD-2565
12:42:41 From  Ann-Marie Breaux  to  Everyone : I'll add an open question in the description for how to deal with requests for materials that do not have item records.
12:43:46 From  Susan.Martin@mtsu.edu  to  Everyone : Thank you, Ann-Marie!
12:44:23 From  Suzanne Mangrum  to  Everyone : Yes, thank you, Ann-Marie.
12:44:41 From  Dung-Lan Chen  to  Everyone : So from searching point of view, single line PO is better than having multiple lines in each PO? We are schedule to migrate end of May. Thanks in advance for your advice!
12:45:48 From  Bill Verner  to  Everyone : That is how Duke plans to do it for monographic orders.
12:46:05 From  Scott Perry (he/him/his)  to  Everyone : Chicago will be single line pos.
12:47:55 From  Ann-Marie Breaux  to  Everyone : And I've heard from some serials acq folks that single line POs are better for ongoing orders, since they can change over time, and it's easier not to have them lumped together with other ongoing orders that might not have changed.
12:49:06 From  Ann-Marie Breaux  to  Everyone : Voyager and Sirsi libraries seem to be the ones most familiar with multi-line POs. We wanted to allow for either single or multi-line POs. And libraries that only want to use single line POs can set that in the Order settings.
12:49:45 From  Lloyd (Marmot)  to  Everyone : Sierra can do a multi line PO.
12:38:03 From  Ann-Marie Breaux  to  Everyone : Give me a minute to track down Jiras

12:50:59 From  Ann-Marie Breaux  to  Everyone : Yes - and public libraries also seem a little more accustomed to multi-line POs, in my experience (and I've seen POs from many, many libraries over the years!)
12:53:28 From  Dung-Lan Chen  to  Everyone : Yes, our continuation orders are single line PO but firm orders are multiple lines currently.  My previous institution we were doing all single line for any PO.  I'm trying to figure what may be a better way to go in FOLIO. Thank you for your comment(s)!
12:54:15 From  Dung-Lan Chen  to  Everyone : How about removing the invoices before rolling over if they won't be paid before rollover?
12:54:59 From  Lloyd (Marmot)  to  Everyone : Question, does FOLIO give you the option of never rolling over the fiscal year?
12:55:03 From  Scott Perry (he/him/his)  to  Everyone : That’s one option. We also leave already created invoices that haven’t been approved in the system.
12:56:45 From  Ann-Marie Breaux  to  Everyone : The other use case I've heard for multi-line POs are the ones created at point of receipt for approval plan purchases or DDA/PDA purchases. What you set as your POL limit in settings would govern these scenarios too
12:57:19 From  Ann-Marie Breaux  to  Everyone : Never rolling over, or unapproved invoices - have to ask Dennis about those
12:57:58 From  Lloyd (Marmot)  to  Everyone : Sierra has three options

12:58:29 From  Dung-Lan Chen  to  Everyone : Is overlapping fiscal years allowed in FOLIO?  So one can fix stuff in previous FY while start working in new FY?

13:00:20 From  Lloyd (Marmot)  to  Everyone : Sierra has three options 1. never rollover, you have one never ending fiscal year 2. old fiscal years continue to exist on the system and you can still invoice against them 3. old fiscal years are frozen and can never be acted on We have libraries using each of those methods.

13:02:16 From  Ann-Marie Breaux  to  Everyone : Right now we are only supporting option 3. We would have to think through the other two options, if they are definitely needed
13:04:04 From  Martina Schildt  to  Everyone : Yeah! +1
13:04:10 From  Lloyd (Marmot)  to  Everyone : Option 3 is used by the academics.  Publics use the other two.
13:04:30 From  Scott Stangroom  to  Everyone : yes





Action items

  •