Release encumbrances when POL payment status is set to canceled and update POL statuses

CSP Request Details

None

CSP Rejection Details

None

CSP Approved

None

Description

Purpose: When reviewing orders it is very difficult to see which are canceled and which are not. The ui should include some indicator in the POL view that clearly identifies each POL as canceled. 

User story statement(s):

As an ordering librarian
I want to have the ability to easily mark a POL as canceled and know that any encumbrance will be released
so that my budget will no longer be impacted by POLs that I do not intend to pay

Acceptance criteria:
Case 1 :

  • Given POL has fund distribution

  • When POL payment status is changed to canceled

  • Then all related POL encumbrances for the current FY are given status of released.

  • AND budgets are updated accordingly

Case 2: order from Closed to Open (ReOpen) This case will be covered by a separate story

  • Given POL has fund distribution

  • When POL payment status is changed From canceled to Awaiting payment, partially paid or Ongoing.

  • Then all related POL encumbrances for the current FY are given status of Unreleased.

  • AND budgets are updated accordingly

  • AND POL statuses updated accordingly
    If Order type is One-time and POL has no related pieces with status "Received" then
    "Receipt status"= Awaiting Receipt
    If Order type is Ongoing and POL has no related pieces with status "Received" then
    "Receipt status"= Ongoing
    If Order type is One-time and POL has no related invoices that are approved or paid then
    "Payment status"= Awaiting Payment
    If Order type is Ongoing and POL has no related invoices that are approved or paid then
    "Payment status"= Ongoing
    If Order type is One-time and POL HAS related piece(s) with status "Received" then
    "Receipt status"= Partially received
    If Order type is Ongoing and POL HAS related pieces with status "Received" then
    "Receipt status"= Ongoing
    If Order type is One-time and POL HAS related invoices that are approved or paid then
    "Payment status"= Partially paid
    If Order type is Ongoing and POL HAS related invoices that are approved or paid then
    "Payment status"= Ongoing

see wiki for more detail https://folio-org.atlassian.net/wiki/x/JQhU

Environment

None

Potential Workaround

None

Attachments

9

Checklist

hide

TestRail: Results

Activity

Show:

Dennis BridgesJune 13, 2022 at 4:18 PM

Test successful in folio-snapshot

Dennis BridgesJune 13, 2022 at 4:06 PM
Edited

 creating additional stories sounds logical to me as the scope of this story should only including Canceling order.

One correction to your statement above for story 2:

2. Story : Update logic of the payment status for "Cancel" ongoing order flow
When closing ongoing order with reason for closure NOT EQUAL to canceled. Payment status is set to Fully paid.
When closing ongoing order with reason for closure EQUAL to canceled. Payment status is set to Canceled.

Actually I think that was my error from the post above yours. I have corrected it in both places. When ongoing order is canceled the Payment status would be set to Canceled unless it is already in a "Resolved" status like 'payment not required' as per our previous stories.

Andrei MakarankaJune 13, 2022 at 1:04 PM
Edited

Hi

When the order is canceled or closed, the logic of changing payment status for ongoing orders works differently than you suggested above.

We obviously already got confused in the test cases that are the scopes of this story. Move over Case 2 was added by me after questions about "ReOpen" flow.

I propose to remove the Case 2 from the current story and create 2 new ones:

1. Story( Case 2) : Update POLs payment status and encumbrances for "ReOpen" flow after cancelling order.
I propose to remove case 2 from the current story, as it relates to the ReOpen logic and clarify the test cases for encumbrances and payment status for both types of one-time and ongoing orders.

2. Story : Update logic of the payment status for "Cancel" ongoing order flow
When closing ongoing order with reason for closure NOT EQUAL to canceled. Payment status is set to Fully paid.
When closing ongoing order with reason for closure EQUAL to canceled. Payment status is set to Fully paid.

After getting a more accurate picture of the test cases, Nina will go through them again and mark the ones that don't work as expected. Then back-end proceed with the implementation.

What do you think?

Thank you in advance

Dennis BridgesJune 10, 2022 at 4:03 PM
Edited

 Case 2 already describes all scenarios where the encumbrance status should be set to Unreleased. The encumbrance status would only be Released if the Payment status = Fully paid OR Canceled.

The problem this may cause is that when we Close an ongoing order FOLIO is releasing the encumbrances. However, the payment status could still be ongoing because we do not automatically change it to "Fully paid". We may need to add this logic so we can rely exclusively on the Payment status to release encumbrances. This would mean:

When closing ongoing order with reason for closure NOT EQUAL to canceled. Payment status is set to Fully paid.

When closing ongoing order with reason for closure EQUAL to canceled. Payment status is set to Canceled.

 would this make sense to you? If so I believe we will need a separate story for this. 

Otherwise it will be possible to have a Closed Ongoing order with a payment status of Ongoing and encumbrances status of Released. Would this cause a problem currently?

NinaChistovaJune 10, 2022 at 9:14 AM

Hello thanks for your answer! So move In review. And could you please update CASE 2 description consider with "Release" Encumbrance status if order has related approved or paid invoices?

Done

Details

Assignee

Reporter

Tester Assignee

Priority

Story Points

Sprint

Development Team

Thunderjet

Fix versions

Release

Morning Glory (R2 2022)

Affected Institution

MI State University/Library of Michigan

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created March 17, 2022 at 7:24 PM
Updated March 14, 2023 at 10:59 AM
Resolved June 13, 2022 at 4:18 PM
TestRail: Cases
TestRail: Runs