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.
If you go to the search bar of the POS module and type in the characters (using the keyboard only) of the offending 9 digit code and do not hit any other keys, the proper reaction of the system is to display both the 9 digit coded item and the 12 digit coded item in the items grid on the right side of the screen to allow the user to select the correct one.
If this is not the reaction you are seeing then I would agree that the system is not acting correctly. However, if the system does display both items in the items grid, then the problem is not in the POS module and is instead related to how your scanner is configured. In modern GUI operating systems the scanner is seen as a second keyboard by default. This is true for Linux, Windows, Android, and ChromeOS. That means everything the scanner sends to the system is just like someone had typed it very fast on a keyboard.
The above little experiment should clear this up for us.
Please, these experiences are crucial to making this software better, let’s not push them back as the faults of the shops; the software must be ready for whatever is thrown at it; and this is how it gets done; when we pass it through the fire; we make it solid gold
Thing is; with all respect; there’s some misunderstanding of how retail works in the real world. @bkm Like @olamide_shodunke has pointed out; look at the facts; no shop has standardized codes all the way; except you print yours; which is simply counterproductive, expensive and tedious. You will have code39, ean8,13, code128, all sorts, mixed up, plus no barcodes. Have you seen household items coming from the East? From bowls to mop sticks, sponges, no brand, not to speak of barcodes.
I offered a database of 1.2gb for any one interested to see what a big retail store looks like, 1.2gb of text only data, no images; humongous data; spanning 3 years, handled by over 20 people at different times in the life of the stock. You are talking 20k+ skus, with over 10k in stock at different levels and in over 30 item groups.
I agree that the item name field as displayed in the cart is far too short to allow the user (cashier) to confirm they have the right item actually in the cart. Even if this means using 2 lines to show the barcode and the separate description field (or at least most of it) on the cart screen.
I believe that definitely warrants a rewrite of the cart screen.
I type in a 9 digit code that is exactly the first 9 digit of the product, but is not the product.
if no other product with that exact 9 digit exists, then the 12 digit bar coded product will be automatically placed on the invoice
That is the mischief we are trying to prevent.
In a retail environment with 40,000 skus from 4 different continents, ANYTHING is possible. There could be many reasons why I am typing in a non existing 9 product digit…
I am amazed that people are asking me why ability to print multiple copies of receipts in a fast paced retail environment is not a security risk? With all due respect gentlemen this is Retail 101!
And the bar code behavior issue…this is a no brainer …it is not right!!
This would help! @H_N only problem is, for online pos; the print button sits right there after you print. It should be hidden after the first click. Js should be able to take care of this; or even still hide it server side to harden it from smart guys; this is running in a browser; certain things should be server side; hard core.
Absolutely shocking bro! Shocking! Those shops requiring multiple prints are threading dangerou ground. Someone can walk in, pick stuff, show an old invoice given by a friend, out the door. Its a big world, consider the developing world we live in; these things happen.
Ok; let me fry your brains; do you know people, cashiers, get their own pos pads into shops and swipe cards to their accounts on the shop’s sales!!! A lady swiped worth 3M before she was caught.
The risk of invoice printing needs no argument; I someone from quickbooks or other desktop pos meets us in this debate it will scare them; its n done, if a store needs multiple printing it should be a high level setting not a cashier affair; it should print the number set up and that’s it; 1, 2 o r 3 etc.
Guys there is one thing you need to understand, you are running the POS from the browser so you are restrained by the browser. Limiting the number of prints you can’t ask the developers to do because the browser sandbox you from accessing its internal printing settings. so even if you hide the button as @noetico is doing, the cashier still can change the number of prints in the printing dialog.
How services like QZ and NODE print get around this, the install a printing app on your computer, then in javascript you can use APIs to communicate with the app directly bypassing the browser.
So it is not what you guys want, it cannot be implemented in POS based browser. The simple answer is NO thats why if controlling printing is big priority then you need to use something like print node or QZ and thats why I gave you this link https://discuss.frappe.io/t/print-node-integration-for-frappe-framework/20292 because its the only way you can overcome browser printing.
PS: @noetico I might need you database copy to test the iOS and Android app that I’m working on
Ahh… I see. I was under a mistaken impression of the issue you were experiencing. I thought you were getting the 12 digit item instead of an “existing” 9 digit item.
I am not sure that is easily solved. In theory, if the 9 digits do not exist in any other product, then the selection of the 12 digit coded item would be correct. However if you are just typing in codes you find on a product to see if you are using the correct code, then one would expect to have to delete any incorrect item that might pop up until you find the correct code to identify the item.
If you force the POS module to instead simply display the item on the items grid and take no other action, then wouldn’t that be just as offensive by possibly “missing” the placement of an item on the invoice? I ask this because you indicated the problem occurs with the use of a barcode scanner. If the item scanned only displayed on the right grid and did not populate to the cart, then you would also have the problem of items not making it to the invoice in a busy retail setting.
This seems more like a catch 22 scenario. Either way there would be a problem. What behavior would you suggest in this case that might still allow for accurate and rapid retail use?
BTW… my purpose here is not to cause frustration. I really do want to make sure any POS problems are solved in a manner that speeds up the usage and still maintains the highest accuracy. Really the dilemma is which path to use that best fits the most common situations.
Curious though. What behavior would you suggest and why? Does that behavior have any negative side effects?
Yes; that’s why I mentioned in my reply that you can’t stop it fully; but for now, just hide the print button after first click; then we can try other things in your suggestion; trust me I will look at those. But if you have print again as we have in online pos after printing; then problem still persists
Every barcode scanner can be programmed to add a “carriage return” after each successful scan, this indicates that the digit is complete. This behaviour is standard amongst all scanners.
ERPNext should be adjusted to recognise this “carriage return” and identify items accordingly.
So 123456789> will not be the same as 123456789123> Here I am using the > to represent the carriage return.
When not using a scanner the carriage return is the same as the enter button, so the user types in the digits and presses the enter button to signify completion.
This is the normal behavior in all the PoS I have used, and I have used and implemented plenty.
PS…No offense meant, so long as we are able to understand each other and get a better ERPNext, all is well.