2021-07-06 Acquisitions Group Meeting Notes

Attendees

Alice Daugherty

Amelia Sutton

Ann Crowley

Ann-Marie Breaux (Deactivated)

Dennis Bridges

Dwayne Swigert

Janet Ewing

Jean Pajerek

Julie Brannon (old account)

Julie R. Stauffer

Kathleen Norton

Kimberly Pamplin

Kristin Martin

Lindsey Lowry

Lisa Maybury

Lloyd Chittenden

Martina Schildt

@Masayo Uchiyama

Michael Phillips

Nancy Pelis

Natalya Pikulik

@Okay Okonkwo

Peter Sbrzesny

Sabrina Bayer

Sara Colglazier

Shannon Burke

Shyama Agrawal

@Steven Selleck

susan.martin@mtsu.edu

Suzette Caneda

Tatjana Clemens

Tracy Patton

tbethard

Virginia Martin

william.verner

Discussion items

Minute taker

@Kimberly Pamplin


Agenda


  • Discuss EDIFACT order export. This refers to UXPROD-531 - Export FOLIO orders in EDIFACT format DRAFT  which has been identified as a very high priority in the community pointing exercises. We will review a proposed workflow for EDIFACT orders based on previous discussion and revisit use cases to be sure nothing has been missed
  • Discuss adding a status of “Claimed” to the POL
  • Discuss updating unit price for renewals
  • Discuss usability of Allocation “To” and “From”
  • Review show Piece on Holdings mock up


  

Susan Martin

Reminder that there is no meeting on Thursday, but will meet this Friday 7/9 with agenda to be determined.

Friday's link will be https://zoom.us/j/675766727




Dennis Bridges

Discuss updating unit price for renewals @ 12:05 


Presumably with something you don’t want to encumber, you would indicate that the price is zero in the POL.

When it comes to a possible renewal integration and the update of order information, the thinking is that you would not want to have a $0 price updated even if there is updated price information available.

Can you think of a use case where you use $0, but at some point would want to actually capture a specific price?

  • Sara Colglazier: Sometimes don’t know what the price is going to be at the time of entering. Very often use something general like $50 even as a placeholder price. Vendors might load with $1 if they do not know the price. Will that be overwritten and updated?
  • Dennis: Not concerned if there is a price of some kind. Assumption is that you would want the accurate price if it is available. 

Only use case given originally for $0 amount was that you do not want an encumbrance. Can have a fund distribution, but not have an encumbered value.

  • Sara Colglazier: Would want a $0 amount that does not change.
  • Virginia Martin: Even if manual update?
  • Dennis: You can definitely still edit the POL and update manually. This is specific to renewal logic at this point.
  • Ann-Marie Breaux: Right now when you create an EDIFACT file does not change the price in the POL, only in invoice. 

  • Virginia Martin: Basically other than manual updates this freezes the price. Makes sense.

  • Sara Colglazier: That’s what we do currently and fine with that. EDI invoice from EBSCO for journals – if there is a family (one order with seven titles). Often the price is only associated with one title and all others show as zero on the invoice. Sometimes these will have a separate family line that has the cost. All the actual titles will have zero. Have been imagining creating POs and POLs to reflect this. Line with amount and multiple other POLs with zero. Sometimes the line that has the cost will change. What will happen then? If set up to be updated, will it flag it? 

  • Ann-Marie: Say you have an invoice with a line that says $7,000 and covers 7 titles below it, each with $0 price. When you keyed in that invoice, I think what would happen is if you had a match to the line then it would link to the POL and put the invoiced price against that package. What I don’t know is if you had seven additional lines for an amount of zero if those would link to other purchase order lines if you had created them and if they had a $0 price.

    If it didn’t match up, it would be visible. Don’t know if the zeros would match.

  • Kristin Martin: Will this create a hidden gotcha for some library down the road that might not be expecting that? Sounds okay now, but may be an issue years from now.

    • From Virginia Martin to Everyone:  12:19 PM

      that makes sense to me, Kristin

  • Dennis: POL has price of zero. Reason why is because you don’t encumber this order. Still want to have a fund code because you want to know where money is coming from or for reporting. Say in EBSCONET has price of $100. If you have decided that you want to send price information (that’s a configuration in EBSCONET), that $100 comes into FOLIO and says I need to update the cost of the purchase order line – it’s not $100. In FOLIO mapping, would look and say well the user created this POL with $0, we won’t update the price. Assuming that you have given $0 because you do not want an encumbrance.

  • Kristin Martin: Fear of making assumptions.

  • Martina Schildt: UI does not show that. People may forget and enter zero without knowing that this prevents updates. Would rather have a clear UI (toggle, etc.)

  • Dennis: Or just leave it to set within the system. Don’t send FOLIO the price.

  • Sara Colglazier: In EBSCONET renewal happens to be end of August beginning of September. Often price is only an estimated price. Over course of fiscal year, get supplemental invoices with additional costs because of price adjustments (increase, currency fluctuation, etc.). Would this be an ongoing price update? Or would this only happen at the point of renewal?

  • Virginia Martin: In Aleph look at actual transaction, rather than tab where you entered price on POL.

  • Martina Schildt: After paying, that is the amount that would be taken into consideration.

  • Dennis: Good point that it would be dangerous to have hidden logic. Should allow it to be updated. If that will cause your system problems, should turn the price part of the integration off.

    • From Virginia Martin to Everyone:  12:29 PM

      I think that's a good place to land, Dennis, that summary you just gave

    • From Lloyd (Marmot) to Everyone:  12:29 PM

      Could we use a hyphen or some other code instead of $0?

  • Dennis: Moving forward if we need to build in more control, would need to have some of that on the FOLIO side. That is beyond what we are trying to accomplish here.

  • Sara: When you say integration are you talking about settings for all? Example: with Five Colleges if each library wants to handle it differently. Format is an important point to bring up. For example with standing orders. Don’t know how renewals on that front are being handled; do not want cost information because it will be misleading. Price can vary significantly. Would not want an amount encumbered from some kind of estimate. Sounds like if there is a zero it will be updated. Like Martina’s idea of a toggle to not change. 

  • Dennis: Need a configuration to address this. Cannot always assume if it’s a zero don’t update it. For the time being, would rely on the configuration of EBSCONET which allows you to make decisions on what information is being sent. If this is in your integration config, FOLIO will not stop that from happening for any reason. In the future we can talk about more restrictions and nuance.




