2022-01-07 Acquisitions Meeting notes

 - Working on getting roadmap fully updated on the web site. 

• Will be having more discussions on the SWOT analysis. 

• Will be talking more to the community council 

8:07

Implementer's Topics - "Orders: Inconsistent terminology between filters, detail pane, and .csv export for "Date opened"" @Julie Brannon (old account) 

• What do you call the date that is captured when you opened the order

• I thought the approval date and the order date were always the same, but I now I know the nuances of it. 

  • But because of workflows, for some that will be different. 

• Dennis: We talked about this a little a while ago. There is a date ordered field, but it's only shown once an order is opened. You don't see the date ordered field until the order is opened.  (This is in Kiwi). They can be be the same if you don't have a separate workflow approval step. 

  • Sara: What happens if I open, unopen, then Open?

    • Dennis: Currently it is reset. 

    • Sara: So the approval date could potentially be the original date, and the date ordered could change each time the order is opened, 

  • Kristin Martin: We don't have an approval process so that is essentially when the order was entered into the system. 

• 8:25

• Release encumbrance

• Currently, for ongoing orders, we check this box by default. 

  • For some of you, you are not using encumbrances and this isn't a factor. 

  • But if you do, when you receive your first invoice of the year, no matter how much you are paying for it, any money left over in the encumbered value will be released if you don't uncheck this box.  Should we adjust this behavior to a default not checked 'release encumbrances'?

    • Kristin: If you do have the box not checked, then any money left in the encumbrance for that fiscal year will stay. 

    • Denis: We now also have a manually release encumbrance option. 

    • Sara: It's not subscriptions, they are paid once a year. It's the standing orders that can be billed multiple times a year. 

    • Dennis: This topic is also implementers topic no.34

      • Julie: we were confused why this box defaulted. Hearing the use cases is helpful to understand. 

      • Dennis: I'll make a note on the topic in the wiki page, that it's standing orders, not subscriptions, that should be defaulted to false. 

    • Owen: Is it the case that standing orders are more likely to have multiple invoices against the same encumbrance, but it could be that there isn't more than one?

      • Dennis: Yeah, it'll default

      • Owen, But even with the default set on the Standing order, it may not be that helpful since they are unpredictable. 

      • From Sara Colglazier (MHC/5C) to Everyone 08:41 AM
        Correct, Owen: Annuals are singles generally

      • From Scott Perry (he/him) to Everyone 08:41 AM
        Generally not that regular

      • From Susan Martin to Everyone 08:41 AM
        Mono series can come more than once a year, but one never knows how many you get

    • Owen: I am not clear that a default one way or the other is helpful. 

    • From Sara Colglazier (MHC/5C) to Everyone 08:42 AM
      I think that is why a lot of us do not encumber for them :-)

    • From Susan Martin to Everyone 08:42 AM
      +1

    • From Scott Perry (he/him) to Everyone 08:42 AM
      +1

    • From Susan Martin to Everyone 08:43 AM
      Is there anyone here on the call who does/want to/will encumber their S/O?

      • Peter: Yes, in some libraries within their network they encumber standing orders. 

    • From Scott Perry (he/him) to Everyone 08:45 AM
      I find it easier to forecast how much will be spent on standing orders, but not at the specific order level

  • Dennis: Maybe the default isn't as important as better labeling what the function is. 

  • From Owen Stephens to Everyone 08:48 AM
    From what I’ve heard I’d summarize as: Basically Standing Orders are a pain and if we genuinely want to solve this they probably need special handling separately to other types of orders. But on the other hand the represent a relatively small number of orders so ultimately staff can work around problems (as they currently do)

  • From Susan Martin to Everyone 08:48 AM
    Yup. Sums it up exactly. Standing orders are a real PITA.

Use cases for cancelling orders, then reinstating.  

8:48

• Talked about cancelling orders that are partially fulfilled, or reopening an order. 

• If an order is closed as cancelled, and was partially paid for, partially received, are there any situations where you would pay again? Without receiving? Or receive additional material without paying?

• Sara: Yes. 

• From Kristin Martin (she/her) to Everyone 08:51 AM
  We'll be receiving titles on migrated POs, where we paid in the old system, but are migrating the closed PO and still need to receive.

• Dennis: So if your order is closed, it's closed because it's cancelled. It may be because the publisher said they were not publishing anymore, but then later start publishing again. Would you want to pay and receive on a closed order?

  • Sara: That is situational and based on timing. 

• From Heather to Everyone 08:55 AM
  I would not want anyone to be able to put an invoice on a closed order.

• From Kristin Martin (she/her) to Everyone 08:56 AM
  +1 heather

• From Susan Martin to Everyone 08:56 AM
  +1 Kim

• From Peter Sbrzesny to Everyone 08:56 AM
  +1 to Heather and Kim

• From Sabrina Bayer to Everyone 08:57 AM
  +1 to Heather

• Dennis: When you cancel a po, you can have a single or multi line order. If we cancel a po with an action, that will result in the order state , payment status and receipt status being changed to cancel. Does it make sense to allow you to pick a reason for closure when you are cancelling an order?

• From Scott Perry (he/him) to Everyone 08:58 AM
  I want an alert for a closed order (which is, I think, already there).

• Sara: I want to make sure that when I am in orders and bring up the order I want to overview page that is visible and easy to tell what the status is.