2020-05-01 Meeting notes

Date

Attendees

Discussion items

ItemWhoNotes
Minute taker


 Announcements/Updates

  • No PC meeting 4/30
  • Reporting cluster review is upcoming - May 8th (next meeting).  See Slack channel for list
  • Item State conversations: PO Emma B will join one of RM SIGs meetings sometime in May to discuss behaviors in relation to acquisitions/receiving.  For example, should the item status be allowed to be changed back to 'on order' after receipt.  Should that happen through the acq apps (with the permissions associated with them).
  • Kristin and Dennis met to reorder topics for today's session - will start with financial topics

Return to Receiving discussion

Receiving examples:

  • Levant Pack
  • American Political Science Association Membership
  • See notes 2020-03-13
Didn't address this topic during this meeting

Renewal interaction

  • When POLs are renewed, what information should be reflected at the Agreement Line level? How should different apps interact to support renewals?
Didn't address this topic during this meeting

Jiras that need SIG review

See list in Jira

  • UXPROD-2392 Set money aside as awaiting payment for Invoices that are "open"
  • UXPROD-2318 Export orders in bulk in delimited file format
  • UXPROD-1581 Receiving material without an order record
  • UXPROD-1129 Ability to communicate individual purchase order information to vendor with no integration
  • UXPROD-199 Ability to import/export fund updates via CSV file in order to bulk edit funds

UXPROD-2392 Discussion:

  • Q2 feature - attempting to address the issue that if you create an invoice and there are no orders associated with that invoice, your funds won't be encumbered. When the invoice is paid the money will be pulled from the fund, but there is a "crack" in the processes since it isn't showing encumbrance.
  • Example walked through by Dennis: 
    • Created an invoice line for shipping costs to make sure that the invoice line doesn't related to a purchase order linewhich guarantees that there is no encumbrance.  When you approve the invoice, FOLIO moves the values to "awaiting payment."  
    • The problem is, there was no encumbrance for the line we created.  If it doesn't relate to an order that has an encumbrance, that amount isn't committed as an encumbrance.  
    • How to resolve?  Options:
      • Option 1 - detailed approach: We could create a new type of transaction 'awaiting payment'.
        • The source would always be an invoice (not a POL).  When you look at a budget, this amount would get included in the "Awaiting payment" bucket.
        • It would behave the same as an encumbrance, except that there would never have been an encumbrance.
      • Option 2 - simplified list using "Committment" transaction type: We could essentially change the "encumbrance" transaction type to "Commitment". When we open an order, we would be making a "commitment."  When we approve an invoice, line, that could also commit funds.  
        • This would allow us to see, on the transaction list, a clearer more simplified list
        • If the source of the commitment is "invoice", then that will be a clue that this transaction was never encumbered

Question from Virginia Martin: For ongoing orders that you don't encumber them year to year - would that get lost?  Exactly the same scenario - it's important to be able to clearly see what's encumbered vs. an invoice awaiting payment.  How will we be able to report on those  - 

  • Dennis - yes, we need to make sure we have a transaction for these and what do we call it?  You'll see it at the budget level, and at the order level, we have the awaiting payment value, we're just missing when there is no encumbrance initially.  Small group though "encumbrance" is misleading for these since it was never encumbered.  We could make an "awaiting payment" transaction (option 1), but what do we do with that? There would be a payment transaction, but the awaiting payment would go down to zero.

Scott Perry:  Need to look at financial picture in the aggregate, not just fund by fund.  Drill down when needed, but need to make sure we can see aggregate as well.

Dennis:  I want to see detailed information about what's happened.  If we're seeing $0 for encumbered values we want to see what is awaiting payment in the transaction list.

Aleph provides a transaction view.  

OLE provides a summation

Virgina wants the option to have the encumbrance not released, so both need to be possible; I don't have a preference for the default.

Dennis:  The consensus is that the detail is important to see at the transaction level.  

