Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled

Bug #1257915 reported by Lebbeous Fogle-Weekley
58
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
2.11
Fix Released
Medium
Unassigned

Bug Description

Seen both in Evergreen master and 2.3.4, purchase orders can get "stuck" in the "on-order" state even when all the lineitems belonging to it have a more final status.

It's simple enough to reproduce.

- Create a purchase order with, say, 3 lineitems and 2 copies on each of these.
- Receive the first two lineitems outright.
- Receive one of the copies on the last lineitem and cancel the other.

You'll see the PO's own state is still "on-order" when "received" would make more sense.

I'm pretty sure "received" would make more sense even in cases where you had a 100 item PO with 1 item received and 99 canceled.

Does anybody have a case to make for the current behavior or for a third way?

Revision history for this message
Bill Erickson (berick) wrote :

Quick note, if any of the canceled items are not really canceled (keep_debits=true), then I'm assuming the PO would remain on-order until such items were received, deleted, or truly canceled.

Revision history for this message
Kathy Lussier (klussier) wrote :

I've asked the acq people here to take a look at this and post any comments if they have feedback. But I do concur with Bill that a distinction needs to be made between canceled items where keep_debts is true and those that are false. We expect that items with a cancel reason of backorder will arrive at some time.

Revision history for this message
Christine Morgan (cmorgan-z) wrote :

I received some feedback from a library on this. They also concur with Bill.

Kathy Lussier (klussier)
Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Jennifer Pringle (jpringle-u) wrote :

We (Sitka) also agree with Bill. If keep_debits = true for any cancelled items than the PO should keep the status on-order. If all items received or cancelled (with keep_debits=false) the PO should have the status of Received.

Revision history for this message
Leslie St. John (lstjohn-deactivatedaccount) wrote :

PINES, on ver. 2.7.1, also agrees with Bill and Sitka, et al. If keep_debits=true for cancelled items then the PO status should be on-order. However, if all items are received or cancelled with keep_debits=false then the PO status should be received.

Revision history for this message
Martha Crawley (mcrawley) wrote :

NC Cardinal, ver. 2.7.4 : I would like to see that taken one step further to have some status that would indicate all have been received or truly cancelled and also invoiced. At the end of the fiscal year we always end up with money still encumbered when we're pretty sure everything has come in. Once we track it down we find that somebody received the items but forgot to invoice them. We've created a report that helps us identify what these are, but it is only useful at the end of the year when the resulting list is not so long that it's unmanageable. If there was one status like received that indicates all are received or cancelled and another status like "complete" that indicates all are received or cancelled AND invoiced, maybe periodic acquisition searches within Evergreen would help us find these earlier instead of having to deal with them all at the end of the year. Each staff person in tech services needs a way to search their own accounts within Evergreen and find these so they can fix them throughout the year.

Revision history for this message
Kathy Lussier (klussier) wrote :

Martha,

I like the idea of using a "complete" status to cover all those PO's that are basically "done." However, I recommend filing that feature in a separate ticket, primarily because I view the original problem reported as a bug, whereas creating a new PO status would qualify as a new feature.

Kathy

Revision history for this message
Blake GH (bmagic) wrote :

This query might have identified the situation:

select purchase_order,string_agg(cancel_reason::text,',') from acq.lineitem where purchase_order in(
select id from acq.purchase_order where state='on-order' and id not in
(
select purchase_order from acq.lineitem where state in('cancelled') and cancel_reason in(select id from acq.cancel_reason where keep_debits) and purchase_order is not null
)
and id in
(select purchase_order from acq.lineitem where state in('cancelled'))
and id not in
(select purchase_order from acq.lineitem where state not in('received','cancelled') and purchase_order is not null)
)
group by purchase_order
order by purchase_order

Changed in evergreen:
assignee: nobody → Chris Sharp (chrissharp123)
Revision history for this message
Chris Sharp (chrissharp123) wrote :

Working branch here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1257915_mark_po_received_with_canceled_lineitems

I have tested by un-receiving an already received lineitem on a PO with canceled items, then re-receiving the lineitem's copies. The PO should then be marked "received".

What I haven't yet tested is what happens when you cancel an item that is the only un-received/non-backordered item on a PO.

Revision history for this message
Leslie St. John (lstjohn-deactivatedaccount) wrote : Re: [Bug 1257915] Re: Acq: purchase orders stay "on-order" with some lineitems received and the rest canceled

on test, po 844. Created list placed order received 3 of the 4 items. 4th I
can't cancel - i get Event: 10102:ACQ_NOT_CANCELABLE -> The object is not
in a cancelable state.
lineitem 37900
so I can't do the test!
Leslie

Leslie St. John
*PINES Services Specialist*
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345-4304
404-235-7129 tel
404.235.7201 fax
www.georgialibraries.org
www.gapines.org

On Wed, Apr 5, 2017 at 11:24 AM, Chris Sharp <email address hidden>
wrote:

> Working branch here: http://git.evergreen-
> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/
> user/csharp/lp1257915_mark_po_received_with_canceled_lineitems
>
> I have tested by un-receiving an already received lineitem on a PO with
> canceled items, then re-receiving the lineitem's copies. The PO should
> then be marked "received".
>
> What I haven't yet tested is what happens when you cancel an item that
> is the only un-received/non-backordered item on a PO.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1257915
>
> Title:
> Acq: purchase orders stay "on-order" with some lineitems received and
> the rest canceled
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> Seen both in Evergreen master and 2.3.4, purchase orders can get
> "stuck" in the "on-order" state even when all the lineitems belonging
> to it have a more final status.
>
> It's simple enough to reproduce.
>
> - Create a purchase order with, say, 3 lineitems and 2 copies on each of
> these.
> - Receive the first two lineitems outright.
> - Receive one of the copies on the last lineitem and cancel the other.
>
> You'll see the PO's own state is still "on-order" when "received"
> would make more sense.
>
> I'm pretty sure "received" would make more sense even in cases where
> you had a 100 item PO with 1 item received and 99 canceled.
>
> Does anybody have a case to make for the current behavior or for a
> third way?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1257915/+subscriptions
>

Revision history for this message
Leslie St. John (lstjohn-deactivatedaccount) wrote :

OK it worked to cancel the line item. The po is still does not reflect
that, nor does the line item until you click on the copies link. But we got
the first bit. YEAH & thanks.

Leslie St. John
*PINES Services Specialist*
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345-4304
404-235-7129 tel
404.235.7201 fax
www.georgialibraries.org
www.gapines.org

On Wed, Apr 5, 2017 at 5:23 PM, Leslie St. John <
<email address hidden>> wrote:

> on test, po 844. Created list placed order received 3 of the 4 items. 4th
> I can't cancel - i get Event: 10102:ACQ_NOT_CANCELABLE -> The object is not
> in a cancelable state.
> lineitem 37900
> so I can't do the test!
> Leslie
>
> Leslie St. John
> *PINES Services Specialist*
> Georgia Public Library Service
> 1800 Century Place, Suite 150
> Atlanta, GA 30345-4304
> 404-235-7129 <(404)%20235-7129> tel
> 404.235.7201 <(404)%20235-7201> fax
> www.georgialibraries.org
> www.gapines.org
>
> On Wed, Apr 5, 2017 at 11:24 AM, Chris Sharp <email address hidden>
> wrote:
>
>> Working branch here: http://git.evergreen-
>> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/use
>> r/csharp/lp1257915_mark_po_received_with_canceled_lineitems
>>
>> I have tested by un-receiving an already received lineitem on a PO with
>> canceled items, then re-receiving the lineitem's copies. The PO should
>> then be marked "received".
>>
>> What I haven't yet tested is what happens when you cancel an item that
>> is the only un-received/non-backordered item on a PO.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1257915
>>
>> Title:
>> Acq: purchase orders stay "on-order" with some lineitems received and
>> the rest canceled
>>
>> Status in Evergreen:
>> Confirmed
>>
>> Bug description:
>> Seen both in Evergreen master and 2.3.4, purchase orders can get
>> "stuck" in the "on-order" state even when all the lineitems belonging
>> to it have a more final status.
>>
>> It's simple enough to reproduce.
>>
>> - Create a purchase order with, say, 3 lineitems and 2 copies on each
>> of these.
>> - Receive the first two lineitems outright.
>> - Receive one of the copies on the last lineitem and cancel the other.
>>
>> You'll see the PO's own state is still "on-order" when "received"
>> would make more sense.
>>
>> I'm pretty sure "received" would make more sense even in cases where
>> you had a 100 item PO with 1 item received and 99 canceled.
>>
>> Does anybody have a case to make for the current behavior or for a
>> third way?
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/evergreen/+bug/1257915/+subscriptions
>>
>
>

Revision history for this message
Christine Burns (christine-burns) wrote :

Hi Chris

We have loaded this fix onto our 2.12 testing server.

I can confirm the first piece works - marking the last copy as received updates the PO status to "received"

Example PO most line items received or cancelled -> 2 line items showing on order -> mark both as received -> PO status is updated to "received"

The other piece does not work. If you cancel the last line item the PO status remains "on order"

Example PO all line items marked as received except 1 -> cancel selected line item -> line item is cancelled but PO stays "on-order"

Revision history for this message
Chris Sharp (chrissharp123) wrote :

Christine,

I added a commit to the same branch that should handle the cancellation issue. Could you please ask your admin to apply that patch and try again?

Thanks!

Chris

Revision history for this message
Bill Erickson (berick) wrote :

Chris, I pushed a fix for canceled lineitems to a new branch, which also includes sign-offs for the existing commits. Fix also includes some minor formatting repairs (kills tabs, etc.)

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/lp1257915-mark-po-recvd-with-canceled-lis

Revision history for this message
Chris Sharp (chrissharp123) wrote :
Changed in evergreen:
assignee: Chris Sharp (chrissharp123) → nobody
tags: added: pullrequest signedoff
Revision history for this message
Christine Burns (christine-burns) wrote :

This new fix works for me as well

marking the last copy as received or cancelled updates the PO status to "received"

Revision history for this message
Galen Charlton (gmc) wrote :

Tacking on 'needstest', but also taking responsibility for writing it.

Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
tags: added: needstest
Revision history for this message
Galen Charlton (gmc) wrote :

Pushed to master, rel_2_12, and rel_2_11, along with a follow-up that adds live_t tests. I'll also note here what I noted in that follow-up:

    It should be noted that the patches for this bug do *not*
    retrospectively mark purchase orders as being received.

If somebody cares to tackle creating an update script, please open a separate bug.

Thanks, everybody!

Changed in evergreen:
milestone: none → 2.12.2
status: Confirmed → Fix Committed
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.