Hi Ganas,
This is great stuff. Couple of things that I believe are essential for POS terminal:
- Sales Returns
- Exchange
- Loyalty Program: Sign Up, Registration, etc.
What will it take to add those stuff into your POS app? How can I help?
Thanks
Jay
Hi Ganas,
This is great stuff. Couple of things that I believe are essential for POS terminal:
What will it take to add those stuff into your POS app? How can I help?
Thanks
Jay
Thanks for your input. I’ll to include them in the design along with idea of her receipts.
For now I’ll work on designing the interface based on the inputs I get. Then i’ll put a prototype on invasion so we can get specific comments and usability test. After everything is agreed on I’ll post it up on bountysource.com and if anyone wanna help he can chip in on bounty source
How is this going?
Sorry I got little busy with work, I’ll try to finalize it this week, I’ll post the updated mockups soon
Hi there! I’m really interested in these ideas. Are there any news?
This would be a big step for the POS module. Any updates on status?
Great idea
Sorry for not updating this in a while. Here are is the design I came up with and looking for you inputs as I’ll finalize it and start a bounty to implement it. In the design the goal was touch screens first, so i avoided any typing or message boxes and notifications and used tab approach.
Here is a link for the design:
poserpnext.bitballoon.com
and here some screenshots
http://2.1m.yt/_DuqrwS.jpg
http://2.1m.yt/jcf9vEj.jpg
http://2.1m.yt/tfKvVgj.jpg
http://2.1m.yt/SCva-HR.jpg
http://2.1m.yt/AKeglFh.jpg
@ganas
Wow! Looks great!
I really like how you used the tabs approach. It looks much tidier.
I added some suggestions for modification to simplify it a bit and speed up the work flow.
I hope it doesn’t seem like I’m nagging because it looks like a lot of inputs. I really like your design and I would really like to see it in ERPNext!
On a tablet you would use a screen keyboard. This would cover most of the form. Maybe it would be better to have a “New” button by the search field and then use the whole screen for the form+keyboard.
A customer buys two cokes: You press “2” “x” “coke”
You want to give the customer 15% off: “1” “5” “-%”
You want to gibe the customer 2.00 off (this possibility is missing): “2” “00” “-”
You want to change the amount of a previous item: select the item and use the number keyboard.
Fiddling a slider to the correct number is less practical!
I would put a traditional POS number keyboard with “00”, “x”, “-”, “-%” and “delete” buttons
Instead of the “x” as delete button I would use the “garbage” button for consistency.
You also need a possibility to give discount to the whole and to part of the cart. The traditional way is a “subtotal” button but maybe there is a better idea.
Isn’t there a better possibility then a dropdown list to select a category on a touch screen? (I don’t have a better idea either.)
I really like the Paymernt-tab! Simple and efficient!
I would add a “00” button to the number keyboard. Entering 100.00 is much faster with it.
But is the Summary-tab really needed? Couldn’t you just add a big “Finish” button to the Payment-tab which does a predefined process (like printing the receipt).
You could also put some smaller buttons to do different things (like send the receipt by email or delivering everything by mail). If you then need more information (like the email-address), you could be send to the Customer-tab or an other tab would be opened which asks for the missing information.
Thanks again for your hard work!
Thanks those are really valuable inputs I agree with most of them and will update the design.
Just this part, would you mind explaining more?
I used the sliders in the cart because you can simply fetch the available quantity and maximum discount allowed for the employee and set them for slider limits so you don’t get annoying notification when quantity not available or exceed allowed discount. Also you can easy integrate the price list rules with the sliders so available discount on the slider will be updated based on qty. Anyway we can drop them for traditional POS number keyboard
This is very nice and what I would like for a POS provider.
Have this been put up in GitHub issue or is there any bountysource for it so we can contribute to the development?
Of course:
A great thing about your design is the lack of scrolling. Everything is always visible.
The “new customer” form is the only place where that is not true:
Every on-screen keyboard I could find on Google Play uses the full width of the screen and more or less half of the hight. For your design this has the consequence that everything lower than the “Billing Address”-title would be covered and you’d have to scroll down.
To avoid that you’d have to use only the top half of the screen for the form. To insert it into your current design I thought a “New” button which opened an overlay form using the full width of the screen would be an answer to that. But I can see now that you wanted to avoid overlays. So it’s overlay vs scrolling… But maybe you have a better idea.
I hope my explanation makes more sense now.
By the way: If you get rid of new customer form on the right side you get free space for other things. For example valuable informations about the selected customer: recent history (“by the way we have a new add on for your…”), next birthday, family members… (Could be something to think about for a next release.)
Hm… I see your point now and I see the benefit of it but I honestly think there has to be a faster way for the cashier. Maybe its enough to just write down the max discount next to the discount button. If they put more then allowed they get a sound and the max discount turns red or something…
Two more things:
I would add a big “+” button in the top bar to open a new sale. If a default customer is set in ERPNext then you go right away to the Cart-tab with the default customer preset. Otherwise you go to the Customer-tab to choose a new customer.
This could speed it up the switch to a new sale especially if a default customer is set.
In an retail store you often get unregistered customers. In ERPNext there has to be a specified customer. As a workaround you have to have a customer called “Unregistered” (or similar).
Lets say you start with customer “Unregistered” but then you realize you need to register this customer (maybe because you have to call them when their order has arrived). You don’t want to overwrite “Unregistered” nor do you want to open a new cart and repeat the sale.
You just want to swap from “Unregistered” to a new registered customer. Maybe you could add the possibility to change a customer to an other one. Or maybe there is a better solution to this problem…
@ganas
I hope I’m not too annoying with all my inputs. It’s just that I’m really exited about your design!
Hi,
I totally agree. What if we have to add “Unregistered” Customers to queue? In retail, it is more than often that we have “Unregistered” customers.
One way around this is to add a customer called “Retail”.
Also, quick change of POS Profile, while I understand that it is related to ERPNext login.
I would also want to see a 2nd screen for customers so that they can view what was scanned and the total for cart. Maybe can add this to the bounty too.
This is way cool…
\i need this one for my restaurant business
Here is an updated design based on the inputs
poserpnext.bitballoon.com
Changes
1- search box in the top. In this search box, you can:
2-Customers Tab
2-Cart Tab
3-Payment Tab
4-Summary Tab
5-Active customer
6-Online Tab
Great and lovely @ganas
Just to comment a bit, hehe
Have a field for Discount Coupon. Future proof the POS as discount coupons seems the norm in the retail world. Or if Discount Coupon DocType to be provisioned along with POS update.
Cart Summary. I think to put in Item, Item Price, Qty, Total Item Qty will be much better.
Should be able to select default customer, for example, retail shop will more often than not choose Walk-In customer
Thank you very much @ganas !
One thought is, this is a completely new design language. I’m not so sure it is a good idea to introduce a standalone design language with the module, as that will be jarring for the user experience.
However, it would make a lot of sense to make this a standalone Electron app for ERPNext POS. In that sense, design language could be modified, and there are further possibilities. However, that would increase cost and development time drastically, so feasibility and community interest will easily be in question.