@bkm, your points about the browser caching may be the very reason why they should decisively remove.
Now let me tell you that I have over 6 retail clients with 10k+ items running the v6 pos!!! 3 Of them hbe close to 21k items and almost 2 years worth of transactions that are checked in time during sales and the pos module is still fast enough.
For barcode scanning speed, i dont see a problem and theres no need for over paced scanning. From experience; the cashiers even like to see that what they just scanned was loaded into the grid! infact we have edited the pos.html and pos-bill.html files using a transform so the last item scanned is on top because by popular client demand; the cashiers want to see the last item scanned and see it on top! (in v6).
All these clients are running fast and you know what! they are mostly installed in a vm with around 2gb of ram average and 2 processor cores max from the host, matter of fact over 10 installations have just 1 core from the host and they use the pos and even love the simplicity and speed!
Caching should be dumped. Pos module was good without caching and month after month, no cashier shorts and overs. Its just perfect asides the absence of split tenders.
Kent@Live Mail. its official!
I’ll also state my opinion on solution. Offline should be removed from the browser.
Spot on, its erratic i agree. And i second on the move to remove the offline and revert to live pos only.
No to idea of removing the offline pos.we have great need of it.few problems that are in it now will be overcome.
Okay, I think I see the divide here between those asking getting rid of the use of browser cache for ‘offline’ POS sales, ad the developers that tell us the browser cache is very important to the POS system.
The real problem is a lack of understanding about exactly how the browser cache is being used. It is not only for the retention of sales that occur when the internet connection drops. It is apparently also used to attept to cache an entire quick reference table of all of the products/items in the database to make the right side of the screen where the items are displayed to populate faster and enable that endless search routine to operate when looking up items to add to the cart. The more items/products you have in your database, the more the browser is stressed to house the lookup table. Now add to that the need to keep track of online vs offline sales and it may very well be the browsers ability to manage it’s cache that could be causing some of the problems.
I personally really dislike the ‘endless search’ routine they use on the item grid in POS. As long as you add another character to the end of the search string the routine keeps trying to narrow down the displayed items in the grid. It is because of this action that the POS system cannot buffer barcode scans. This creates a condition where a good cashier will lock up the POS modle because the search routine cannot process the scanned code fast enough to clear the searcj bar and then next scan is accidentaly appended to the first one in a long string that the search routine cannot resolve.
Anyway, I get why the developers do not want to abandon the browser caching scheme. They depend on it for too many other functions. That over reliance on the browser cache may very well be the root cause of all of our POS problems. The developers have passed far to much responsibility for the operation of the POS module to a 3rd party cache manager that they do not control the code base to fix it. So, unless they write their own browser, I am not sure they can ever promise us a good POS module. I may be wrong, but I noticed that the more item I have in my item database, the more erratic the behavior of the POS module. I have a database of over 3000 items. At first I only imported a small portion (about 500 items) into ERPNext for testing. Later I bumped that up to 1800 items and the erratic operations increased. When I porting in about 3200 items, only 1 or 2 transactions in 10 would post properly.
I have already committed to spending a lot of money to generating a fix to allow a way to buffer barcode scans and let the system catch up to the user when they encounter natural pauses in their checkout flow. Now that I am alonst finishe with the scan buffer fix, it looks like I am still not going to be able to use the POS module. businesses cannot rely on their cashiers to go check if their transactions were all submitted properly or to take the initiative to force them to submit if they build up in the queue. It is the fact that transaction ‘appear’ to work properly but actually do not complete the submit process that will cause bad publicity for the whole ERPNext project.
What business owner would want to risk having their inventory numbers to get our of sync because the POS system is not completing the process? What happens when a cashier closes out their shift and powers down the device they use at the checkout stand? All of the buffers are discarded and the transactions caught in the hidden limbo state NEVER get into the system. I cannot think of any business that want to roll the dice on such a POS system.
To be fair and complete here, I am doing all of my testing on the latest ‘production’ version all the time. I have been dumping my system and rebuilding with a fresh production install about every two weeks now since the ERPNext version 8.0.22. I have never been more than two weeks out from the latest release production configuration. I dump the ENTIRE system lately because I found how to reinstall everything including he Debian operating system ins less than 30 min (using GCP and ready made OS images). I cannot see any purpose in testing with a developer configuration since I need production ready system for training the users and writing the documentation the users will depend on later.
I am not happy about spending so much money on fixing one ridiculous problem in POS only t have another even worse problem gt in my way again. I cannot put my clients on the POS module here with it not processing transactions!!! I am very disappointed that such an important module for small businesses is getting such little help. I still believe it need a complete rethink, rewrite, and redesign to make it work in a reliable fashion. Some small businesses only use POS to make their money. How can we continue to allow this module to not post transactions?!? This does not seem like a very good way to attract users. If they cannot trust the system to track their sales and inventory through the POS module, then why bother at all?
At this point I have no idea how I am going to complete my task to get a working ERPNext solution installed and switch everything over from our old ERP system. Too much of the business relies on the POS module for the income side of things.