Use case from Virginia/Sara: spending restrictions were put in place and we needed to see total amount encumbrance vs. total amount that is awaiting payment (hasn't been sent to AP yet).  We need to be able to distinguish between these.  There is different level of commitment between these two states and it's important for us to see both

Standing orders aren't encumbered - Mt Holyoke doesn't encumber any standing orders.  When they arrive we invoice them and it commits the money from the fund, but prior that there are no dollars encumbered.  At Duke there are over 5000 standing orders that aren't encumbered.  Chicago as well - no encumbrances for continuing orders.

Dennis - we're talking about two different things:

  1. making sure money is committed.  critically important for standing orders etc.
  2. when you get beyond that - its about sorting out the origins of transactions.  Would like more details about use cases.  If the use case is I'm the librarian processing invoices, and I need to see how much money in my fund is awaiting payment vs. encumbered vs expended.  What are the reasons why I need to see why I have $34 awaiting payment here?  Am I looking at invoices and why am I trying to find that out?
    1. Virginia - would want to be able to see if there are 5 orders, I want to see the list of 5.  Recently had a list of invoices in awaiting payment status and they weren't getting paid.  She needed to see all of those invoices to find out if they'd gotten lost or to track what happened.  Just need to be able to investigate in various scenarios.
    2. Kristen Wilson: Encumbrance review at the end of year - they validate all encumbrances to ensure that they are valid (clean up).
    3. Virginia - will want to see all the awaiting payments toward end of year to dig into and investigate.

Ann Crowley (via chat) - can we add the PO line to the transactions screen?

Dennis summation:  Seems like we're leaning toward the detailed approach (option 1).  In the case that we didn't have an encumbrance in the first place, we would create an awaiting payment transaction linked directly to whatever invoice resulted in that transaction.  Need to make sure that we always have a link to the records that triggered the transaction to enable detailed investigation.

Last question:  When these commitments happen - originally the key states were Approved, Paid.

  • At what point in time do these amounts need to be applied.  is it when we create our invoice?  Initial state is "open".  Once an invoice line is created, we want to trigger a pending transaction and unencumbered the amount.
  • If you make a mistake, if you want to go back and add an adjustment for example.  You can go in and edit the invoice line to add the shipping cost adjustment.  The system will go back into transactions and adjust accordingly.  this could be an negative impact, if we're manipulating on the fly.  
  • Scott - Is there somewhere to indicate that I'm finished with the invoice lines, now check them.  
  • Dennis - we could add a status of pending so there is a state where you can work on it an get it where you want it and then open it - the encumbrances are created as soon as you open the invoice.  That would improve performance issues.
  • Sara - would the open status mean I can't change anything?
    • Currently you can edit an invoice that's open.  It's the approved state where things get locked down.
  • Sierra (Marmot User Services - consortium in Colorado of public, academic libraries) doesn't have an awaiting payment status and I don't see the need for it.  You order things, the money becomes encumbered, then it's paid.  Period.  I don't care if the check hasn't been cashed yet, or whatever.  Feels like an extra step.
    • Sara - it becomes "paid" once we have transferred the info to the AP system.  
    • Same at Duke 
    • Isn't this something we can control in settings? 
      • Dennis -yes. But if we open approve pay all at one time or we stagger this out it won't be as simple any more.  From a development standpoint, we may commit the funds on approval and in stage two allow for the possibility of committing the funds on Open and allowing a pending status before that.  More complex.
  • Scott Perry: It is really based on if I'm using FOLIO to manage my whole process of getting invoices to the AP system.  We have a separation of duties and need to track that. I need to have those steps built it or have the option to skip it in settings).

Dennis - Conclusion

The feature is 2393 "Set money aside as awaiting payment for invoices"  I think we should split this because we absolutely have to be able to commit the money.  Worried that if this becomes bigger it won't get done in Q2.  He'll simplify this original one, create a second feature that addresses adding the pending status.  The enhancement of encumbrances and traceability for transactions that relate to awaiting payment would also be a separate feature.  He'll post the JIRA numbers and we can rank them.

Action items

  •