SKU search broken?

[dgarroway98]

In the last version of the POS, we were able to scan the our products and the SKU search was working. This is no longer working for us.

Are you able to repro?

[kilbot]

There is now a dedicated mode for Barcode scanning. You can switch between ‘Search’ mode and ‘Scan Barcode’ by clicking on the button to the left of the search field.

[dgarroway98]

So happy to hear it is still an option and thanks again for your fast reply.

Just wondering why you would have split it up into two separate searches? For me this is a very, very unwanted feature!

In our case, we try the bar-code 1st and if it doesn’t work we enter in the name. We are so often in-between the two modes I can certainly see it being a real pain to have to toggle back and forth between the modes. There is really no reason to separate the 2 searches that I can see.

In any other POS I’ve used the search box can take either a name or a SKU…your search field was great before!

Also - while we are on the topic, it would be great if the name search would search the name field of all langages (wpml) and not just the default search.

Thanks! Diana

On Sep 11, 2014, at 9:21 AM, Paul Kilmurray [email protected] wrote:

There is now a dedicated mode for Barcode scanning. You can switch between ‘Search’ mode and ‘Scan Barcode’ by clicking on the button to the left of the search field.

— Reply to this email directly or view it on GitHub.

[piffpaffpuff]

Yes, the separation is very counter-intuitive. It would be better if it was a combined search. Switching back and fort between modes is also time consuming.

[kilbot]

Hi @dgarroway98 & @piffpaffpuff .. I understand it feels like a step backwards at the moment but there is a method to the madness ...

Version 0.3.1 contained an overhaul of the searching and filtering code. The 'free text' search used to check both Title and Barcode attributes but now it only checks the Title attribute. You can filter by SKU if you use the sku: prefix but it will not auto add to the cart. See this post for more examples of filtering by attribute: http://woopos.com.au/docs/product-searching-filtering/

The reason I removed the Barcode attribute from the 'free text' search is that this means the algorithm has to do an extra loop through all the products and variations to check for matches .. this is an approximate 2.5 times the calculations. If someone has a large store with a lot of variations they will be doing a lot of extra cycles for a feature they might not be using.

I made a decision that it is in the best interest of 80% of the users to split the barcode search from the 'free text' search ... but fear not! I do have a solution to make it easier for barcode scanners.

Most barcode scanners allow you to set a barcode prefix. I plan on introducing HotKeys into the next version of WooCommerce POS so it will be possible to use the barcode prefix to trigger the Barcode Mode HotKey which will then switch modes for you automatically.

If you have any feedback on the use of prefixes with barcode scanners please let me know.

[piffpaffpuff]

Thanks for explaining this. Performance is really the problem here. Maybe you could improve the discoverability with an interface change? Add a little triangle to the icon or add a title to it?

BTW: Some clients also had issues with variable products: when they were in a variable product tab (ie. Pants Brown) they wanted to search for a new product (ie. Pants Blue). For this they had to first close the tab or switch to the "All" tab or clear the whole search field text. I think it would be faster and more intuitive to directly jump back to the "All" tab when the client changes the search text. Don't you think so?

[dgarroway98]

Hi Kilbot,

Thanks for the details in your response. It helps to know your reasoning behind the switch.

I have to admit, I'm not a fan of the idea of the prefix for a few reasons - a) I'm guessing there is no "auto-switch" to go back to text search from barcode mode, so it is still a manual switch. b) I have no idea if my scanner has a prefix mode and I assume this extra set-up step will cause both you and your customers headaches in the long-term c) why complicate something that doesn't need to be complicated at all? A single search mode is super simple.

Performance - so critical I agree! There is nothing more embarrassing than having a customer in front of you ready to pay and your system is slow producing the bill. However, I missed your logic on how a barcode search is slow. The way I see it:

a) create hash table of your barcodes when loading inventory (since you are caching all inventory anyway this should be easy) Then during search: b) if hashFunction( search-term ) is in hash table then return c) else search title for name

Step A is O(n), but since it fits into your inventory load step and you are already stepping through each product it is of zero consequence. Step B is O(0)...as good as it gets and no punishment at all for non-barcode users. In fact if your hash table is empty then a simple flag could even bi-pass the hash table and head directly to the string search.

Even alpha-numerical barcodes (which I assume are rare), can be dealt with in a hash-function and the memory usage is next to nothing.

Please correct me if I'm missing something here!

[Vellimack]

Hi All....

Is there anyway to rmeove the option of using the sku: variable when searching for products? Staff would have to type in sku; everytime, which could be very time consuming.

Thanks a lot Garth