Bar Code Scanning Behaviour at PoS

It is not a NEW problem, that is actually the EXPECTED behavior. The search function of the POS screen has always been about narrowing the field of candidates to select items from. In previous versions it would literally do this on a per character basis as the characters were typed. Recent changes to the search function allowed additional fields to be included and faster searching.

The faster searching was done to allow better use of a barcode scanner, but the enhancements to the rest of the search function was done to allow a user (cashier) to still type in descriptions and have the ability to select the right item from a very narrowed list of options based on the characters typed into the search box. All search functions (including barcodes) will follow this protocol.

By allowing the description search in the same box as the barcode search, you are going to be stuck with the search narrowing function. In β€œmost” real world retailing areas the barcode has both a standard format and length. So, in most cases you should not get only 6 characters of a 12 character barcode.

Your implementation may be different, but it helps to understand how the system was designed. In order to have all of the current functionality of the POS search function, the partial search feature is going to be there and you have to plan your usage around it or in concert with it.

Hope this helps.

BKM

1 Like

How can we apply single fix in production server

:grinning:

@rohit_w we are using pdf417 (2d barcode) which contain multiple serial numbers separated by space or | or lines. So if there are multiple option to convert above strings into lines it will be amazing. Also an option to delete the first line; which usually contain the carton unique barcode.

@gsbaig I think the fix has already been merged so running bench update on your production server should do the trick. :smiley: