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.
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.
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; and 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!
@olamide_shodunke I once had @bobzz_zone try to implement something like this; I think he could achieve it only after a day. It’s worth looking at again.
What we came up with was the invoice was blank after the set time; he put a simple if clause; few seconds work; and it rendered a blank invoice outside the time. Very simple solution. I think someone can offer us code here.