Dennis Bridges

Discuss usability of Allocation “To” and “From” @12:35



Dennis: If I want to increase: actions > allocation > increase by $100. Straightforward. To decrease in previous versions you were able to put a negative number. You were allocating to a budget -$100. Decided we would not let users input negative amounts, but rather they would say allocate “from” which is a decrease in allocation. Not overly intuitive that this is allowed with the blank field. Suggested that we choose a word or descriptor for the empty field. Allocating from African History to outside the system or to African History from outside of the system.

  • Ann Crowley: What if you just added increase and decrease next to "to" and "from"?
  • Bill Verner: Or you could just classify as a credit or a debit. Would default to credit since that is most frequent.

  • Dennis: So have a selector at the top, like an extra toggle to control what displays.

Question that had come up was maybe to give this a label, but it might be hard to use something that will match all use cases.

  • Virginia Martin: Like the idea of credit and debit.

  • Dennis: Could be moving allocation from one fund to another.

  • Bill & Virginia: Not an allocation, but a transfer.

  • Bill: Neither process should impact the total allocated budget and if one does, that would be a problem.

  • Vriginia Martin: Why is there functionality to allocate from one fund to another?

  • Dennis: Two funds. A & B each with $100. You decide at some point in the year, that you want to take $20 from A and put it in B. There are two ways to do that. You might make the decision that next year you want fund B to have a budget of $120 and fund A to have budge of $80. Other possibility is you are just moving $20 as a temporary movement of funds (transfer).

Move the money around so new year allocation will reflect adjustments made during the year.

Questions as to whether there was a stated need for this.

  • Dennis: Need was to be able to control what is budgeted for the year, vs. what moves around the system to facilitate purchases.

“To” and “From” are not very intuitive. Rather than labeling empty space, might be able to clarify by having user specify the function they are trying to perform. Will take away and put together a mockup to discuss maybe next week.

  • Sara: If there is going to be this one window, can we have a toggle where we check off this is an allocation vs. this is a transfer? Check that. Once checked for allocation and say debit, then it’s clear to the system that I am making an adjustment to an allocated amount. With transfer would have from “Science book” to “Science ebook.”




Dennis Bridges

Display piece information on Inventory holdings record @12:56


Display piece information on Inventory holdings record

In inventory app when you look at a holdings record, at the bottom you can see the receiving history. There is a table with enumeration, chronology, and public display toggle. Don’t want to get rid of this functionality and want to leave it there if you are not using receiving app, etc.

To address this will add a source column to the display area.

Rather than have two separate tables (one that shows information from the receiving area and another that shows manually added information), will show altogether in a table and will show the source (“Receiving” – from a piece in the receiving application or “User” – manually input by user).

Will review on Friday to get comments.