Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Approving an invoice with multiple lines that ref the same POL 2 payment 1 credit. Causes over reported encumbrance value on budget

Description

Overview: Approving an invoice with multiple lines that ref the same POL 2 payment 1 credit. Causes over reported encumbrance value on budget

Steps to Reproduce:

  1. Log into some FOLIO environment as User X

  2. Click invoices app

  3. Create invoice

  4. Add 3 invoice lines based on the same POL

  5. For line number 2 make the amount negative

    • Eg. line 1 - $10, line 2 - (-$10), line 3 - $10

  6. Click approve invoice

Expected Results: Invoice is approved successfully and the desired payments/credits are created as expected. The related POL encumbrance is also updated as expected and released if one or more of the line have "release encumbrances" = true.

Actual Results: invoice is approved and encumbrance is release but the budget encumbered value does not change. ie. $10 is still encumbered but now there is no way to release it.

Additional Information: Reproduced 2 in folio-testing (lotus)

Library creates one invoice each month for the previous month’s credit card charges for each credit card holder.  (In this case POLs 18251-1, -2, -3, -4, -5 were charged, refunded, and re-charged due to a PayPal issue where the vendor could not retrieve his payment from the original money sent for the goods.) In order to report all this activity the library wants the charge, credit and new charge to appear on the voucher.
URL: 
Interested parties:

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Attachments

3

Checklist

hide

TestRail: Results

Activity

Show:

Dennis Bridges January 27, 2022 at 6:28 PM

Test successful in bugfest-kiwi

Oleksii Petrenko January 26, 2022 at 3:35 PM

Deployed to Kiwi BF. Please proceed with verification

Siarhei Hrabko January 10, 2022 at 7:33 PM

Verified via API tests agains folio testing

Damien January 4, 2022 at 5:58 PM

The merged commits turn parallel processing into sequential, for pending payment creations. They may or may not be necessary to fix , but they have been merged already and they help to fix the bug, and they may be necessary, so it doesn't hurt to leave them.

The main fix for needs to be done in mod-finance-storage, so I created a separate ticket, MODFISTO-280. So it's not a separate issue, but it should be considered a hotfix candidate: will not be fixed without MODFISTO-280 (which is why I set it as a blocker). And yes, the result of and MODFISTO-280 is incorrect budget totals that users may not be aware of.

Dennis Bridges January 4, 2022 at 5:51 PM

 just to clarify, there are a few commits under this issue. These address the parallel processing problem with an interim solution. However, we need to address in properly by refactoring this processing in mod-finance.

MODFISTO-280 is a separate issue that occurs even with this interim solution in place? If so, it should also be consider a hotfix candidate. The result of this issue would be incorrect budget totals and a user would not be aware it was happening. 

Done

Details

Assignee

Reporter

Tester Assignee

Labels

Priority

Story Points

Sprint

Development Team

Thunderjet

Parent

Fix versions

Release

Kiwi (R3 2021) Hot Fix #1

RCA Group

Legitimate regression

Affected Institution

MI State University/Library of Michigan

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created December 9, 2021 at 6:16 PM
Updated June 27, 2022 at 9:29 AM
Resolved January 10, 2022 at 7:34 PM
TestRail: Cases
TestRail: Runs