Was your sales person going to make deliveries at customer site? Or after he returns from his rounds? Either ways you can turn on the Update Stock by default on the invoice. And put the default value of the sales person’s Warehouse in the Warehouse field.
Sure, we will build the app to support other languages, but we will need your help in the translations.
Thanks
Jay
You may be surprised to know that the developer group I used to make my customizations is already part of the ERPNext foundation and I specifically asked them to do pull requests for everything I have them create for me. Many of the improvements that have happened to the POS module in the past several months are directly tied to those pull requests.
I do all of my modifications this way. You can probably figure out the team that I used if you look back at all the PRs on github. I like them very much and even as I write this I have them making even more customizations form me.
Sometimes the modifications do not follow the path the foundation wants for ERPNext so they are not merged. Sometimes they cause arguments in the community and they do not get merged.
One such modification that caused a great deal of arguing was the ability for the POS user to print a draft invoice BEFORE submitting it. Everyone cried foul and fraud. But if a situation like I described above it becomes a super useful tool. The drivers can print out a DRAFT invoice and take into the customer/manager responsible for payment. If they decide the total was too much for their budget, the sales rep can easily remove the item from the cart and reprint again until it reaches a level the customer agrees he can pay. Once it is signed, the sales rep submits and finalizes the sale. Until that time it stays in draft mode and can be modified.
You will probably never see that feature show up in the POS module even tough I have already paid for it and made it available to all. It just sparked too much argument from people that didn’t understand how to use it. They just didn’t understand the concept of DRAFT. Draft invoices never update inventory levels or accounting. So unless it gets submitted, it never matters. I even added a check box in the POS setting to turn that feature off or on at the administrator level, but it was still rejected.
Believe me, I try to donate everything back, but sometimes the ones the do not understand the system make the most noise and the merge doesn’t happen.
I was not-so-voluntarily volunteered to be the Module Volunteer and coordinator for POS and I still take that seriously and fund it when I can. But I will not try to argue with the ill informed. it is a waste of my time.
So, to your original point… I have actually attempted to donate ALL of it ALL the time. That is how I prefer to work with ERPNext. I will always do the same with my customizations whenever possible.
The only times it may not be possible is when I ask for custom work to go into older versions of the system. Then the code is usually too far behind to be of use (but I still ask them to try 
).
BKM
You set that up int he POS profile of the driver.
BKM
You can do almost everything you want without a custom app. See my detailed description of how to use the system above.
As for using a device with a printer built it, that would all depend on the operating system of the device and the available space. Not everything with a built in printer will play nicely with ERPNext since the system operates from a browser. We did get android to work with a wireless printer.
UPDATE
Printers built into devices are usually the thermal 52mm or 80mm wide paper type. You will want to do a great deal of experimenting with those sized printers before you commit to them in a all-in-one device. ERPNext does NOT work very well with that size paper unless you take great care in actually modifying the source code. Everything ERPNext prints is usually in the form of a PDF document. The PDF generator in ERPNext will build in some fixed sized borders for the right and left sides of the documents to print. Those fixed borders are also in the docs sent to thermal printers. So in the case of a 52mm wide printer, the 18mm wide border of white space on the right and left sides forces all of the printing to happen in the remaining 16mm of space in the center of the paper (or the remaining 44mm in the center of a 80m wide printer). It is not easy to get thermal printers to play nice with ERPNext at this time. If it is something you must have it WILL REQUIRE A LOT OF CUSTOM WORK.
END UPDATE
You can already enable or disable users and POS profiles from the office at any time. Trying to do it at the app level might prove difficult or expensive.
Monitoring max cash to be carried will definitely be a custom thing. There is no provision right now in ERPNext to handle that. My clients do it by making the drivers either do 2 stops a day at the bank (regardless of amount) or for those that have few cash sales it is submitted at end of day with invoices.
BKM
Why do I disagree so much with this message?
Must be the overtly sanctimonious tone.
Regards
Chill, guys! It’s tough to achieve consensus. Which is perhaps the reason I disappear for weeks together from this forum. 
I know its tough, so I appreciate every small contribution.
But what BKM brings up is a good point. I will hijack his point to the following:
What is core?
What are nice to haves?
What are peripheral features?
Plus it is all context. One man’s core is another man’s peripheral feature.
Can we enable all? Where do we draw the line? How do we still accommodate a feature that is non-core to most but extremely important to some.
Let’s please keep the discussion on broad concepts. Let’s not take offence or get personal.
Thanks
Jay
I think an apology is in order before we can proceed
Agreed. I made the custom stuff I wanted and made it available to the community. They disagreed with my concept and it didn’t get merged. So what? I got what I wanted and I offered it up. Everyone is still happy. As long as my clients pay me for the modifications I don’t care if they rest of the community likes them or not.
@olamide_shodunke I am not here to preach. Just to point out how the process works. Whether that is good or bad is all up to the viewer perspective.
BKM
Ok. I am sorry if I offended you. I am not sure how I may have offended you, but that was certainly not my intent.
I was only emphasizing the extremes that seem to occur when an idea is presented.
BKM
That right there is the beauty of ERPNext. If it is not core but you must have it, you can always make it work with modifications. That is exactly what I do every week.
BKM
The Solution is to make most of the features optional.
Take for example the PoS profile, over the last few months the options available have increased
I am still working with the ERPNext team to add about two more options here.
For ERPNext to be useful to all, this should be the adopted approach, once a use case can be made for a feature it should become part of the core albeit optional if it has two sides to it.
That is my two cents to this.
If you are able to help @Fred1 with a solution to his desire for an all-in-one deivce with the built in printer, please consider making the printer part of that available to the core as well.
Currently ERPNext doesn’t do well with thermal printers unless you are willing to modify the code directly on your server. I had to do that on mine to get the 80mm printers to work up to their potential.
If you solve this issue in a more generic way that can be applied to the core, that would be a real benefit to most POS users.
BKM
That is true. My custom version also has the check box to turn on Allow Print Before Pay. That was a direct result of my Pull Requests. Glad to see it is in the standard version now. In my custom version is is actually called Allow Draft Print before Submit.
I hope to see several more options appear here for the POS users.
BKM
@bkm if i understand Mr Jay very well,what he is trying to develop is an app that will be standalone on android device and sychronise with the ERPnext.So i don’t expect it to be a heavy app.Once install directly on an android hand held device i believe it should be able to print directly from the inbult printer.The printing directly from handheld device is a very major breakthrough i have been searching for more than one year.So @JayRam kindly take into considerations all the design information i mentioned in above post particularly the direct printing.I will be willing to contribute to its development.Thanks.
Ok. Pardon my misunderstanding. I am so used to trying to make everything fit “into” ERPNext that the idea of an external app was not on my radar. If you can get that to work then it may be quite fast since it would not rely on the ERPNext structure to be running.
Good Luck.
BKM
@bkm you have not offended me at all.Who knows whether i am the one wrong in my perception of what Mr Jay has in mind.
@JayRam Kindly clarify us.Is your app a standalone that will sychronise with erpnext or just an extension of erpnext,will it be installable on android devices?
It is an Android app and will use Rest API to work with ERPNext. So while the app will have simple interfaces, the transactions will all happen on ERPNext on the back end. Hey! This is an ERPNext forum. We HAVE to use ERPNext, right? Or move this discussion elsewhere.
A future version will be able to do transactions with a local cached database. And synch up with ERPNext when the device is back online. Though you need to worry about security if you allow this. Like if the Driver makes deliveries on cash by deliberately going offline but is able to provide a printed invoice and then clears data on the app before coming back online, we may have a situation on hand.
Thanks
Jay
So in summary the web page of sales invoice from the erpnext will still be what will be printed.Ok
This was perfect for me …I thank you alot for the enlightenment… i tested it and everything looks great except for one matter, Credit Sales (Sale on Account) … i tried setting up Credit Sales in the POS Mode of Payment, but they system didn’t allow me to link the credit Sales with Debtors account (Accounts Receivable) … how are you treating such matter?
For us… Sale on Account is actually where we give the customer 30 day terms. We created a separate mode of payment for this and called it “On Account”
Credit Card sales are considered Bank Transactions. Our business treats them as CASH sales. So the account we link to is bank account like a check would be linked. We have a merchant account for the credit card transactions and the money is immediately deposited into the bank account. We let the accounting department handle the monthly G/L entry for the transaction fees separately. The drivers can access the credit card approval service through their smart phone and they are required to put the card transaction approval number in that extra PO field we had added to the POS screen. The cannot hit the SUBMIT button until they get the approval on their phone from the credit card processing site. We handle all credit card transactions outside of ERPNext because the system doesn’t have a good way to handle card readers at this time.
Our accounting practices are a little different because we have a 3rd party accounting program we are forced to use so do not judge your work on how we do things here. Your accounting will be much better if you stay within ERPNext.
Glad you were able to use the information about how to manage mobile sales reps. It is not the easiest thing to figure out. We had many mistakes along the way until we settled on what I laid out for you. I can’t imagine doing it any differently now.
BKM