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.
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?
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!
Here's the video again: http://screencast.com/t/a71HEUjuzZFs Now I'm going to test on master.
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
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).
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 :)
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.
Created attachment 23555 [details] [review] [PATCH] 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 anything 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')
Created attachment 23606 [details] [review] 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.
Created attachment 23723 [details] [review] 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>
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.
Pushed to master. Thanks, Jacek!
Patch pushed to 3.14.x, will be in 3.14.2.
This patch has been pushed to 3.12.x, will be in 3.12.11. Thanks Jacek!