ACQ backordered items show up as canceled

[Jason Etheridge]

Warning, I may have some of the terminology wrong here.

An EDI order response file for a purchase order indicated backordered items, but the interface presents them as canceled (backordered is a cancel reason in the database). This is confusing.

Screenshot attached.

[Kathy Lussier (klussier)]

I can confirm that this still happens in 2.3 and that it is confusing.

[Bill Erickson (berick)]

Agreed it's confusing. It's a terminology problem in the interface. Delayed items behave largely the same as cancelled items on the backend, which is why we use cancel_reason's. However, we need to do a better job of accurately labeling these items in the interface as delayed instead of cancelled. Such cancel_reason's have a well-known ID, so treating these as special seems reasonable to me.

[Bill Erickson (berick)]

Or better yet, differentiate between "delayed" items and truly cancelled items by whether or not the keep_debits flag is true on the cancel reason.

To re-summarize:

When a lineitem is cancelled in ACQ, the cancellation takes two forms: "delayed" lineitems, whose debits stick around, and truly cancelled lineitems, whose debits are deleted. In the ACQ PO interface, it's not possible to tell at a glance which type of cancellation has occurred to a given lineitem. This patch adds styling for "delayed" lineitems and displays the cancel-reason label just to the right of the non-title attributes on the lineitem (i.e. next to author, isbn, ..., source) .

working => user/berick/acq-flesh-li-cancel-reason-repair

This bug requires bug #1088500 to be merged first.

[Jason Stephenson (jstephenson)]

This went in with bug 1088500. The same branch is listed on that bug. I wonder if a branch is missing here or there?

[Bill Erickson (berick)]

Doh! Yep, wrong branch. Should be working/user/berick/acq-style-cancelled-delayed -- Sorry 'bout that.

[Bill Erickson (berick)]

Reverting statuses to "confirmed" since this code was not in fact merged, due to the branch name confusion.

Pushed release notes to the branch. Again, for reference, the branch is:

working/user/berick/acq-style-cancelled-delayed

[Kathy Lussier (klussier)]

Hi Bill,

This looks great when a line item is cancelled from the PO screen. However, I noticed when I canceled a copy from the copy interface, and then returned to the PO, the line item still displays as on order, without the cancel reason displaying, even though all associated copies were cancelled. Is that expected behavior?

I seem to recall from a few months ago that EDI order responses cancel the copies, not the lineitems, so I thought it might be an issue. However, I don't if this has changed with the recent EDI development.

[Tim Spindler (tspindler-cwmars)]

Evergreen 2.3.3

I think this is related and there may be another bug on this but we are finding that if a PO gets an order response file from the vendor and sets the state of the line item to "cancelled-back ordered" that if the item then comes in later, it cannot be received without changing the state of the lineitem in the acq.lineitem table to "on-order"

[Kathy Lussier (klussier)]

Hi Bill,

I took another look at this today with the hope of signing off on the new feature and of handling the separate copy issue in another bug.

However, I noticed one other issue in my most recent testing. I marked a lineitem as canceled with the cancel reason of backorder. The "Backorder quantity" label displays to the right of the non-title attributes as described.

Following the workflow where the backordered item eventually become available and is shipped, I then returned to the PO to mark the lineitem as received. The lineitem status changes to received as expected, and the row changes to the color (lavender?) that is typically used for received lineitems. However, the "Backorder quantity" label continues to display to the right of the non-title attributes.

Could this label only display in cases where the current status of the lineitem is cancelled?

Thanks!
Kathy

[Bill Erickson (berick)]

Hi Kathy, it looks you've uncovered a tangentially related bug. When marking a canceled lineitem/copy as received, the API code is failing to clear the cancel_reason, even though it's changing the status to 'received'. I can push a fix for that...

[Bill Erickson (berick)]

Actually, this raises some interesting questions. For example, if the cancel_reason is a non-keep_debits reason, do we re-instate the debits? Do we prevent it from being received? I'm thinking a separate LP ticket may be in order here. In short, receiving canceled lineitems / copies is not fully functional. I'll open a ticket..

In the meantime, I've pushed a conflict-resolved, rebased branch of the existing code back to the original branch at

working/user/berick/acq-style-cancelled-delayed

[Bill Erickson (berick)]

For reference: bug #1206649

[Kathy Lussier (klussier)]

Thanks Bill! I've moved the release notes to fit into the new 2.5 directory structure and sign off at

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/acq-style-cancelled-delayed

For reference on the other bugs found during testing of this patch:

https://bugs.launchpad.net/evergreen/+bug/978095 - canceling all copies does not cancel the associated line item.

https://bugs.launchpad.net/evergreen/+bug/1206649 - receiving a canceled line item does not remove the cancel reason.

[Bill Erickson (berick)]

Thanks Kathy. It looks like the final commit removed the release notes, but didn't add them back. I shuffled them around and squashed the commit.

I'd like to backport this to 2.4 and 2.3 as well, since this seems more like bug-ish improvement than a new features (release notes notwithstanding). If there are no objections, I'll backport.

[Kathy Lussier (klussier)]

I have no objections to backporting.