Unfortunately another “bug” was introduced by the fix
Assume I have a product ‘A’ with Barcode 841427351002.
If i scan barcode 841427351 product A will be listed. This should not be so as the real barcode is 841427351002
The way to address this is for ERPNext to require a enter key (also called carriage return) after each barcode. In other words for a product code/description to be seen as completed the user must tap the enter key.
This will not be a problem when using a barcode scanner because all barcode scanners are programmed to add a enter key after each scanned barcode.
I noticed in your screen shot that you did not have a customer listed in the customer field. When there is no customer, you should NOT be able to add itmes to the cart anyway.
Also it is probably NOT the best idea to have the POS screen try to fix the issue. It is better to have the user program their barcode scanner properly. When you use a barcode scanner you can program it to simply scan the characters and place them in the field, or you can also have the scanner add and Enter key to the end of every scan, or a Tab key to the end of every scan. Almost all new scanners that you can buy on Amazon or Ebay come with the Enter key already programmed to be appended to every scan. So, if you “fix” this in the POS interface you will probably cause everyone else that is using a scanner to have problems when they update to to your fix.
I really think you should not try to fix it in the POS UI and instead have the user program their scanner properly.
ERPNext PoS does not recognize “enter” or “return Character” to list the items on the invoice item field. I tested this with a programmed bar code scanner before I raised the issue.
The way to address this is for ERPNext to require a enter key (also called carriage return) after each barcode. In other words for a product code/description to be seen as completed the user must tap the enter key.
If you are hitting the enter key to get it to work after the scan, then it sounds like the scanner is either missing the enter key at the end or it is sending the characters too fast for the POS UI to see it.
It works perfectly in my location, so I am lost as to what is happening for you. I only use POS in Online mode with version 9.
It was NOT working BEFORE I raised the issue, that is why it was possible for me to have the item search without a customer name listed. THEN the system would not try to list the item on the invoice, you would have to click the item.
The NEW PROBLEM is that the POS is not using the full barcode to identify the product, so if a barcode is 123456789, scanning in a code with 123456 will bring up the item 123456789 or all items with 123456 as the first 6 digits.
I thought all POS barcodes had to fit an agreed upon standard. So here in Australia you have UPC-A (12 Digits) or UPC-E (6 Digits). I have come across one retailer that had created non standard barcodes via their POS Accounting package. When they migrated to a new POS system we had to program the scanner to add extra zeros to the end of the non standard barcodes created by the old system which worked. In the end the retailer went through and updated all of their stock to UPC-A standard over a few months.
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.
@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.