[Bug 41936] New: Barcode order is different from submitted in inventory report
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 Bug ID: 41936 Summary: Barcode order is different from submitted in inventory report Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: esther.melander@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl To replicate: 1. Run an item search to narrow down on a list of barcodes on a shelf. Be sure to sort the items by call number so the barcodes are ordered as they would appear on the shelf. Add the barcodes to a txt file for upload. 2. Go to the inventory module and upload the barcode file (or paste the barcodes into the barcodes box) 3. Select Compare the barcodes to list. Select the library, shelf location, collection code, add the call number range as needed. 4. Select skip items on loan. 5. Submit. Compare the order of the barcodes on the screen to what was submitted. Notice the barcode order is different. Also notice the problem column states all items are not found in the correct place. I would expect the sort order would match what was submitted. If a different sort order is needed, the table tools gives the option to sort the columns differently. Though, most often, an inventory scans the items on the shelf in a particular order. The report should be ordered in the same way. In my scenario, I submitted the barcodes in this order: 312375 312373 312372 312371 312370 311697 311698 308825 312870 311696 312375 308824 311695 The report returned the barcodes in this order (includes barcodes not scanned because I told it to compare the barcodes to the shelf, skipped barcodes of items checked out): 312836 312838 308824 311695 308825 312870 312837 311696 312377 312839 311698 308830 311697 312376 312840 312374 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- I know I bumped into this recently, so I'll look at what's happening... In the item search, the default sort is by title ascending. If you sort it explicitly, it'll say it's using itemcallnumber but under the hood it should use cn_sort (see C4::Items::SearchItems). In the inventory, the sort is by items.cn_sort then itemcallnumber, then title. If an item doesn't have a cn_source or a cn_source that doesn't work with its itemcallnumber, then it will be empty, and that can lead to confusing results. Note that the SQL sorting is lexicographic so L100, L1, and L2 would be sorted like this: L1, L100, L2. -- So often a confusing sorting will be because of having an itemcallnumber which can't be computed into cn_sort in a semantic way. But that's a data problem. Koha is doing the best it can with the information that it has at hand. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41932 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 --- Comment #2 from Esther Melander <esther.melander@bywatersolutions.com> --- I think the problem is that the report is sorting and it shouldn't be. The results should be in the order submitted. The report is causing the problem column to show everything is found in the wrong place even though the user scanned things in order. I am not sure if the barcodes are processed in the order submitted or not. The report seems to imply they are not. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Esther Melander from comment #2)
I think the problem is that the report is sorting and it shouldn't be. The results should be in the order submitted.
What do you mean by report? The inventory results should be sorted in call number order.
The report is causing the problem column to show everything is found in the wrong place even though the user scanned things in order. I am not sure if the barcodes are processed in the order submitted or not. The report seems to imply they are not.
I think that you're misunderstanding how the inventory works. Do the inventory again but don't upload the barcode list this time. It will display the list of items in itemcallnumber order. This should match how they're shelved in the real world. When there is a discrepancy between that generated list and the scanned list, it will highlight the difference. I've had a few libraries lately with this same problem and it's because they're sorting books on the shelves based off how a human understands the call numbers but it differs from how Koha understands the call numbers. That is, how it translates itemcallnumber into cn_sort. If you investigate the cn_sort for your system in question (and try that method of creating a list via the inventory that I mention above) I think the data problem will become clearer to you. You'll want to check the cn_source as well. This is also why Marcel has proposed bug 41932, because the way humans and machines sort call numbers is different unless we apply certain algorithms at the machine level. Let me know if that was clear as mud... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=14907 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41936 Michelle Spinney <mspinney@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mspinney@clamsnet.org -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org