Bug 3966 - receiving items should allow for entering barcode
Summary: receiving items should allow for entering barcode
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: Main
Hardware: PC All
: P5 - low normal with 10 votes (vote)
Assignee: Srdjan Jankovic
QA Contact: Bugs List
URL:
Keywords:
: 6356 (view as bug list)
Depends on: 7048
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-19 10:27 UTC by Nicole C. Engard
Modified: 2013-12-05 19:53 UTC (History)
8 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
patch (26.00 KB, patch)
2011-09-14 04:00 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (25.99 KB, patch)
2011-09-23 00:38 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (36.88 KB, patch)
2011-11-01 07:35 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (35.74 KB, patch)
2012-03-07 07:04 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (35.47 KB, patch)
2012-03-13 04:32 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (34.92 KB, patch)
2012-03-22 07:29 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (39.68 KB, patch)
2012-04-03 03:44 UTC, Srdjan Jankovic
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:21:33 UTC


---- Reported by nengard@gmail.com 2009-12-19 22:27:51 ----

When you place an order you enter the item information for the items you're ordering, but since you don't have them yet you don't have a barcode. When you go to receive you aren't shown the item information again - this means I have to go into cataloging and add the barcode to the item records after receiving an order.

I suggest allowing the addition of the barcodes to the items on receiving - or showing the entire item again so that edits can be made and a barcode added right from acquisitions.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:21 UTC  ---

This bug was previously known as _bug_ 3966 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3966

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.

Comment 1 Katrin Fischer 2011-03-14 06:39:42 UTC
+1

At the moment this only works if you add items on receive, but not if you add items on order. I think it should always be possible to add a callnumber, barcode and perhaps other specified fields on receive.
Comment 2 Katrin Fischer 2011-05-18 08:06:41 UTC
*** Bug 6356 has been marked as a duplicate of this bug. ***
Comment 3 Nicole C. Engard 2011-05-18 15:08:22 UTC
+1 to Katrin's suggestion.
Comment 4 Srdjan Jankovic 2011-09-14 04:00:35 UTC Comment hidden (obsolete)
Comment 5 Ian Walls 2011-09-14 14:45:42 UTC
This patch changes the output of a several C4 subroutines; a test plan should include first identifying all calls to those subroutines, and then any calls to subroutines making those calls, and so on.  Scope should include more than just C4 (include all script pages and cronjobs).

This comment does not indicate anything about the patch itself; just want to communicate the need for thorough and cautious testing for anything that changes C4 subroutines input or output, since such changes cascade the most easily.
Comment 6 Srdjan Jankovic 2011-09-15 01:11:33 UTC
I cannot possibly come up with a plan myself, but here's the list of the scripts that use AddItem() or ModItem() in some form:

cataloguing/additem.pl
catalogue/updateitem.pl
serials/serials-edit.pl
serials/serials-recieve.pl
acqui/addorder.pl
acqui/addorderiso2709.pl
acqui/finishreceive.pl
tools/manage-marc-import.pl
tools/batchMod.pl
tools/inventory.pl
misc/maintenance/touch_all_items.pl
misc/cronjobs/longoverdue.pl
misc/cronjobs/cart_to_shelf.pl
misc/commit_biblios_file.pl
circ/waitingreserves.pl
circ/returns.pl
circ/branchtransfers.pl
circ/circulation.pl
opac/sco/sco-main.pl
opac/opac-renew.pl
reserve/modrequest.pl
reserve/renewscript.pl ("ReturnToShelvingCart" yes)
rotating_collections/transferCollection.pl
offline_circ/process_koc.pl
members/paycollect.pl

To be precise, most of them do not use the return value at all (I believe only catalogue and acqui do), but for the sake of completeness.
Comment 7 Katrin Fischer 2011-09-21 06:37:40 UTC
I have started testing this. I found one smaller problem so far and will continue testing tonight:

== OK! Cataloguing ==
- Add new record, create new items, using
  * add item
  * add & dublicate
  * add multiple copies
- Edit existing items (cataloguing/additem.pl)
  * add new fields
  * change existing fields
- Delete items
  * delete single item from 'edit items' screen
  * delete all items from staff detail page
- Attach item to another record (cataloguing/moveitem.p)

