Versions Compared

Key

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

Date

Attendees (38)

Agenda

  • PC Update - Kristin Martin 
  • Continue UAT Receiving results
  • Display acq information on instance
  • Discuss adding a field or indicator to identify Consortium purchases separate from Organization/Vendor
  • Discuss adding Acquisitions Method for category "free"

Discussion items

TimeItemWhoNotes
PC UpdateKristin

Product Council Updates

https://

wiki

folio-org.

folio

atlassian.

org

net/wiki/display/PC/2021-09-30+Product+Council+Meeting+notes

LDP app in kiwi release, asked TC to create guidance to make sure it met tech standards. They are working on it, and we anticipate it making it into Kiwi. 

 https://

wiki

folio-org.

folio

atlassian.

org

net/wiki/display/PC/2021-09-23+Product+Council+Meeting+Notes

9/23 updates: Can see what has been going on the various groups.

Yesterday talked about Juniper upgrade slowness.  More of an awareness raising.

Trying to do a review of all apps maintenance. There is a page for that.   https://

wiki

folio-org.

folio

atlassian.

org

net/wiki/display/REL/Team+vs+module+responsibility+matrix


Continue UAT Receiving results

 Dennis

https://docs.google.com/presentation/d/14UfA9n2hkDMTg1ndAo1_0dT1JQengNheli44yQD6FPc/edit#slide=id.gb5bc2518aa_0_4

UAT Receiving results

Last time talked about having a wizard that gave guidance on the critical parts of creating the order.  Parts that make a big difference in how the order acts. 

Dennis would like to understand more about the training issues about training, have you focused on this in training, or are you relying on templates?

From Jean Pajerek (Cornell Law Library) to Everyone 08:12 AM
"Manually add pieces for receiving" was something I stressed over and over when conducting training at Cornell.

Dennis: Have they applied it correctly?

  • I don't know. Most of them work in the main library.
    I work in the Law library.

Dennis: How did people train on this? 

Jean: What I told people is, If you are ordering on ongoing thing, like serials, you needed to check the box for manually add pieces. 

Kristin: For ebooks, you are creating a piece record and receiving that?

Jean: Yes, we think of it more as verifying the piece. We do not have item records. We just have the holdings. There is just an instance and a holdings. 

From Lisa Maybury to Everyone 08:17 AM
The main library at Cornell will most likely not use the function "receipt not required"

From Virginia Martin to Everyone 08:17 AM Duke plans to use it. what are y'all doing for e-resources that aren't ebooks?


From Ann-Marie Breaux to Everyone 08:18 AM It's my understanding that some libraries are making item records because Course Reserves required item records - so maybe pieces would make sense in that case?


From Virginia Martin to Everyone 08:18 AM right... so you will have to use "receipt not required," right?
just not for ebooks?

Dennis: Kristin, you will use receipt not required and verify it later?

Kristin, we don't actually verify that it works. We get a link, set it up, and trust that it works. We have a holdings record. 

From Sara Colglazier (MHC/5C) to Everyone 08:18 AM What about the E-Resource Details Section for recording confirmation of access


From Virginia Martin to Everyone 08:19 AM we verify access of firm and approval ebooks but not every single title in a package or database


From Sara Colglazier (MHC/5C) to Everyone 08:19 AM Activation Status check, Activation due date or Expected activation date?

Dennis: Sounds like a few libraries are relying on the auto resolve?

Susan Martin: It is for us.  We had not been receiving ebooks. Right now, we have an instance and a holdings, no item record. But they were not closing out upon payment. They had not checked receipt not required. 

Ann-Marie: Payment and receiving need to reach an end state, or not be required, This is important to emphasize in training.

From Kristin Martin to Everyone 08:23 AM This will be a new wrinkle in our workflows as well.

Virginia: I don't want to rely on templates for poor user design. 

Ann-Marie: Do you think payment not required is poor design?

Virginia: The way there are a lot of fields that are essential, but are not required, but are important to the order.  How fields are organized, labeled, I think there are ways to improve on that. 

Ann-Marie: If you don't make a selection, it defaults to receive and pay. Maybe we should assume and force people to pick one.  Without a defulat, people have to make a decision. 

Dung-Lan: I didn't think about receiving electronic resources. I am surprised to hear Susan say that for ebooks the status is not complete after paying. 

From Susan.Martin@mtsu.edu to Everyone 08:27 AM Dung-Lan that was our assumption as well. We were surprised to find out otherwise.

Dennis: The importance of that detail is not clear. 

Lloyd: I would want to set my default template. 

From Ann-Marie Breaux to Everyone 08:28 AM I wonder if we could have a setting for those Receive/Pay checkboxes that allows setting different defaults for P, E, Mixed, Other - similar to the Inventory defaults. 

Lloyd, it would be optimal if I could set it by logon. 

Ann-Marie: We don't have that level yet. In the interim , would it be better to hace a setting or not?

Yes. 
From Julie Brannon (she/her) to Everyone 08:29 AM Yes - controlling the default behavior in settings would be a big improvement

Ann-Marie: In my mind, it would work like inventory interaction. You get a drop down list of options. 

Dennis: So if you had a p/e mix, you want to be able to receive the print, and not the electronic. 

Kristin: I agree with Ann-Marie. We made some workflow assumptions early on. Being able to control some of those things make it more transparent, to understand what they do.  When we talked about this early on, we said we don't want th po to close if we don't receive it. 


From Julie Brannon (she/her) to Everyone 08:29 AM Yes - controlling the default behavior in settings would be a big improvement


