Hahahaha @H_N it’s a big world! You trust, but you also secure!
@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.
It’s all about the speed; its just the speed… previously If you put a matching barcode by typing; it gave you just a brief second after you stop then it entered the item in the grid. I can’t explain it; it was just so efficient; the never got one complaint!!!
@ganas, I will explore qz, seems interesting. But, but there’s something I have to drive home, forgive me; no matter what we implement for silent, direct printing; for online pos; if that print button stays then another print can be initiated for the just submitted invoice. The perfect solution will be to just dump a new invoice on clicking print and clear the screen. Perfect.
I think there is a py module already exist httptocom which transfer http request to com ports (printer) in github.
Thanks @bkm, all good; I’ll try that; but I think they’re settling into it; I left there around noon and no issues up until my replying this. The errors were the few, one came due to % sign being in some of the item names I believe, like a drink called Chivita 100% juice, I think they were somehow interfering with the % wildcard used in erpnext. Then valuation rate enforcement which we sorted by setting allow zero valuation default to 1 in sales invoice item. Theyr also learning to manage the search issue and I just made sure they start printing barcodes, period. They search too much! In v6 they were fine but that also is a waste of time for the customer.
Yeah, that is actually pretty close to how it works now. It is the “continuous search” function. It was built into every search function in ERPNext. It simply takes whatever characters are in the search box and runs with them. No need to tell it to act with an enter key or tab key. You are right. It is very efficient but I believe it may be causing some trouble for @olamide_shodunke. I hope to dig around in my developer notes to see if I can find something to help him.
BKM
lol, its the speed thats off this time Sir! its too fast, just the speed. I dont remember clearly but I think someone recommended he needed to scan as fast as possible, thats the issue, since this field is for human searching + barcode scanning, it shouldnt be tooooo fast for one to type and make a useful search. I still feel it working just extremely fast to be usable for accurate and error free checkouts as we used to have.
Very well. I will dig out my old notes (past revisions) and add in my new notes (what I have with developers right now) and see if we can find common ground where we can pool our ideas and resources to get even more out of it.
I guess I am going to have to figure out how to setup a group of some sort.
BKM
Go go for me… thanks.
Sorry to bother, just something I’m thinking, which you may ask the devs, it also appears the cache is at work to enable that kind of speed, like some buffer, because I really see some evidence of caching on the online pos, quietly holding items, am I correct? It may seem that the code hasnt changed much but because its fetching from a local cache and not searching the server in real time always, it becomes unusually fast. This is good, then let’s consider a search field for the online pos that queries the server for searched items typed in. Do you remember v4 something like that! No Loss; will be perfect; barcode(buffered?) and search field(live) separate! best of both worlds
UPDATE: Reason I think theres some caching is, POS is snappy then for a few seconds at random it just freezes, and then races. could that be when it refreshes?
I believe it uses “some” caching functions, but not the way it used to in the offline version. I think it only loads up the items database to make the searches fast but when it tries to load an item to the cart, it is actually checking the live database online to see if there is enough stock to support the sales transaction. That is why the colored dots are there now on the cart side to indicate sufficient stock. So, not all functions are operating out of the browser cache, just the item searches and building of the cart. I think everything else is live (when in live mode). When in offline mode, it goes back to the something similar to the version 8 method of POS running.
BKM
ok, that confirms it, and its fine, now please add a no caching item name, code, description search field to your notes pleeeease, so its searchable by humans, let it give that brief moment… just like how you can set speed of double click on windows or mac, just that, that field should be at human speed lol.
Lol! 
Sorry I’m just getting around to replying messages on the forum, it’s been a packed weekend but a glorious one 
We are still looking forward to being able to implement proper controls here but in the meantime, we’re managing it by enforcing barcoding and labelling of all items so that there’s something for security to cross-reference. This is easier for us because of the types of products being handled (Electronics, Devices etc). For general FMCG it’s more of a challenge
I believe these discussions will yield some positive fruit very soon and I’m also following up with the issue already posted by @noetico on Github
Cheers!
Well, there is no “throttling” mechanism in the code that I am aware of at this time. It pretty much runs at the speed of the processor.
I must be missing something here. I do not get why you would want to slow down the search mechanism. Is it misbehaving in some manner? How is the fast speed become a problem? Pardon my ignorance here, but even if it seems obvious to you, I am still missing the point. Very much like why I still don’t understand the issues with reprinting receipts.
Please explain how this fast speed issue has become a problem. (Sorry if it seems redundant).
BKM
It’s not really a problem, I love the incredible speed, but I also think we need a separate, no cache search for item names and description. Please note my focus here is online pos.
Ok, let me try to explain; like in v6 where we were coming from, I have been involved some way or another with implementation at over 18 business in different places for say 2 years+ now, that’s over 300 cashiers over the period because I know some shops who keep cashiers 1 month; I have never got a complaint about the search, everybody just loves it, I tell you again, some cashiers are comfortable with v6 pos in under 2 minutes!!! It lacked a few things like split payment or touch friendly buttons but we have never needed those, most people can’t even afford them here.
if you type in a search it just smartly pulls in the info; if what you entered is a barcode; you see it roll into the cart, but you know what; it gives you about a second; its natural, very human yet efficient with the scanner, you don’t think; you just do it and it just works; extremely well. The speed of this v9 makes you jittery about searching items!
Now; I think because of the caching; and maybe some buffering which I know was requested somewhere so that the user doesn’t go faster than the scanner; the buffer is now caching items, so when you type; anything that matches just rolls in before you even see it! I saw it myself; I even helped a cashier, I was trying to enter an item barcode which wasn’t scanning due to damage, and I had 2 unwanted items roll in before I finished; also I even suspect it’s trying to match item codes because sometimes the item that comes in is very different from what you typed. I think I need to send you the link to my db so you can use it to see these behaviors on a host of items; you can create an item listing report and just use some items to search the pos.
Hello @wale true, your sector is way easier to handle and secure. Matter of fact; some in electronics business give a4 receipts in multiple copies, signed and all. You can even do highly detailed inventory with focus. Retail is a lot more chaotic, you have a similar set of items with no barcodes, no brand names, nothing, then various people working on them at different times. Some make it to the shop once and never again… another similar one, different supplier different price, debuts. You have them named as per what the current user feels like; for instance, ‘red plastic kitchen spoon’ and creates an inhouse code, months down, another product comes, different inventory guy calls it ‘cooking spoon - red’. Carelessly, n barcode is printed; cashier struggles to decide! All this, combined with negative stock; because If neg stock Is always off you can see what is out and what’s in use. Sometimes both are in stock, but no codes on them, cashier searches, and can’t decide; well she picks any; and stock issues propagate. Do you get the picture?
Sorry, posted incomplete message, please re check.
Now this topic got really long and redundant and not much of a help. Someone should go through it and summarize it in main short pullet points maybe in a new topic. In the future we should stay focus, write things in short focused paragraphs.