I have no issues with V8 for hanging invoices. Just playing with a test VM for V9, so can’t say for sure.
One thing that I find annoying is that both offline and online modes are not synchronized in the look and the functionalities. Would be great if they are.
@H_N how do you get the offline invoices to submit? For me sync offline invoices just delivers draft invoices, even if It worked; it will not be usable by high volume retailers; mayb only during emergencies, yes; stores can’t depend on a cashier to hit the sync buttons. Sometimes they even tell you they plan to remotely view their sales as it happens in real time; they get that with online pos.
I brought up this issue of barcodes a few weeks ago.
I think I know what the problem is and the team just needs to implement it
It has to do with the “carriage return” or “Enter” character.
Every barcode scanner puts a default return after every successfully scanned barcode set, this is what tells the PoS that the barcode digits are complete. In the same vein when you type in the barcode you are expected to hit the “Enter” key to tell your PoS that you are done keying in the codes.
As configured ERPNext does not wait for or recognise the “return” and just looks for the closest number match.
I may be wrong but I strongly believe if this is addressed the issue will be solved.
I am facing the same issue in a production environment. My only saving grace is that 95% of products are barcoded.
For V8, every time I have a draft invoice sync, i just resubmit it and find out the error message. There is a reason why it stays in draft as not all the edit checks in Sales Invoice are implemented in offline POS. Once that is solved, no more draft invoices on sync.
Ok it’s good to know I’m not alone on this. It’s bad for this current client because they have so many items; so many without barcodes, asides the lot in the supermarket; including shawarma, snacks and confectionery. I just started putting in strong recommendation that they start printin codes.
Ok essentially this is a small number of invoices you can resubmit. For high speed retail; impossible. Yesterday was Sunday and between 12 noon and 7, they had 585 invoices already!!!
@olamide_shodunke You are absolutely right on the enter key; the cashiers expect to hit enter after typing a barcode; naturally; but before they’re done you have an unwanted item in th cart
I also think; if it can be considered; the interface is relying too much on client side codes like javascript, which also depend on browser implementation… correct? I think this is an erp system reliability and simplicity are crucial. Sometimes I notice (asides pos which is faster), compared to v6, other simple things take longer to do on the same db with v9:
Module loading: up to 20s sometimes, 8s average (2 to 3s o v6)
Rename and save an item: up to 23s (1 to 2s on v6)
Save pos profile: 4 to 8s (1 to 2s v6)
Cancel document (15 to 35s)
List documents (sinv, po, pr): 5 to 20+ seconds
It varies so much, making me feel the caching is just getting in the way, the system is fast; these were never slow on v6; now the system in itself feels very efficient but you feel like drag sometimes, making me feel it’s something with scripts and caching.
I posted this on github, cus I’m facing same. If you’re using offline @H_N posted the location; but here’s the bigger issue; you’re printing from the browser dialog so you really can’t prevent it! But here’s something we have tried before:
I can look at the current pos.py for you; in the past, we took 2 steps; we merged the print and new into conclude; so on clicking conclude, you have the print dialog, on printing; you immediately have a new invoice, the old one is closed in the background. Then on firefox there’s a very powerful plugin called seamless print, with it you dont get a dialog, on conclude, seamless print just prints a copy to the default device. No dialog. Neat. These 2 steps is almost 100% secure except that
Seamless print stopped at ~ firefox 45 you can try
Rarely, but a savvy user can disable the addon
So you see; its tough enough printing in a browser then caching… I think people will be willing to pay for pos apps, standalone, or a modified secure version of chromium, who knows, with policies and admin locks so no settings are accessible. Its really hard securing a browser.
I’m also exploring windows server to see if group policies for managing printing can help
Hmm… why exactly is this a “security loophole?”
What is left open to manipulation if multiple receipts are printed?
In some of my client stores, they absolutely want the ability to print duplicate receipts so they can give the customer a second one to use for mail-in rebates while still keeping their original receipt for other items that might also be on the same purchase.
What security issue does this potentially leave open?
This should only happen if you do not have standardized barcodes. If you have some items with only 9 character barcodes and others with 12 character barcode, then there is going to be the potential for the first 9 characters of a 12 character code to be a match for an item with a 9 character code.
In any book on good barcodong practices, this should never be allowed to occur. That is the whole point of the UPC and EIN codes. They are standardized to a fixed length and format to prevent such issues.
I do not believe this is an problem with the system, but more likely a problem with your implementation of barcodes. Standardization is the most important factor in any functional system and the use of barcodes is no exception.
On the topic of the “Enter” key being appended to the end of a barcode scan event, most lower priced barcode scaners come pre-configured in this way. However, all barcode scanners you would want to use in a cashier environment also come with a booklet of instructions for how to either turn off the appended keys or alter them to other keys. Only the cheapest of scanners will have a problem with this. If you are already investing in an expensive tablet or computer to run the cashier station you should put at least as much effort into your choice of the barcode scanner. The low end of the better (more useful) scanners is going to be in the $100 USD range. A small price to pay for reliable service.
The Enter key issue is not the fault of the ERPNext POS module. It is just knowing how to configure and use a scanner properly.
Most top level PoS solutions have this feature standard. The ability to reprint a receipt is controlled by rights and the reprinted receipt always has “REPRINT” written on it.
Most retailers have security at the door that check receipts from customers to ensure that the products were actually paid for. If the cashier has the ability to reprint receipts they can easily collude with customers to take out items with receipts geberated from the system.
This is such a basic need in structured retail that I will just stop here…so many other reasons…return fraud/promos etc
Some if not most of our retailers buy their products from many continents where different Barcoding structure exists. So some products can come with 9 digits and some with 12.
Barcodes are not designed internally.
@bkm why not look into the issue clearly before concluding . I had the same conversation with you on another topic and I just let it go as I did not want to argue.
The current scanning behavior is not normal. Period.
Not just the above issue, but several of the issues you have raised here are starting to look much more like database problems caused by the upgrade. The database schema has changed multiple times and the errors you are experiencing are looking more like disconnects or mis-connects that were not resolved by the upgrade process. This may also account for your severe time lagging events. I am not sure you can effectively track down every change and repair it after so many version level changes all at once.
I have not seen such severe lagging in my 3 store implementations and they are all running on Google Cloud Platform. If I remember correctly, you are running on local servers so I would think you should have much better response times than my cloud servers. For my largest retail client, I run 3 stores and 7 mobile sales reps on a single 2.9ghz CPU virtual server with 8gb of memory. Only on large database reports do I see any lag, and that is usually less than 7 or 8 seconds. In total the stores and the mobile sales (also using POS module) total about 450 to 500 transactions daily. I know this is lower volume than your system, but my cloud server is also much less powerful. I used this same configuration on all three of my retail clients running version 9. The largest client is the one mentioned above and the other two are single store fronts.
Just as an experiment it might be useful to export all of your live data one weekend, and them re-import it to a fresh version 9 install on a sandbox system. Then experiment with that to see if you have the same lag time when doing some of the same functions. The export/import path takes the database issues out of the picture and relies instead on the system to populate a fresh database with the CSV files you generate. Any fields that are either required or not populated correctly will also be exposed in the import function. This may further your investigation into the lag issue by shining a light on where the upgrade process may not have been complete enough. I did this in my transition between v7 and v8 to find that my databases were not optimal after the upgrade. I instead used the export/import model to create a better system for the client. The real loss on this path was the ability to properly see the historical data trends from the older system.