== OK! Serials ==
- Create subscription, enable 'create an item record when receiving this serial'
  * mark serial arrived and create item using 'receive' link (serials/serials-e$
  * mark serial arrived and create item using 'edit serials' link (serials/seri$
Note: /cgi-bin/koha/serials/serials-recieve.pl seems outdated and should
probably be removed.

== Acquisitions ==
- Create new basket
- Create order lines, using
  a) catalog search
  b) external source / z39.50
  c) new
  d) suggestion
  e) staged file
- receive everything
- check items

Each for
= 1) AcqCreateItem set to 'in cataloguing' =
d) Note: quantity defaults to 0, should be 1 (not scope of this bug)
d) Note: currency should default to vendor currency (not scope of this bug)

On receive no items can be added. This is correct.

PROBLEM: After receiving of an item and saving you get to a blank receive page.
It should bring you back to your vendor specific receive page with a list
of ordered items to receive (works when I switch back to master branch)

= 2) AcqCreateItem set to 'on order' =
d) Note: currency should defalut to vendor currency (now bug 6894)

On receive ordered items can be edited. This is correct.
Note: Bibliographic frameworks used seems to be 'Default'. I would be nice
if it would be possible to specify a frameworks to be used here (like for
ACQ).

PROBLEM: Same es for 1). After receiving an item you are brought back
to a blank screen

= 3) AcqCreateItem set to 'on receive' =

...still to be tested
Comment 8 Katrin Fischer 2011-09-22 05:39:34 UTC
= 3) AcqCreateItem set to 'on receive' =

On receive ordered items can be created. You can even order more items than 
you have ordered - which is nice too.

PROBLEM: Same as before - page after receiving an item is wrong.
Comment 9 Srdjan Jankovic 2011-09-23 00:38:18 UTC Comment hidden (obsolete)
Comment 10 Srdjan Jankovic 2011-09-23 00:40:33 UTC
supplierid was not being passed on properly. I believe it's an old bug. Fixed.
Comment 11 Katrin Fischer 2011-10-08 22:32:00 UTC
I see some problems with item creation 'on order'. It's no longer possible to do a partial receive (example: only 1 of 2 items was delivered).
You can receive more items than you have ordered (example: 2 ordered, adding another item using the +), but when saving, there is an error messsage 'Error adding items'.
Comment 12 Katrin Fischer 2011-10-18 06:07:44 UTC
After more testing I think this bug depends on the problem noted in bug 7048. 

Partial receive is broken after applying this patch, because there is currently no way to remove item forms from the acq pages. If you have ordered more than one item all items related to the order line are pulled in to be edited on receive (as they should be) But there is no way to remove one of them - so no way to do a partial receive. 

I think for this problem to be fixed, we have to fix bug 7048 first.
Comment 13 Srdjan Jankovic 2011-11-01 07:35:12 UTC Comment hidden (obsolete)
Comment 14 Katrin Fischer 2011-11-01 08:26:48 UTC
Hi Srdjan, 
thx for your work on this :) Can you give a bit more information about the problems/questions you have?
Perhaps I might have caused confusion with the 'being able to add more items than were ordered' bit. I think it should not be possible to do so, or it would be a new feature.
For the minus sign there is some discussion on another bug and a bit of a mystery. Perhaps you have an idea about it? (bug 6740)
Comment 15 Srdjan Jankovic 2011-11-02 01:03:18 UTC
It is quite possible that "+" feature should stop when reaching the ordered quantity number, ie if there should be no provision for updating order with new items at the time of receiving (more received then ordered for whatever reason). Please confirm.

The removal functionality seems to had been there, and then removed. I've put it back in again, so not knowing why it was removed I'm a bit cautious. Especially with the "move missing items to a new order".

Also I believe items and orders left below "delete" link figures are incorrect. But that may have been like that before.

I deliberately chose to deal with 6740 bug here rather than wait because I may have merging problems. Why is that button disabled - I can only guess.
Comment 16 Julian Maurice 2011-11-04 10:03:27 UTC
There's something strange: I have a vendor who have only 1 basket. This basket contains only 1 order, and the order contains 3 items.
If I receive less than the 3 items, in the 'Pending Orders' table, I now have 2 orders: the first one which have not changed, and a new one with the quantity I've received. And in the "Already received" table, there are the same order lines, with different quantities (one is 0...).
I tested without the patch, it works normally, so passed to Failed QA.
Comment 17 Srdjan Jankovic 2011-11-07 05:56:56 UTC
Can you please tell us what is your AcqCreateItem syspref. Thanks.
Comment 18 Srdjan Jankovic 2012-03-07 06:58:42 UTC
Patch applied for me. Can we please have another go?
Comment 19 Srdjan Jankovic 2012-03-07 07:04:39 UTC Comment hidden (obsolete)
Comment 20 delaye 2012-03-12 14:55:22 UTC
After apply the patch, I'm confused and I do not know what to test.
I understood that the patch allowed you to turn when receiving the opportunity to enter a bar code for each copy when the preference system AcqCreateItem = "on order"

