2022-09-09 Acquisitions Meeting notes



  • Alissa Hafele, Ann Crowley, Ann-Marie Breaux, Björn Muschall, Dennis Bridges, Dung-Lan Chen, Dwayne Swigert, Emily Robertson, Heather McMillan, Jackie Magagnosc, Julie Brannon, Kathleen Norton, Kayla Valdivieso, Kimberly Pamplin, Kristin Martin, Linh Chang, Lisa Maybury, Lloyd Chittenden, Martina Karlsson, Masayo Uchiyama, Molly Driscoll, Nancy Pelis, Okay Okonkwo, Owen Stephens, Robert Heaton, Sara Colglazier, Scott Perry, Scott Stangroom, Shannon Burke, Sven Thomsen, Winter White


  • Housekeeping -

    • next meeting, Tuesday (9/13) at 1 pm
    • If planning a conversation regarding FYRO experience/reflection/info sharing is still of interest within the group

    PC Updates (Kristin Martin) -

    Business -

          no.50 - Invoice approve/pay with pending Order

Discussion items

  • Are people interested in having a session to discuss Fiscal year rollover with Institutions that have completed the process?
    • Bjorn: This was recently done in the German group and  it was a good session.
    • From Julie Brannon (she/her) to Everyone 08:04 AM
      As your faithful documentation working group representative, I'd be interested to know if anyone used the https://lotus.docs.folio.org/docs/acquisitions/finance/#rollover-fiscal-year documentation during rollover and whether it was helpful/feedback/suggestions :)

  PC UpdateKristin

 - Met at WolfCon

  • Did a retrospective and looked forward
  • A few things of interest to the SIG
    • Would like to enhance the PC relationship with the SIGS in ways that aren't there now. How can we better understand where there are gaps to address in the roadmap.  
    • What exactly are we talking about when we say folio product? What is the product? Different groups and people have different ideas of what that is. How do we work with outside groups
    • Look at the scope criteria group. 

WOLFcon recordings

From Julie Brannon (she/her) to Everyone 08:13 AM
This is a handy compilation of Wolfcon 22 recordings



:15no.50 - Invoice approve/pay with pending OrderBjörn Muschall 

