Bug 9948 - acq data going on first item even if not received
Summary: acq data going on first item even if not received
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Jacek Ablewicz
QA Contact:
URL:
Keywords:
Depends on: 9224
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-28 19:49 UTC by Nicole C. Engard
Modified: 2019-06-27 09:24 UTC (History)
6 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: Small patch
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
receiving not editing items right (26.02 KB, image/png)
2013-12-13 17:06 UTC, Nicole C. Engard
Details
[PATCH] Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives (2.42 KB, patch)
2013-12-14 12:51 UTC, Jacek Ablewicz
Details | Diff | Splinter Review
Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives (2.52 KB, patch)
2013-12-17 18:06 UTC, Nicole C. Engard
Details | Diff | Splinter Review
Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives (2.58 KB, patch)
2013-12-20 17:38 UTC, Kyle M Hall
Details | Diff | Splinter Review
[PASSED QA] Bug 9948: Fix acqui/finishreceive.pl so it will update item data properly on partial receives (3.11 KB, patch)
2013-12-20 22:02 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
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!