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 prinât 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.
Please lets just see how we can solve these little issues: how come we had no issues in v6 search? cashiers were trained in under 120 seconds and were able to sell thousands; then yesterday and today I see even the best cashiers struggling with items. It was so much pressure for me. I got a call at 1.20am from the shop owner as he got reports o queues!! I was there over 12 hours yestrday and about 4 today.
whats the point of hiding the printing button if the user can change the number of copies in the printing dialog. and btw, this is seems to be a problem for big supermarket type retail. In other retails that I worked in, this is not a problem. So excuse my ignorance when I said earlier why prevent multiple prints, but again you can only solve this problem with node print or QZ
Indeed, its a problem for big retailers; a lot happens. Please read carefully the 2 : We can use seamless print or as @H_N shared @System19 's post, silent print. Once the print is hidden after first click, then one copy prints with no dialog and a new invoice awaits, I will share images of this in action⌠we implemented this in v6! It works. My only fear is the new pos may not load in firefox 45
I really WANT to say that I agree with this statement. In fact I originally set out to remake POS in that very functional path, but there were complications that could not be overcome. I do not remember them right now but I will go back to my conversations with the developers and see if I can pull out the parts about why it was a problem.
I do know that the developers also felt it to be very important to keep what I called âcontinuous searchâ function they natively built into just about all search abilities in ERPNext. That function essentially searches every possible combination of the data dynamically even as the keys are being typed. Just about everywhere you go in ERPNext and use the search bar ( I believe they actually call it their âAwesome Barâ ) you will find the search works in the same manner.
I am thinking that to change how search works (like requiring a trigger key of some kind) would then screw up how search works everywhere else in the system. I think they are using the same code blocks everywhere. I will try to find the answers in my past developer conversations for you. Then maybe we would have more data on which to base a new desired behavior.
BTW⌠if it seems like I care more that usual about how to make POS better, it is because I have spent the past 4 months financing improvements to it. I have many clients asking for a solid POS as part of their business systems upgrades. It appears that I am also being asked to lead a module group for POS improvement as part of the foundationâs new path of focusing on modules. So, kicking and screaming and fighting against it, I may soon have to give in and try to move this module forward for all of our interests. I am certainly lacking all of the normal characteristics one would want in a module leader here, but until someone else can step up, I might have to do this just to keep focus on POS and try to get things done. I am not a developer, a coder, or even a good github user, but I cannot stand by and let this important chunk of the system go ignored either. So I have to think long and hard on this, but in the next few days I may have to set up a thread (or groups of some kind) specific to POS improvements. If I have to do that, would you be an active participant in such a group effort? PM me later about it.
Canât you customize the receipt to show it as a reprint if the posting time say is more than 15 seconds from the time of the print? This should be quite simple to do.
On another note, what happened to trusting your employees? If I canât trust my employee, I would show him the door. Having said that, control systems need to be in place to ensure that employee theft is minimized. Can you tell the difference between theft and incompetence? Both cost you money. Manual and automated control systems are designed to catch these. Review your cashier controls.
@bkm erpnext search is perfect! I tell you, up until v6 which is the highest I used; the search in pos was flawless. Check with them; something has changed and it looks to me what it is; is just the speed! It doesnât need to be too fast for a human to make a reasonable input. We used the v6 in this big store and it was good until it got too large.
I also wish I could support right now; aând I will. Most of our clients pay between 100 and 500 usd for a whole implementation and you have links to sort commissions, data entry people to pay. But itâs good; first Iâm growing my base, thatâs why we need the product to be good; then we get rich clients and we can put more than coffee in the devs cups! We will get there!