This is a recurring request from many customers: the ability to create copies on the orders while having the opportunity having the opportunity upon receipt to indicate the bar code of each copy received it to avoid to go in the module cataloging
Comment 21 Srdjan Jankovic 2012-03-13 04:32:36 UTC Comment hidden (obsolete)
Comment 22 Nicole C. Engard 2012-03-19 12:57:05 UTC
Test plan:

* Set AcqCreateItem to 'placing an order'
* Order 1 copy of a title
* Order 2 copies of a title
* Receive order
* Receive title with 1 copy
* Receive title with 2 copies
* Set AcqCreateItem to 'receiving an order'
* Order 1 copy of a title
* Order 2 copies of a title
* Receive order
* Receive title with 1 copy
* Receive title with 2 copies


In both cases this line failed:

* Order 2 copies of a title


I was unable to edit the 'Quantity received:' on either of these. I should be able to receive more or less if I want to.

In the case of AcqCreateItem = 'placing an order' it says 2 and won't let me change it to 1. In the case of AcqCreateItem = 'receiving an order' it says 1 and won't let me change it to 2.
Comment 23 Chris Cormack 2012-03-19 16:54:54 UTC
You were using the plus and minus links eh? You have never been able to type the quantity but have to click the plus or minus.  Just checking because that has caught me in the past
Comment 24 Nicole C. Engard 2012-03-19 17:52:18 UTC
Chris,

On the receiving page there is no plus or 'add' link like there is on the order page.

You used to be able to type in the Quantity received when receiving just by altering the textbox.

You are right about the order page though - that requires clicking  the 'add' link which has replaced the plus sign.

Nicole
Comment 25 Srdjan Jankovic 2012-03-22 07:29:15 UTC Comment hidden (obsolete)
Comment 26 Nicole C. Engard 2012-03-30 17:37:57 UTC
patch
Apply? [yn] y

Applying: bug_3966: Update items on receive
/home/nengard/kohaclone/.git/rebase-apply/patch:456: trailing whitespace.
        
/home/nengard/kohaclone/.git/rebase-apply/patch:586: trailing whitespace.
            <input type="hidden" name="moditem" value="" /> 
/home/nengard/kohaclone/.git/rebase-apply/patch:735: trailing whitespace.
    cmp_ok($item->{biblionumber}, '==', $bibnum, "new item is linked to correct biblionumber"); 
/home/nengard/kohaclone/.git/rebase-apply/patch:736: trailing whitespace.
    cmp_ok($item->{biblioitemnumber}, '==', $bibitemnum, "new item is linked to correct biblioitemnumber"); 
error: patch failed: C4/Items.pm:2714
error: C4/Items.pm: patch does not apply
/home/nengard/kohaclone/.git/rebase-apply/patch:401: new blank line at EOF.
+
error: patch failed: acqui/orderreceive.pl:116
error: acqui/orderreceive.pl: patch does not apply
error: patch failed: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/orderreceive.tt:49
error: koha-tmpl/intranet-tmpl/prog/en/modules/acqui/orderreceive.tt: patch does not apply
Patch failed at 0001 bug_3966: Update items on receive
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Patch left in /tmp/patch-PSHSnO.patch
nengard@kohavm:~/kohaclone$
Comment 27 Srdjan Jankovic 2012-04-03 03:44:56 UTC
Created attachment 8793 [details] [review]
patch

The interface changed completely, so I tried to follow it best as I could.
Please have a look and tell me if anything does not look right.
Comment 28 Katrin Fischer 2012-04-05 05:35:05 UTC
I think we have a conflict here - bug 7175 also allows you for editing items on receive and it's currently waiting for QA. 
It provides a similar interface for items than we have now when creating items on order - a table instead of lots of forms stacked up on each other.
I am not sure how to solve this, but perhaps it would be good to test the other feature and see where the differences are.
Comment 29 Nicole C. Engard 2012-05-07 14:53:43 UTC
I signed off on 7175 for this, since it handles more.  Not sure we need this one if that one makes it through QA.
Comment 30 Srdjan Jankovic 2012-05-11 02:05:45 UTC
Fixed with 7175