2021-08-17 Acquisitions Meeting notes

• Bug that we haven’t really fleshed out as a group.
• Paying invoices that have lines that total an amount of 0 or where whole invoice is for 0.
• Before we make a decision wanted to have a discussion with the group. – Why this happens, how you expect it to function, etc.
• Bug found in Iris that also exists in Juniper at the moment. 
  • From Bill Verner to Everyone: 12:04 PM

Can I ask what is the use case for this, and why it's pressing?

• Use case:
  • Most common is that some institutions use if something is damaged. One invoice line on a larger invoice that would be given a value of 0 because they are not going to pay for that item yet.
• Ann Crowley: Issues with approving invoices that have 0 line items on them. Represents something that has been damaged or a duplicate and are returning to the vendor. Three invoices in approved status that cannot go to paid because FOLIO does not recognize 0 value. They put the whole invoice in so that they know why it was short paid.
  • Ann-Marie Breaux: Is the whole invoice total 0 or are you short paying?
  • Ann: We’re short paying.
• Dennis: Problem right now is that the system will approve this. There is no restriction on approving as long as you have a fund distribution, but you cannot transition to paid from there. Technical reason is basically that FOLIO is looking to create a payment or a credit for every fund distribution. It looks at a 0 amount fund distribution and it doesn’t know what to do with that, whether to create a payment or a credit. Fails the payment logic. Will however create a pending payment transaction of 0.
• Are you expecting a transaction to represent that invoice line? In the case of FOLIO that would be a payment transaction presumably.
• Dennis: Ann, in Voyager would you have expected that transaction to appear?
  • Ann: I think in our reports it would have appeared as 0.
  • Dennis: I imagine for reporting purposes it is valuable to have a transaction even if 0.
• Ann-Marie: If you leave out the fund, can you approve the invoice?
  • Dennis: We have a different logic that says you must have fund distributions that account for the totals. You have to have this in order to approve or pay. Could relax that restriction, which would be a different way of approaching. But if you want to have a transaction record, we need to have a fund distribution.
  • Ann expresses a concern regarding relaxing the fund distribution.
• Ann-Marie: Separate but related if you short pay and you have a lock total, would need to edit the total.
• Dennis: The bug is it’s able to be approved, because then you are stuck. Cannot edit, delete, cancel, etc. Maybe simplest solution might be to just tell the system if you end up with a $0 distribution that should be a payment transaction. Instead of greater than 0, equal to or greater than 0.
  • Trick is making sure it does not impact other logic. FY rollover, etc.
• Ann-Marie: Wouldn’t want a transaction of 0 for an encumbrance of 0 on an open PO. Seems like it would be a big clutter of extraneous transactions.
  • Would result in more payment transactions, but that is essentially what you are expecting to see.
  • Ann-Marie: Seems like you wouldn’t want to clutter up with lots of encumbrance transactions of 0 for orders that had a fund assigned but no amount.
  • Dennis: At the moment we do create encumbrances of 0.
  • Ann-Marie: If you are creating transactions for 0 encumbrances, why not payments.
  • Dennis: True. Fair. Ultimately all encumbrances end up being 0 if you release them.
• Seems that maybe this is a more unique workflow than realized. Are there others who have this?
  • From katy.kazee@mtsu.edu to Everyone: 12:17 PM

We can't short-pay. We pay and then apply a credit.

• • From Bill Verner to Everyone: 12:17 PM

We would process a credit memo

• • From Suzanne Mangrum to Everyone:  12:18 PM

+1 to credit memo

• Depending on process with vendor if they are going to charge you again for the thing you are replacing on a new invoice.
• Two schools of thought depending on strictness of accounting:
  • Not able to alter. Pay and then apply credit.
  • Line it out and short pay the invoice.
• Okay: Sometimes we just pay the whole thing, get a credit memo and add back to the same record. Sometimes line out or short pay. They send a new one and put it in a new record.
  • Dennis: Sometimes the vendor doesn’t want to credit and says it is easier to short pay?
  • Okay: Exactly
  • Dennis: So you do it potentially both ways?
  • Okay: Yes
  • From Peter Sbrzesny to Everyone: 12:21 PM

Short-pay is easier but not allowed anymore. We need a credit note.

• Dennis: Other hesitation I suppose would be that if we allow an invoice line to be 0, it is possible that more mistakes happen. Let's say built invoice based on PO lines and all come over as 0 and have to work on adding correct amounts.
  • Ann-Marie: It's on the approver if it is not right.
• Dennis: If I want to approve this thing for $0 have a check box to indicate it is a short pay? Benefit of that is maybe less user error. The downside is it is more work and another box you need to check and review when working with invoices.
  • Okay: Makes sense to me.
  • Ann: Yes.
• Dennis: Or even maybe not necessarily a flag, but a confirmation. One or more of your invoice lines are 0 do you still want to pay? More global
  • Three people in agreement.
• Seems that short pay is a common way to describe this. Is that reasonable verbiage?
  • Confirmed
  • Ann-Marie: Or just saying what it is, you have one or more invoice lines with 0 do you want to approve? Short pay may be a US centric term.
  • Okay: Some of us call it under pay.
• Dennis: Ann-Marie you brought up the lock total; that check would happen first. Amount would still have to be equal. If they are, then the system would confirm you have invoice lines here that are 0, "do you still want to confirm?"
• Scott Perry: Important to call out the invoice lines. It should tell you where the problem is instead of making you look for it.
  • Use some kind of identifier like the exclamation point to know the specific line where it is an issue.