From Ann-Marie Breaux to Everyone 08:32 AM And to be clear (like Inventory Interactions setting) - have a default in Settings, but being able to override for individual POLs

From Julie Brannon (she/her) to Everyone 08:32 AM
We'd want set the defaults for Receipt Status based on order type - one-time vs. ongoing.


Ann-Marie: Its my experience there are fewer ongoing orders closing versus one time. If we base it on format, then we have a grid that we have to make instead of a single decision. 


From Virginia Martin to Everyone 08:33 AM Duke is in the same boat - we won't ever receive electronic materials


From Dung-Lan Chen to Everyone 08:34 AM Agree with Susan - not wanting to receive electronic.


Dennis: It is clear we have to make a few changes to the way this will function.  Sounds like we need more detail if we want to control for all the possible formats in the order.  We don't capture enough detail right now. 

From Dung-Lan Chen to Everyone: Is there a recommendation what we should do in the meantime to complete individual eBook orders once they are invoiced and paid when receiving not required was not checked?
 Dennis: When we talk about the auto resolve when you have an order that doesn't have manually add checked, when you receive the last piece, the system will change the po line status to fully received. On the invoice side, when you process, and pay an invoice that relates to the pol, it will close and complete the order.  
 

From Susan.Martin@mtsu.edu to Everyone 08:38 AM Make sure those POLs are "receipt not required"

Dennis: So how should this be done in the meantime if you want the order to resolve and you don't need pieces, then you mark it as receipt not required.  Then all you need to do is process the invoice. 

From Ann-Marie Breaux to Everyone 08:42 AM
That's a good way to describe it - making sure that the idea of "Resolution status" for Receiving is clear and document. The "Receipt not received" or "Fully received" being resolution statuses that allow the order to automatically close (in conjunction with the payment status)

From Scott Perry (he/him) to Everyone 08:43 AM How does this impact FYRO where you have paid pols that are receipt required?

  • From Ann-Marie Breaux to Everyone 08:43 AM
    I *think* it should not impact FYRO since it doesn't involve money, but Dennis should confirm
  • Dennis: That is correct.  Rollover depends on if you have encumbered or not. Receipt doesn't factor in. 

Dennis: Getting back to receiving feedback: it is clear that users were a little confused by package pol's. Mostly because it's a different workflow. You have to go to receiving and create the the title. We have not implemented any sort of guide for helping users thought that process.  These are po's that have the package box checked. They do not relate to an instance ever. You have to create the title in receiving to to relate this pol to multiple instances.  

Dennis: When you create a pol, how do you receive it? Is that what the sticking point is?


From Heather McMillan to Everyone 08:48 AM How packages work confuse me in general.
From Susan.Martin@mtsu.edu to Everyone 08:48 AM Me three.
From Jean Pajerek (Cornell Law Library) to Everyone 08:48 AM I am also confused by how packages work.
From Dung-Lan Chen to Everyone 08:48 AM Same here.

From Heather McMillan to Everyone : HOW you would use them
From Martina Karlsson to Everyone 08:49 AM Never understood the how or the why of packages...
From Dung-Lan Chen to Everyone 08:50 AM Also no documentation about pkg I could find?!
From Jean Pajerek (Cornell Law Library) to Everyone 08:50 AM +1 Dung-Lan

Sara Colglazier: When playing with packages before, I would want to sue it, but I would want my title listed separately. Plus, then that changed the quantity of things on order, because now my package was also 1. 

From Ann-Marie Breaux to Everyone 08:50 AM In monograph land, the biggest usage that I could see is monographic standing orders, where the individual pieces will end up on different Instances in Inventory


From Virginia Martin to Everyone 08:51 AM they will end up on different instances if analyzed, on the same instance if not
but it feels weird to use a "package" for that scenario since its not a package (containers!)

From Susan.Martin@mtsu.edu to Everyone 08:52 AM Ah, Containers.
From Virginia Martin to Everyone 08:52 AM I can't quit you, containers.

From Susan.Martin@mtsu.edu to Everyone 08:52 AM +1


From Julie Brannon (she/her) to Everyone 08:52 AM
About documentation: The documentation for the receiving app mentions packages briefly.  See https://docs.folio.org/docs/acquisitions/receiving/ "Creating a receiving title"

From Virginia Martin to Everyone 08:52 AM Thanks for all of your documentation efforts, Julie!

From Ann-Marie Breaux to Everyone 08:53 AM Right - that's why I said monographic SOs. On the other hand, if you're paying for a fixed group of 500 eBooks, then maybe you don't have individual titles/records/agreement lines for each one - but still maybe(?) use a package order.  As far as I can tell, the main decision point for packages is whether you need to receive and track multiple individual (ongoing or one-time) titles.

From Virginia Martin to Everyone 08:54 AM Okay, apologies for misunderstanding.
From Dung-Lan Chen to Everyone 08:54 AM Yes to Ann-Marie.

Dennis: Where most people got lost was I created my package pol, opened order, I need to receive things. In this workflow, you now need to add the titles. you relate the title and pol  in this area.  These bits of detail can be linked to agreement lines. WE should talk a little more about how this package can be a more useful part of the workflow. 

From Sara Colglazier (MHC/5C) to Everyone 08:57 AM But then what about Titles that are not in Inventory but only in Agreements (AGLs) By Titles, I mean Receiving Titles






Receiving Documentation https://docs.folio.org/docs/acquisitions/receiving/

Closed Captioning Transcript


View file
nameclosed_caption 20211001.txt
height150