Bug 9126 - Receiving orders create too much items
Summary: Receiving orders create too much items
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: master
Hardware: All All
: P5 - low critical (vote)
Assignee: Julian Maurice
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-21 16:38 UTC by Julian Maurice
Modified: 2019-06-27 09:24 UTC (History)
4 users (show)

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


Attachments
Bug 9126: Do not return from Check too early. (2.39 KB, patch)
2012-11-21 16:40 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 9126: Do not return from Check too early. (2.57 KB, patch)
2012-11-29 13:38 UTC, Jonathan Druart
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 9126: Do not return from Check too early. (3.10 KB, patch)
2012-12-27 11:05 UTC, Katrin Fischer
Details | Diff | Splinter Review
[Passed QA] Bug 9126: Do not return from Check too early. (3.18 KB, patch)
2013-01-14 22:33 UTC, Elliott Davis
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2012-11-21 16:38:02 UTC
If AcqCreateItems = 'receiving', receiving an order create 1 not wanted additional item. This is due to patch for Bug 8637 that exit function Check() too early.
Comment 1 Julian Maurice 2012-11-21 16:40:51 UTC Comment hidden (obsolete)
Comment 2 Katrin Fischer 2012-11-29 10:28:52 UTC
Hi all, 
this is a critical bug in 3.10 - it would be awesome if someone could test and sign-off on this soon.
Comment 3 Jonathan Druart 2012-11-29 13:38:19 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2012-12-01 20:41:53 UTC
I can reproduce this on master - changing version.
Comment 5 Katrin Fischer 2012-12-01 22:07:56 UTC
I had managed to create 2 items during one of my first tests, but have not been able to reproduce it since.
Comment 6 Katrin Fischer 2012-12-01 22:37:57 UTC
Hi Julian and Jonathan,
I tested on master and on 3.8 - I can't reproduce it apart from that one time I thought it happened. What am I missing?

AcqCreateItem = receive
UniqueItemFields = barcode

- I create a new basket, ordered quantity = 1
- I close the basket and start a new chipment
- I receive the items, I tried
  - only filling out the barcode
  - only filling out the itemtype
Comment 7 Julian Maurice 2012-12-03 07:50:11 UTC
Hi Katrin,
there's a thing I forgot to mention: it must be a partial receipt, so you can test by creating an order with quantity=2, and receive only one item.
Comment 8 Katrin Fischer 2012-12-03 08:25:40 UTC
Hi Julian,
I think that was the crucial bit of information - I had started testing with a partial receive and that was probably the one time I could reproduce the problem.

If someone else could sign this off... I could QA it later...
Comment 9 Kyle M Hall 2012-12-07 15:27:53 UTC
I'm unable to reproduce this bug on master. Perhaps a video of the bug in action would be helpful.
Comment 10 Julian Maurice 2012-12-10 08:42:32 UTC
Hello Kyle,

I think the additional item is not created because of "unique key" on items.barcode. You may see in log file something like this:
  DBD::mysql::st execute failed: Duplicate entry '013' for key 'itembarcodeidx at /home/julian/koha/src/C4/Items.pm line 2105
  DBD::mysql::st execute failed: Column 'itemnumber' cannot be null at /home/julian/koha/src/C4/Acquisition.pm line 1094.

Try the following steps:
  - create order with quantity=2 and go to receipt page
  - fill the item form for the first item with a unique barcode and click 'add'
  - in the new item form change barcode so it is unique too but do not click on 'add'
  - click 'Save'
  - you should have 2 items created but parcel.pl indicates only 1 item received.
Comment 11 Katrin Fischer 2012-12-27 11:05:28 UTC Comment hidden (obsolete)
Comment 12 Elliott Davis 2013-01-14 22:33:45 UTC
Created attachment 14574 [details] [review]
[Passed QA] Bug 9126: Do not return from Check too early.

If there is no errors, it should continue instead of returning true.

+ move a block of code at the end of Check function. This avoid
detaching and re-attaching a HTML block if there are errors.

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
The following queries show us the issues:
select count(*) from items;
select * from aqorders_items where ordernumber=XX;

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
To test:

AcqCreateItem = receive
UniqueItemFields = barcode

1) Create a new basket
2) Create a new order with quantity > 1
3) Close the basket and create a new invoice/shipment
4) Receive only 1 item.
   - Fill out the first item form with item type only. Click add.
   - Don't change second item form at all.
   - Click save.

Before patch:
2 items are created on the record, both with the selected itemtype.

After patch:
Only 1 item is created, which is correct.

Signed-off-by: Elliott Davis <elliott@bywatersolions.com>
Seems to work as described by the test plan
Comment 13 Jared Camins-Esakov 2013-01-15 04:01:07 UTC
This patch has been pushed to master.
Comment 14 Chris Cormack 2013-01-15 04:40:41 UTC
Pushed to 3.8.x and 3.10.x
Comment 15 Julian Maurice 2013-02-01 11:13:33 UTC
Ok in 3.8.x, 3.10.x and master.