Hi, i am using version 20.5.22 on Mac. while going through inventory i have found duplicate items but do not see any warning when i open inventory tab? I remember it was working on earlier versions. Can some please explain why is it so?
20.6.9
@lubos this appears to be a bug. Manager do not seem to identify duplicates in the Inventory Items tab.
any update on it? is this bug removed/updated or corrected?
When corrected, this topic will be removed from the bugs category and the fix will be announced.
will it be corrected / fixed or it’s gone in forgotten list?
It hasn’t been forgotten. There is going to be new Find & Merge which will work across all relevant tabs, not just inventory. That’s why it’s taking longer.
I have 3 duplicate entry in my Inventory Items . but manager not showing me any yellow box over my Item code or Item Name . i also dont find and " find and merge " option in list . please guide me .
The latest version (20.10.76) is adding Find & Merge back. I won’t be showing yellow box until I’m confident the feature works properly. It is rewritten from ground-up so it can be adapted to any tab (not just inventory items).
So for now, just look for Find & Merge button in the bottom-right corner under Inventory Items tab.
It fully supports History so if you make a mistake merging something you didn’t want to or the program did something wrong, you can undo the changes using undo function in History.
I moved this topic back to bugs. When trying this out in a test business, I had three items that were all the same:
Upon clicking Find & Recode, only two were found:
When Merge was clicked, the following error message appeared:
There is also no option to select which inventory item to merge others into, as there used to be. The only option would be to merge all, even though all items with the same code have not been found. I will continue experimentation with other entry possibilities.
Currently, find & merge looks at the name. Does not consider code yet. This is something I’m still working on.
Fixed in the latest version (20.10.78)
The system will decide this. It scans all the transactions and the primary one will be the one linked to the most transactions. This is because every transaction linked to duplicate item needs to be updated to point to the primary item. This ensures footprint of History for find & merge is as compact as possible.
The automatic selection of surviving item seems suboptimal to me, but is at least rational. The addition of code is vital, though, and should override name as was done previously.
@lubos, a method is also needed for bypassing the merge function. If multiple sets of duplicate items are found, they are displayed one at a time. But the only way to avoid merging a set is to bail out of the process. If you decide to leave items unmerged (perhaps because you want to edit one or more of them rather than merge them), there is no way to move on to another set. So you need a Next button or something similar.
I think it’s fine the way it is. Every duplicate should be resolved either by merging or editing invidiual items until they do not meet duplicate criteria.
I can add Edit buttons on each duplicate so you can either Edit the item or Merge them. But I do not see skipping useful. It just adds extra button to allow ignore the problem. It’s the same principle when within bank reconciliation workflow, there is no skipping as well.
The latest version (20.10.80) is using Code field rather than Name field to determine duplicity.
@lubos, v20.10.80 now has a new problem. If item codes are not used, duplicates are not found at all. I believe you should revert to the legacy scheme:
- If codes were used, they were searched for matches. Codes overrode secondary searches.
- If codes were not used, names were searched for matches.
An Edit button for each duplicate would be a slight convenience, would not solve the problem of needing to bypass a set of duplicates. Here is a simple case:
Item codes are not used. Item A is stocked both as Each and by the Case as two different inventory items, but with the same name. Production orders are used to convert the Case item into multiple Each items—something users are routinely advised to do when buying in bulk and selling by the unit. You would not want to edit either inventory item, nor would you want to merge them. So you need a Next button to move to another set of duplicates.
Your comparison to bank reconciliations does not hold up because, in a bank reconciliation, there can be only one exact outcome. With a limited search scheme for duplicate inventory items, you could have several desired outcomes.
The other alternative is to extend the search to more fields. Item codes should always control if they are used. But if not, names should be looked at, then descriptions, then units of measure. You might not be able to distinguish intentional duplication without examining all those things (and possibly even custom fields). Here is another example:
Again, no item codes. Multiple items are named Star Trek T-Shirt. Descriptions include color and size. Currently, Find & Merge would return nothing, because names are not searched. But to be useful, you would want all colors and sizes of items named Star Trek T-Shirt returned so you could check the descriptions for duplication. And if things had been done properly, you would want to bypass the entire set. If entries had been made incorrectly, you might want to edit or merge just one pair. But with the current situation, you cannot do any of that.
I don’t believe you intend to make item codes mandatory. But the latest implementation requires them or Find & Merge doesn’t work at all.
To me, this is an error. Two items need to be differentiated. They need to have unique code or name. Can’t be the same. There are features that will be built upon the idea that codes / names must be unique. Such as ability to batch update or batch create without using GUID.
That’s why Find & merge cannot have bypass function. Every duplicate needs to be resolved.
OK, that is a persuasive justification not to allow bypassing the merge. It also, however, reinforces the need to search both item codes and item names for duplication, with codes taking precedence.
The way new Find & merge is implemented is that it can find & merge anything. Not just inventory items. And I need to check what generic rule for duplicity must be in place so it’s all consistent across the program.
OK, maybe it doesn’t make much sense what I’m saying but basically I need to improve batch create and batch update first so it doesn’t require GUID, then it becomes obvious how exactly Find & merge must work in relation to what is a duplicate and what is not across all tabs (not just inventory items).
What you say makes sense. But it may also lead to a need for more control of the process. Imagine eventually looking for duplicate customers to merge and finding several with the same name, a distinct possibility.