EDI invoices automatically expend debits

[Erica Rohlfs]

Evergreen 2.6

EDI invoices automatically expend the debits. Several libraries need a way to avoid expending (setting encumbrance=f) the fund debits until after staff members can review the items and view /edit the invoice manually. One possible workaround would be to re-encumber / un-expend debits by removing lineitems from the invoice, but it can't be prevented outright without disabling EDI invoicing.

[Kathy Lussier (klussier)]

A request I have received from staff here is that Evergreen wait until an invoice (EDI and non-EDI) is closed before expending debits. That approach would address this issue.

[Christine Morgan (cmorgan-z)]

This is especially problematic around the time of fiscal close. Many libraries do not perform the fiscal close operation until some time after the end of the fiscal year. Some libraries will wait a week or more, while various issues are cleaned up. Invoices that are retrieved after the last day of the old fiscal year are processed by Evergreen and automatically expend from the old fiscal year's funds rather than the new fiscal year.

This is also a problem throughout the year when libraries are trying to reconcile expenditures with a town or institution. Libraries have to compensate for the EDI invoices for which that they have not yet received a paper invoice.

I agree with Kathy that funds on an invoice should not expend until the invoice is closed.

[Bill Erickson (berick)]

If we wait to set encumbrance=f for EDI invoices, would we want to do the same for manually created invoices? I'm guessing manual invoices are generally created at time of payment so this is less of a concern, but for consistency sake, it would be good for both types of invoices to behave the same. Sound reasonable?

[Bill Erickson (berick)]

To answer my own question.. Yes, they should behave the same. It would be confusing for them to behave differently and it would complicate the code. I'm taking a look at this now...

[Bill Erickson (berick)]

Today, encumbrance=false indicates a lineitem_detail has been invoiced. We will no longer have that information after code for this bug is implemented. We can regain the information by incorporating the code from bug #1380709, which tags the invoice_entry on the fund_debit for invoiced lineitem_details.

There are various cases where we need to know if lineitem_detail has been invoiced. Because of this, I consider bug # 1380709 a prerequisite for this change. I'll be building the new code on top of bug #1380709's code.

[Bill Erickson (berick)]

Code, Perl live test, and release notes pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1333254-invoices-paid-on-close

This code includes code from bug #1380709 -- I'll rebase to master and remove these commits once said branch is merged (or we they could be merged all together).

From the commit:

    To test:

    1. Activate a purchase order with at least one lineitem/copy.
    2. Create an invoice for the PO.
    3. Confirm PO shows same amount encumbered as before invoicing and $0
       paid.
    4. Close the invoice.
    5. Confirm amount encumbered on the PO is reduced by the amount invoiced
       and the amount paid on the PO is increased by the amount invoiced.

[Bill Erickson (berick)]

Rebased to master after merge of bug #1380709:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1333254-invoices-paid-on-close-rebase

[Kathy Lussier (klussier)]

Hi Bill,

When testing this code, we found it works as you describe when clicking save and then close. However, if the user immediately clicks close without first clicking save, the funds stay encumbered. For other functions (e.g. changing quantities or prices), clicking close on its own updates the values while also closing the invoice. We, therefore, have users who have gotten into the habit of just using that one button when it's time to close the invoice.

Kathy

[Bill Erickson (berick)]

Thanks, Kathy. Looking at that now...

[Bill Erickson (berick)]

Fix pushed to same branch. What Kathy describes was the intended behavior, just had to fix a code thinko.

[Christine Burns (christine-burns)]

Tested on mlnc2 VM

Tested both processes successfully

Clicking Save and close -->
1. Activate a purchase order with at least one line item/copy.
2. Create an invoice for the PO.
3. Confirm PO shows same amount encumbered as before invoicing and $0 paid.
4. Save the Invoice.
5. Close the invoice.
6. Confirm amount encumbered on the PO is reduced by the amount invoiced and the amount paid on the PO is increased by the amount invoiced.

Only clicking close -->
1. Activate a purchase order with at least one line item/copy.
2. Create an invoice for the PO.
3. Confirm PO shows same amount encumbered as before invoicing and $0 paid.
4. Close the invoice.
5. Confirm amount encumbered on the PO is reduced by the amount invoiced and the amount paid on the PO is increased by the amount invoiced. "Paid" label now appears beside the line item on the purchase order

I have tested this code and consent to signing off on it with my email address, [<email address hidden>], and name, [Christine Burns].

[Kathy Lussier (klussier)]

Hi Bill,

We still have problems with one workflow that involved multiple copies.

1. Activate a PO with a line item that contains 2 copies at a price of $15. A total of $30 is encumbered from the fund.
2. Add the line item to an invoice, but update the # Invoiced / # Paid entries to 1.
3. Click Close without first clicking Save.
4. The Total Invoiced updates to 2 and the Total Paid updates to $30. If you look at the individual debits in the Funds interface, both debits are set to false in the encumbered field.
5. Reopen the invoice. The Total Invoiced updates to 1 (should be 0), the total encumbered is $15 (should be $30), and the total paid is $15 (should be 0).

Also adding a note that if you click Save and then Close using the above workflow, the system correctly expends just $15 for that 1 copy.

Everything else is looking good from our end!

Kathy

[Bill Erickson (berick)]

Thanks for the testing and details, Kathy. I have pushed a change to address the problems described.

[Kathy Lussier (klussier)]

Looks good to me Bill! Merged to master for inclusion in 2.10.

Thank you so much for testing Christine! Just as I hit Enter, I realized I forgot to add your sign-off to the commit. Apologies for the oversight!