• Ann-Marie: What happens to the fully paid exclamation point if the order line has a zero and payment line has a zero, do we get an exclamation point?
  • Dennis: Does the order amount have a bearing in that way? Does that make a difference?
  • Are there orders for 0 that you would consistently invoice 0 for? Doesn’t seem likely to me.
  • Ann-Marie: If we set the logic of payment = 0 or above will it trigger a bunch of accidental exclamation points?
• Dennis: Maybe use something similar to duplicate invoice warning. Show different invoice lines in a table when asking are you sure you want to approve? And warning to indicate that the line is zero dollars on the invoice line. Is it necessary to do both?
  • Ann: Just looking for a way to identify it quickly.
  • Dennis: Maybe a FOLIO UX question, because other warnings already exist. Do we need a different icon, etc.?
• Ann: Looked at 2 problem invoices and both POs had an estimated price. Dollar values, not 0.
• Dennis: Conclusion I think we have come to is that we should allow short paying, although we will not call it that. Should allow invoice lines for 0 to be approved and paid. When that happens will simply create a 0 payment transaction (not credit). And there are no use cases for approving an invoice that is actually 0 total? We're just talking about one line or a number of lines?
  • From Mary Moran to Everyone:  12:34 PM

As far as standing orders go, we sometimes receive free copies.  They are either a regular gift from an organization or, like the Loeb volumes, they are free because we buy the online version.  Receiving them on an invoice or packing slip allows us to keep track of them better.

• • So you may actually pay a 0 invoice?
  • Mary: Yes
• Dennis: So, we would allow either individual lines to have a total of 0 or the whole invoice. Still need to have fund distributions to create payment transactions. And basically the check point for this would be when you go to approve the system will confirm, “we’ve noticed that you have some amounts of 0 on this invoice are you sure you want to approve?” Last detail would be identifying the lines that are 0 in some way.
• Any other questions or concerns? Feel free to message in Slack.

• Came up recently that you have the ability to open and unopen orders in FOLIO.

• When you open, we capture the date ordered. Meant to equate to the date sent, once sending orders out through FOLIO. This is the day the vendor became aware that you wanted this thing.
• At the moment in FOLIO, when you unopen an order and open it again we actually reset the date, which seems like it may not be what all users are expecting or hoping for.
  • E.g. order opened on the 12^th. If I unopen this order for whatever reason it will reset the date ordered. Now the order was opened on the 17^th.
• Use case around ongoing orders where you add or remove a POL.
• In current systems do you capture multiple dates or just the initial date ordered? What are you expecting to see?
  • Sara: So in Aleph there’s an open date, an order date, and a status date.
    • On a one-time order where I could envision the open date and order date being different. Could be a case where there’s a lag between creating the order and sending the order. So far have not found an example.
    • Any time edited the status date changes.
• Ann-Marie: Use case -- the most common I am aware of is either where a library is creating orders toward the end of a fiscal year, but not sending them out until after new year starts. Or, sometimes libraries have selectors create beginnings of orders or create beginnings of orders from selector data, but do not approve for purchase until after vetted by somebody and given a final OK to officially order. Are situations where there is lag but also situations where create and order date will be the same.
• Dennis: Three dates that you mentioned open, order, status. How do you get that order date? Is there a specific action for order? Or when you open does that become the order date? In FOLIO opening the order triggers that date. Same in Aleph?
• Sara: 5 colleges circumvents a little bit because we automatically put at status of sent to vendor. Jump over new. If I put something in now, created a new order and the open date is today, no date for order date. When I set the order status to "sent to vendor" that will trigger the order date to fill in. If I create a new order today, the open date would be 8/17. Then if I finish tomorrow and set to "sent to vendor" then the order date would be created then.
• What if you change the status back to new? And then back to sent. Is there an equivalent to unopening?
  • Sara: All dates stayed the same.
• Dennis: In FOLIO seems like the created date would be more like the open date in Aleph. It never changes. Date ordered is open for us. Basically set by transitioning the status of the purchase order to open. Then continues to get reset as you go back and forth. You have an edit log where you can see that was changed?
  • Sara: Yes
• Dennis: Interesting thing to me about this is it’s probably true that you can open an order without sending it again, because we will control export in a different way. If you unopen and then open again but do not want to send it back to the vendor, our plan is to have some controls for that. If that ends up being the case, probably doesn’t make sense to update that date ordered. Rather it should stay the way it is. Right now do not have a choice because we’re not actually sending orders.
• From Peter Sbrzesny to Everyone:  12:45 PM

In our system the dates for each change of status are captured (created, ordered, received, cancelled …). But this is mainly used for statistical purposes.

• From Julie Brannon (she/her) to Everyone:  12:45 PM

Just to fill in Sara's comments: Aleph defines the Open Date as the date that the order was initiated. The Order Date as date that the order was sent to the vendor. The Update Date is the date a record was updated.  All dates are system generated.

• Are many of you on the call surprised to find out that the date ordered changes? Or is that what you would actually be expecting to see?
  • From Jean Pajerek (Cornell Law Library) to Everyone: 12:51 PM

I did not know and I am surprised.

• • From Scott Perry (he/him) to Everyone:  12:51 PM

Surprised!

• • From Julie Stauffer to Everyone:  12:52 PM

I am somewhat surprised - I would expect some permanent create-type date to be retained

• • From Peter Sbrzesny to Everyone:  12:52 PM

I would expect a new order date only when the order has been sent again.

• • From Suzanne Mangrum to Everyone:  12:52 PM

I wouldn't expect it.  We may edit an order--it usually has nothing to do with the order date.  So surprised.