no.50 - Invoice approve/pay with pending Order

  • The approvement/payment of an Invoice should not be allowed if the linked Order is pending since transactions will not behave as expected. Opening the Order after approval/paying creates new encumbrance transaction for current FY with values for Awaiting payment resp. Expended = $0.00 even though the Invoice is already processed. For this reason, the encumbrance/expended amount is not taken into account during FYRO. Right, it's the wrong workflow. But a warning would definitely help to address this issue. For my liking I would prefer a modal warning when approving and paying an Invoice  with pending Order (with options Cancel/Proceed). Or even more restrictive just present an error message and not let it happen. I would really appreciate a solution for that since it caused a lot problems with us. Thanks for consideration.

    Addendum: After fixing transactions on database level and bringing it to the attention of colleagues, this workflow error occurs again and again.

  • From Sara Colglazier (MHC/5C) to Everyone 08:19 AM
    I guess I did not realize that you could approve/pay an invoice on an Order with Status Pending?! I am just want to make sure I am understanding correctly.
    +1 to that!!
  • From Scott Perry (UChicago) to Everyone 08:19 AM
    This seems like a bug to me.
  • Dennis: Is there a use case for paying an invoice against a pending order?
    • Several people agreed.
  • EDI will not link to a pending po, but you can manually add it. 
  • From Julie Brannon (she/her) to Everyone 08:22 AM
    Agreed that this should be treated as a bug - order should be in open status before invoice can be approved.
  • Dennis: If there is a multi line invoice, you would expect every order to be open to approve?
    • From Kimberly Pamplin to Everyone 08:24 AM
      From Scott Perry (UChicago) to Everyone 08:24 AM
      From Dung-Lan Chen to Everyone 08:24 AM
      From Julie Brannon (she/her) to Everyone 08:24 AM
      Yes - if an invoice relates to multiple orders we'd still want all orders to be in an open status
      From Scott Perry (UChicago) to Everyone 08:24 AM
      Yes.  Blocked regardless of encumbrance
  • Owen: I am not sure why this is important to people?  
    • From transcript "I feel like I understand why arises like that decision that you don't have to have a fund allocated to the order. When you do the the fund transaction to creating a transaction against the fund to the invoice that is a transaction for the invoice, and you've never created one for the order.  So there isn't one for the order so that that's kind of down to you.  But i'm wondering I suppose but 2 questions are one would be like I'm. not sure I've quite understood like why this is really important to people like what is the outcome that it is that people aiming at is it  that they don't want to have a situation, where they can possibly send an order that's not allocated to a fun code, so that that doesn't arrive.
       or is it that they want to be able to retrospectively link this back in the way that you may be in a smooth way, but but essentially in the way that this is described?
       So that if you then do do the invoice and it's linked to an order line and the transaction, then there should be some creation of a transaction at that point, that's linked to the order or is it just a navigation thing
       that that it's about being able to navigate from the order to to something else. "
    • From Ann-Marie Breaux to Everyone 08:33 AM
      It sounds like maybe we need to tease apart what current scenarios need clearer documentation, but are not bugs/logic problems, versus what may be bugs/enhancements that need to be considered for fixing/changing.

    • From Sara Colglazier (MHC/5C) to Everyone 08:34 AM
      We documentation that spells out ripple effects of forking decisions ...
    • From Dung-Lan Chen to Everyone 08:34 AM
      If we need to specify fund code when paying/approving invoices since money has to come from somewhere, then why not have the fund code specified in the POL to begin with.
    • From Scott Perry (UChicago) to Everyone 08:36 AM
      I consider the ability to approve an invoice with a pending order to be a bug of the first order, especially since it seems to impact encumbrances.  Looking to see the impact on the recording of the payment in the transactions (all of them have funds).
    • From Owen Stephens to Everyone 08:36 AM
      I think that's a good question Dung-Lan - and perhaps the issue is that you may have 'orders' that are not paid? (free stuff, pre-payment, ???). I'm guessing a bit here
    • From Ann-Marie Breaux to Everyone 08:37 AM
      If that's a decision we want to change now - I know I'll need to pay for this, but I'll decide the fund at point of invoice, not point of order - we can revisit, but it's one of our earliest, basic decisions. And we definitely would continue to allow no fund assigned if there is no expected cost (e.g. free materials or paid/encumbered on another POL)

    • From Owen Stephens to Everyone 08:38 AM
      Is there a short explanation why this decision was made Ann-Marie?
    • Dennis: There are institutions using the orders app and not the finance app
    • Bjorn: There are use cases for intentionally not having a fund code, and use cases for it being a mistake. It would be nice to have a warning that no fund code is applied before opening an order. 
    • From Ann-Marie Breaux to Everyone 08:40 AM
      Perhaps we add a tenant-level setting that requires a fund in a POL (unless est cost is 0)? Or a POL-level warning, like Bjorn is describing?
    • From Dung-Lan Chen to Everyone 08:41 AM
      Sure, gift/exchange/free stuff can still have a fund attached if fund code is required as part of POL approval but we don't have to attach real invoices to complete the PO or attach $0 invoice to close it.
    • Dennis: Do we want to revisit being able to pay an invoice against a close order?
      • From Ann-Marie Breaux to Everyone 08:42 AM
        Good question - paying against closed orders. Would there be a scenario where you thought you paid for all of it, and then an additional fee (or credit) shows up?
      • From Björn Muschall (UB Leipzig) to Everyone 08:42 AM
        What happens with the encumbrance if you close an order?
      • From Ann-Marie Breaux to Everyone 08:43 AM
        So in the scenario that Sara describes, would you want to have to reopen the order? Per Scott, sounds like reopening is not a great solution, but a warning might be helpful?
      • From Dung-Lan Chen to Everyone 08:43 AM
        In FOLIO, reopen a closed PO to attach new invoices is not prohibited.
      • From Sara Colglazier (MHC/5C) to Everyone 08:43 AM
        The warning for it being Closed would be fine, as long as it is still possible
      • Dennis: Is that approach to soft when it's a pending order? Should it just be prevented? It sounds like there are no use cases for paying against a pending order. So a soft warning is not enough. 
        • From Scott Perry (UChicago) to Everyone 08:44 AM
          I don't see any use case for payment on a pending order
        • From Sara Colglazier (MHC/5C) to Everyone 08:45 AM
          +1 to Scott
      • No one else answered Dennis. Silence means no one objects to blocking users paying against a pending order. 
      • From Julie Brannon (she/her) to Everyone 08:46 AM
        Can we submit this as a bug and get it moved into the development pipeline more quickly than a story?
      • From Scott Perry (UChicago) to Everyone 08:46 AM
        +1 Julie
        • Dennis: It's probably more like a missing requirement. 
        • Ann Marie - that is a bug catagory
        • Dennis: Today was the deadline for Morning Glory
        • Sara: In lotus you can see the status of the order?
          • Dennis: Yes. 
          • If one is closed there is a red banner to say one of them is closed?
            • Yes
            • In Lotus you can. 
:53no.54 Creating and filtering piecesSara Colglazier
  • Creating and filtering pieces
  • Would like to have a way of identifying pieces that represent material that will be sent for binding
  • Would like a check box to click that this needs to be sent to the bindery
  • This was discussed in the Cross application interaction meeting as well
  • From Kristin Martin to Everyone 08:54 AM
    We create the item at the time of sending out issues to the bindery, and then check out to the bindery.
  • From Ann-Marie Breaux to Everyone 08:54 AM
    Is there any library doing something to identify these now in FOLIO? location? checked out to a specific bindery (or pre-bindery) patron? tag? something else?
  • From Jackie Magagnosc to Everyone 08:56 AM
    The staff person who does our binding i experimenting with using the Binding note in the Holdings record to put in details. I guess the presence of the note could flag a title as something that gets bound. So at least in our implementation there is a note type defined for binding

  • From Ann-Marie Breaux to Everyone 08:57 AM
    We've definitely talked about pruning the extra item records (after binding). I don't remember talking about a binding flag/checkbox though.
  • From Scott Perry (UChicago) to Everyone 08:57 AM
    I need to leave for another meeting.
  • Dennis: Will have to pick up this conversation later, he does have questions and we are out of time. 
  • From Kristin Martin to Everyone 08:58 AM
    I also have to go. Let me know when this will go on the agenda again, and I can get our expert in this area to the meeting.

Action items