Feature request: touch screen capable 'caffe' interface

[SamuelDudley]

My use case is a caffe environment where the primary trade is coffee, but other items such as cakes and wholesale produce are sold as well. This use case differs from the current register app which I feel is currently more of a 'check out' style application.

My idea is the following:

An interface which has a grid of buttons which are linked to items and item modifiers. When an item button is pressed the item is added to the current transaction. When a modifier button is pressed, extra detail is added to the item (and extra cost if appropriate).

As an example consider the process of ringing up an order for a coffee:

You could add an item: coffee then you could add a modifier: skim milk etc...

It is possible that modifiers have an added cost associated with them:

Coffee $3.00

• skim milk
• extra shot $0.50

When the order is complete there is an option to print a order docket which would be in this case passed onto the barista and in addition there is an option to print a tax receipt for the customer. These two print outs would differ in detail.

As a note this is what im designing the system around / to support (working with what I've been given):

• Apple iPad
• Heckler Design Windfall POS Cash Drawer
• Epson TM-T82II Ethernet Thermal Receipt Printer
• Server (details TBA but most likely an Odroid XU3 running Ubuntu)

Is there any interest in having this sort of use case supported? At the moment I'm hacking my way through an initial proof of concept which I'm happy to contribute back to the repo.

My pan is to make a separate app within orthosie and use the existing inventory system.

Input is welcome!

[maxolasersquad]

Yes, this is very much in my plans. I have a friend that runs a restaurant and I would like for him to be able to adopt this program at some point. I have designed it up to this point to be a POS for something more like a grocery store. I have been building this for our local food cooperative.

My primary goal right now is to make everything from the interface work by calling restful api endpoints. This will make the business logic completely separate from the interface and will allow multiple interface to be built, each for their own specific purpose. I would eventually like to have three main modules, core, inventory, and register. Core would run a server, inventory would run on an office PC, and register would run on the registers. There could be multiple register applications.

Anyways, these are my thoughts on my long-term design decisions. At point I had written out a bunch of road maps on what I wanted to see for each release. I should probably work out more roadmaps that lay out all of these ideas.

[maxolasersquad]

All chargeable items extend from the class Inventory.Item. Right now Grocery (really, anything with a UPC) and Produce (anything with a PLU) are the only ringable items.

Adding a new class, I'll just call it Food for sake of a better name. They would only have a name and a charge. Each food entry could have a many-to-many relationship with these modifiers, which themselves would inherit from Item so that they could have prices too. Every time a Food is selected the interface could see its modifiers and provide those as options. This is just off the top of my head.

[SamuelDudley]

That sounds logical. I guess what I had proposed would be a different register front end and a some features added to the core module as you said. This is something I'll be doing in some of my spare time to help out my brother. My coding background is Python and C++ in an embedded systems context so web development, css, html and javascript is new to me. I have a bit of learning to do on that front but it seems quite manageable.

Another possible end point of interest to me for this system is a kitchen or similar environment which displays current active orders (rather than printing a docket).

If you had a grid of buttons for a register front end they could be each assigned a url via the REST API to assign an action... but controlling what the buttons look like (location, colour, text, etc) might need a little thought. If you have an idea how one would tackle dynamically managing the buttons I would like to hear it. Something like a stand alone web app which configures the register interface?