I have been trying to start up the POS module for my client that has 2 stores with 3 cashiers each. The performance of the POS part of the system very slow.
The cashiers have Andriod tablets for their screens and bluetooth barcode scanners for each check out station. To make sure we were not experiencing problems with the Andriod OS we also replaced one station with a Windows 10 touch screen PC, but the problem was still there.
When the cashiers scan an item, it was taking up to 3 seconds for the item to be added to the customers purchase list. This was when we only had about 2000 items in the test database. We went back to the “Item” information in the system and eliminated all of the item pictures so there would be less data to sort and load. Now it takes about 1.5 seconds for the scan to register to the customers cart. This is NOT in any way the fault of the scanner. I can also type the barcode information into the search bar quickly and it still takes the same length of time to find and post the item.
To make matters worse, the POS module does not appear to have been designed with barcode scanner use in mind from the beginning. Even a slow cashier, using a barcode scanner will get ahead of the “search and return” script that the POS module uses to populate the sales ticket. If you scan more than 4 or 5 items in less than 7 seconds you will overrun the POS feature that populates the cart. The search bar above the item grid of the POS screen will wind up with multiple sets of barcode data in the same line.
It seems to be the “open ended” search function that is at the root of the problem. The open ended search appears to work similar to “predictive text” in a smart phone. As long as you continue to add characters to the search bar it keeps trying to narrow the search. With this kind of design, there is no end point for the search mechanism to be able to know that new characters coming in are for the NEXT search. Because of this there can be no buffering of searches.
When using a barcode scanner on any other POS system, the system will buffer individual scans in case the user gets ahead of the the processor trying to populate the cart. In other systems, the buffering allows the system to catch up to the user. The open ended search does not allow for such features and therefore slows everything down.
Here is a screen shot of what happens when you get ahead of the search bar with a scanner:
You can see in the search bar there are actually 2 sets of barcode data. All of the barcodes in this case start with ABC followed by 5 digits.
Other systems are able to use buffering because they can accept a control character as the marker for the end of a search string. Anything that follows the control character is obviously part of the next search code. This is why all barcode scanners have the ability to append a scan with control characters like carriage return, carriage return/line feed, tab, or even escape. The one I am using for testing right now is programmed to add “Carriage Return/LineFeed” to the end of each scan. the ERPNExt POS module seems to ignore those characters though and continue looking for more to append to the current search criteria.
In this way, a cashier can easily find they have 2 or 3 sets of barcode data present in the search bar, because the system could not buffer the individual scans and instead could find nothing. The user then has to stop and clear the search bar, then scan each item and wait for it to populate before they attempt to scan the next one. This is exactly what happened on the very first sale a clinet tried to do in a convenience store. A customer wanted 2 packs of cigarettes and a bottle of water. The owner scanned all three items in a row and the search feature could not keep up. I have tried this at a convenience store, an auto parts store, and a small family owned wine shop. In all three cases the frustration over the POS system as forced them to abandon it and go back to a simple cash register. Then sales have to be entered by hand at the end of the day.
This is not an acceptable POS solution. The user interface needs to be redesigned with a real POS operation in mind. The current implementation simply does not work in most real life POS scenarios.
This problem is not new to this version of ERPNext. It has been around for a long time, but nobody has addressed it.See below:
Does anyone have this on their list of things to fix?
I would have hoped it would have been taken care of with all the changes made during the version 8 upgrade to POS.
Does anyone have an alternative method to make this work better?