Bug 9948

Summary: acq data going on first item even if not received
Product: Koha Reporter: Nicole C. Engard <nengard>
Component: AcquisitionsAssignee: Jacek Ablewicz <abl>
Status: CLOSED FIXED QA Contact:
Severity: critical    
Priority: P5 - low CC: abl, fridolin.somers, gmcharlt, jonathan.druart, katrin.fischer, tomascohen
Version: Main   
Hardware: All   
OS: All   
Change sponsored?: Sponsored Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 9224    
Bug Blocks:    
Attachments: receiving not editing items right
[PATCH] Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives
Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives
Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives
[PASSED QA] Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives

Description Nicole C. Engard 2013-03-28 19:49:54 UTC
This is hard to explain so I did a video: http://screencast.com/t/COozHEj58ny

If you choose to receive 1 item out of multiple and that item is not the first one Koha puts the acq data on the item you didn't receive, not the one you received.

Tested in 3.10.4 and master.  The bug is in both.
Comment 1 Katrin Fischer 2013-06-16 21:02:37 UTC
Hi Nicole, 
I had watched the video a while ago, but it's no longer available :(
I have tried to reproduce this on current master, but couldn't.
I was using AcqCreateItem set to on order and received only one item to which I had added a barcode from the receive screen.
Do you have an idea what I could have done differently? Can you still reproduce the problem?
Comment 2 Katrin Fischer 2013-06-16 21:26:56 UTC
Eeek, I found it. While the invoice is linked to the right item, so the items tab in staff is correct, the replacement and purchase price are on the wrong item. Upping severity - weird bug!
Comment 3 Nicole C. Engard 2013-06-17 12:09:29 UTC
Here's the video again: http://screencast.com/t/a71HEUjuzZFs 

Now I'm going to test on master.
Comment 4 Nicole C. Engard 2013-06-17 12:29:51 UTC
I do believe you are right and this is fixed in the current master. I'd like to know how/when though so that it can be fixed in 3.10.x

Nicole
Comment 5 Katrin Fischer 2013-06-17 12:46:12 UTC
Hm, did you see comment 2? I managed to recreate it in the end, just confused that the invoice links correctly, but the data is entered into the wrong item (or so it seemed).
Comment 6 Nicole C. Engard 2013-06-17 12:51:16 UTC
Oh darn!! Well then it's still a bug and I was using my Monday brain - which should never be used to find and report bugs :)
Comment 7 Nicole C. Engard 2013-12-13 17:06:57 UTC
Created attachment 23524 [details]
receiving not editing items right

This is still a big issue and now this preference: AcqItemSetSubfieldsWhenReceived also comes in to play. Today is 2013-12-13 and I received an item.  I have AcqItemSetSubfieldsWhenReceived set to change subfield 7 to 1 on receipt. In the attached image you see that the second item has the right subfield 7 but the third item has the pricing info that came over from receiving in Acq.
Comment 8 Jacek Ablewicz 2013-12-14 12:51:20 UTC Comment hidden (obsolete)
Comment 9 Nicole C. Engard 2013-12-17 18:06:06 UTC Comment hidden (obsolete)
Comment 10 Kyle M Hall 2013-12-20 17:38:08 UTC Comment hidden (obsolete)
Comment 11 Katrin Fischer 2013-12-20 22:02:34 UTC
Created attachment 23739 [details] [review]
[PASSED QA] Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives

Problem summary: when doing partial receives for the given order -
1) if AcqCreateItem is set to 'ordering', various item data (price,
dateaccessioned, replacementprice, replacementpricedate) are getting
erroneously updated on the wrong (yet to be received == not the ones
being currently received) item records
2) if AcqCreateItem is set to 'receiving', newly received
item records are being created without the aforementioned fields
set to the proper values

This (trivial) patch should deal with both cases, hopefully without
breaking enything else.

To test:
- apply the patch,
- create some orders with 2+ quantity
- test partial & non-partial receives for those orders
- ensure the received item records are getting modified
(for AcqCreateItem set to 'ordering') and/or created (for AcqCreateItem
set to 'receiving') correctly for both partial and non-partial receives
- receiving orders with quantity = 1 / receiving orders in non-partial
mode should be still working fine for 1) & 2) scenarios (i.e.,
AcqCreateItem set to 'ordering' / AcqCreateItem set to 'receiving')

Signed-off-by: Nicole C. Engard <nengard@bywatersolutions.com>

Works as I'd expect now! Awesome patch.

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Passes all tests and QA script.
Also: t/db_dependent/Acquisition/
      t/db_dependent/Acquisition.t

Created 2 orders with 3 items each for both settings
of AcqCreateItem (on receive, on order) with the patches
applied. No regressions found.

Closed baskets and received shipments for each, with
AcqCreateItem set according to how the order was created.

First recreated the problem without the patches, reloaded
database and confirmed that the patch fixes it.

No problems found.
Comment 12 Galen Charlton 2013-12-23 16:05:58 UTC
Pushed to master.  Thanks, Jacek!
Comment 13 Fridolin Somers 2013-12-30 10:18:51 UTC
Patch pushed to 3.14.x, will be in 3.14.2.
Comment 14 Tomás Cohen Arazi 2014-02-07 15:00:07 UTC
This patch has been pushed to 3.12.x, will be in 3.12.11.

Thanks Jacek!