Hello friends. I just decided to move this issue to a clean slate so its easy for the devs to try to reproduce it and see what needs improvement
If theres a way to add short clips, I could also post this behavior against previous pos search finesse.
I am not assuming a perfect world but using a very real scenario we experience everyday to build this.
1. Reproducible problem with searching:
Create a clean installation of v9
Create one item, call it Sample and give it a barcode of say 12345678, add a selling price and save the item
Head to pos after setting up any profiles and customer ids if you like.
Open online pos and confirm the single item Sample
In the search field start typing s
-observation: on typing s, item is added to the cart automatically, search field is cleared
Try again, faster, sam item is updated quickly to 2. Search field is cleared
Type with a mistake, fast, like sampt, you get no data, clear, on removing t, the item is added again, qty of 3. Search field is cleared
So with this behavior amidst thousands of items, and there’s a need to search, you get items randomly flying into the cart. Imagine I wanted to type artemeter, while I’m at a, in a split second something might fly in, if I go fast enough and pause to see in a split second, what im getting, the first thing that matches what I entered, is sent into the cart. Again, lets not assume everyone can type super fast. Please lets try this.
What we used to have (sorry guys, I’m refering to v6)
You can naturally type a barcode up to 12 digits, except youre excessively slow and get a match while typing, nothing goes in.
If you type an exact match, even as short as 4 digits, the pos takes a second or so before the item is entered.
Ok, this is actually what I would expect to happen. Since there is only one item in the database and it begins with “S” the search function determined there was nothing else it could be and added it to the cart.
Had there been multiple items with the first letter “S” then they would have all been displayed in the items grid on the right side of the screen.
I do not see the problem with this part.
Here we see the same thing. Again, there is still only one item in the database that can possibly match so it is added to the cart. On the final test, when the “t” is removed, you again have a search sequence where there is nothing else possible in the database so it is added again.
I do not see the problem with any of this.
Now you’re just making assumptions because you may not fully understand how the search works. I tested this by adding artemeter and artichoke both to my test database and when I typed “a” both items were displayed in the item grid on the right side of the screen, but nothing in the cart until I had typed “arti” and then artichoke was placed in the cart.
The search feature only moves items to the cart when there is no other matching description possible.
As for the barcode digits, I will have to set up another database to test this. Probably later tonight when things slow down a bit.
I knew you’ll see it that way haha. But here’s the problem in real life amongst many many items. It starts to match things at random. I think summarily;
Only a barcode match should enter the cart automatically
If a barcode match is not found, present results and let user choose. Asides barcode match, nothing should enter the cart
This was exactly your previous design in v6. Its the finest thing I have ever seen in pos!!
Thats actually the issue, it should not make any exact matches when its not a barcode match, the user must then choose. This is the core of our issue! Please think about this again.
Google doesnt take you to a website when its one result, you choose. A barcode on the other hand is a unique, perfect match.
If you put 3 items sample, sample product 1 and sample bar product 2, you will find sample always jumping in too quickly before you can make a good search. Although we have trained them to pick more unique parts of the string where possible. But try this too.
But you Sir, may be very fast on the keyboard. Most of our cashiers are not computer literate, first experience is when they sell at a computerized store.
Do you know I could have Sample blue and Sample yellow. Now some inventory guy didnt put the new stock which is sample yellow, but its been displayed in store (real scenario, happens in all, all the shops around here). Now cashier is looking for sample yellow, its not been created, but while shes at sample, item has gone in, she may not look again (then on this pos the names are so short), she has added a wrong item and stock gets messed up. The right item is really not being handled on the system, I cant begin to elaborate more. You can imagine the scenario Sir.
For searches without the barcode match, let the results wait so cashier has a split second to confirm sample yellow before its automatically added.
I cant over emphasize this, but this should just never be. The only item that ‘seemingly’ matched the search in say 100 items can still be the wrong one, maybe a variant of the one erpnext saw as the only match! It may be an item physically in stock but hasnt been created but was purchased with signed papers to be entered, not finding it should help fix the problem at inventory, please Sir. Lets revert to what it was. Match and enter only on barcode match, display wildcard matches and allow user to select. wildcard search selection should never be decided by a system, its a users search and decision.
Ok. I think this might be a solution to the issue you experience. Even if others are not experiencing it, this might prevent similar issues to show themselves later.
That should not require much more than an IF statement in the search process to redirect anything other than a barcode match to force user to select the result from the item grid on the right side of the screen (even if only one result is displayed).
The only thing I worry about here is if this search routine is used in other parts of ERPNext. It may require some extra logic to make it only act this way in POS.
While I do not personally see a problem with how the current search works, I can see enough benefit to your proposed solution to add it to a list of changes.
This does not address the partial barcode search issue you have also brought up. For this I believe forcing a barcode standardization is really the only answer. While ERPNext will not prevent you from having 2 different items with the following barcodes:
Item 1 - barcode 123456789012
Item 2 - barcode 123456
It would require a “good practices” program to be in place to prevent such things from being allowed at the location.
Barcodes should be standard length and format. If multiple formats are used, then it is up to the user to make sure the formats do not interfere with each other.
For example:
At one of my client sites, they purchase items from wholesalers and they manufacture their own items as well. The wholesale purchased items all have a UPC format barcode already in place. Since the items the client manufactures changes with each season of the year, they cannot get official UPC codes fast enough to sell the items before the season ends. Instead of UPC code for these times they generate an 8 character barcode that always begins with 2 letters followed by 6 digits. In this way the 2 different barcode formats to not intersect and cannot be mistaken for each other.
This is ok and feasible for a manufacturer though. It is infact right for them. They buy a handfull of raw materials from suppliers, produce their own packaging for end products and decide on a scheme for all their finished goods.
Come to retail Sir. Different ball game, you can have over 300 suppliers in some stores supplying products from every corner of the world, including locally made items from manufacturers with little inventory knowledge or even control systems. Wow! Thousands and thousands. So its impossible to standardize. I believe stores in some developed countries will not accept products without a barcode because my friend, its a huge problem. Imagine when you have total inventory items over 800, 000 across 20k+ skus!!! Massive brother.
But im so confident in v6 search, it wasnt scared of anything, such elegance.
V6 had no issue with this!. If you entered 123456 and just paused briefly when you are done and it matched a barcode, it just pulled it in. If you kept typing it allowed you proceed until you paused again, if it matched you will see in cart, if it matched other field, you would see results as you were typing. If any results were left and there was no match for a barcode, you are left to decide if one of the results is valid for the sale.
Great! I also pointed out in other post it should be a very easy fix for a team as good as this, so lets push it forward, based on these optimal patterns.
@bkm All I’ve been trying to explain is nothing new; its what erpnext has always been until now. Check screen shots. you search, even 1 result waits for you to select, not to make the decision for you!
