Features OpenbravoPOS ought to have - Open source point of sale application

We've been using OpenbravoPOS as an open source POS solution and I thought it was a good time to document some of our experiences.  Firstly, I would have to say this is a really good piece of software, generally well designed in a true object oriented style - OB POS handles many of the routine POS issues very well.  The scripting environment is excellent and there is a reasonable community with a good knowledge base. However, there are some features missing that I'd like to document here.

1. Shared Ticket Locking

It appears to me, that OB POS (TinaPOS) was originally designed for a traditional counter sales retailing environment and later extended for hospitality & restaurants.  The restaurant tickets are linked to tables and the tickets (called shared tickets in the DB), have a very simple structure.

\d sharedtickets

Table "public.sharedtickets"

i.e. the entire ticket information is stored (streamed as java objects) to the content field. This creates a number of problems. The first is that the streaming only occurs when the ticketbag is activated (loaded) or deactivated (saved) and therefore, the shared ticket is not persisted between these points in time. The second issue is that it makes it hard to track changes or audit the shared tickets table without resorting to java coding. Now consider a restaurant with multiple tills where they want to access the same data - and hence the same database. If two users open up the same table, then they create two versions of the table data in memory, and these are saved when the user exists the screen. There is no locking. So corruption can and does occur. We have implemented place locking as a work around, whereby the first user to access the table, locks the table for the duration of their edit and this effectively prevents the other users for accessing the table at until the first user exists the screen and (automatically) relinquished the lock. Whilst this does not effect OB POS when used in traditional retail or in single POS mode in restaurants, this does expose a design deficiency in the business logic.

2. Built in Auditing

OB POS does not include an auditing system which would be handy for debugging and for security auditing. I think this could actually be turned in to a feature such that a supplier logs multiple audit events to a central database for all deployed systems and then creates rules based on the audit events to identify statistically significant events or sample for suspicious activity. We have implemented logging in the database based on a database trigger however some built in and more fine grained logging would be helpful.

3. Attribute Interface

Using both auxiliary products and product attributes provides a very flexible set of options for build your own products and accessorising. However, the user interface presented for attributes is clumsy and difficult to operate on a touch screen. It would be great if the attributes could be displayed in a similar way to the auxiliary products perhaps with a button to go forward / back to the next option for selection. We have added the ability to combine images, background colours and text to the product/auxiliary buttons to make the system easier to use.

4. Auto logout

If the tills are left unattended, and particularly in relation to the effect describes in 1 above, the POS should logout. This could be circumvented by integrating iButton support with 'touch and hold' - where an automatic exit would occur when the iButton is release from the POS. We are working on both of these features.

5. Service Events

It would be nice if a few more events were tracked by the system for table status - specifically events such as "seated no ordered", "ordered drinks", "ordered food", "food delivered", "desserts", "bill ordered". Some of these could be automated and some might need to be manually entered, but this would open up the ability to project times for free tables, track restaurant efficiency & turnover time, record service failures and prompt staff to action certain tables.

6. Flag out of stock products

Here a kitchen or back office user could flag the unavailability of a product temporarily due to it being out of stock - preventing the front office for selling the product for a time.

Summary

These are a few small problems, mostly related to restaurant mode. The retail sales (simple) mode works very well and is quick both with scanning, printing and manual entry. The report capability is excellent and the standard canned reports are adequate for most purposes and easily extended. Being open source, we have already created solutions to a number of these problems and I note that as of writing, the roadmap for 2.4 is being developed due for release later this year.  Let's hope that some of the issues are designed out or solved in the next release. On the whole, a solid platform with a large number of features.