Summary: | receiving items should allow for entering barcode | ||
---|---|---|---|
Product: | Koha | Reporter: | Nicole C. Engard <nengard> |
Component: | Acquisitions | Assignee: | Srdjan Jankovic <srdjan> |
Status: | CLOSED FIXED | QA Contact: | Bugs List <koha-bugs> |
Severity: | normal | ||
Priority: | P5 - low | CC: | chris, dpavlin, julian.maurice, koha.sekjal, kyle.m.hall, mglavica, stephane.delaye |
Version: | Main | ||
Hardware: | PC | ||
OS: | All | ||
See Also: | http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7175 | ||
GIT URL: | Change sponsored?: | Sponsored | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 7048 | ||
Bug Blocks: | |||
Attachments: |
patch
patch patch patch patch patch patch |
Description
Chris Cormack
2010-05-21 01:21:33 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. *** Bug 6356 has been marked as a duplicate of this bug. *** +1 to Katrin's suggestion. Created attachment 5421 [details] [review] patch This proved to be larger then I initially thought. Full set of items can be edited at the time they are received. "+" button is there to insert additional items. However: * There is no '-' button to remove items. I'm not sure what is required there. * The way that form is submitted/processed is unreliable in some ways. I tried to catch errors, but it may be possible that they are silently ignored. Please test thoroughly. Also, I have changed interfaces to AddItem() and ModItem(), so regression testing on parts of the system that use those ones is required. 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. 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. 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 = 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. Created attachment 5556 [details] [review] patch supplierid was not being passed on properly. I believe it's an old bug. Fixed. 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'. 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. Created attachment 6128 [details] [review] patch Some of the things there are still a bit of a mystery to me (creating new order upon partial receive, totals and some other figures on the receipt summary screen). I've enabled "-" button (link actually). Please test and voice your impressions. 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) 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. 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. Can you please tell us what is your AcqCreateItem syspref. Thanks. Patch applied for me. Can we please have another go? Created attachment 8047 [details] [review] patch 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 Created attachment 8195 [details] [review] patch Actually this is more for modifying items that were created when making an order, so additional details can be added when receiving an order. New patch, old one does not apply any more 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. 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 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 Created attachment 8465 [details] [review] patch There was a HTML isssue. Can you please check now and maybe comment. I've expanded + and - with words 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$ 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. 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. I signed off on 7175 for this, since it handles more. Not sure we need this one if that one makes it through QA. Fixed with 7175 |