| Summary: | Barcode order is different from submitted in inventory report | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Esther Melander <esther.melander> |
| Component: | Cataloging | Assignee: | Bugs List <koha-bugs> |
| Status: | NEW --- | QA Contact: | Testopia <testopia> |
| Severity: | enhancement | ||
| Priority: | P5 - low | CC: | dcook, m.de.rooy |
| Version: | 25.05 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41932 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14907 |
||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Esther Melander
2026-02-25 17:55:00 UTC
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. 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. (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... |