While advising a potential client with a requirement to be able to setup mobile POS-clients for traveling between retail trade-fairs in Germany, we had the opportunity to analyze a few weaknesses of the odoo POS.
The Web-POS is great, as it simplifies the client-side requirements, requiring no client-software installations, no version-upgrades and no setup. However, use-cases are POS require very high reliability, as a failure could imply lost-transactions, long queues at the retail-outlet and disgruntled staff that aren’t able to execute checkout-functions.
While out at trade-fairs, often with somewhat temporary infrastructure such as power-supply, or network-access, the Web-POS tends to loose all the data in the case of a power-failure. In such a use-case, the browser looses all cached data (which it maintains for operation in offline-mode), which will inevitably lead to deletion of all recent transactions, before committing them to the central odoo system.
The only visible solution we could think of to guarantee zero-data-loss is a native App for the POS hardware, usually a PC-platform, running the Linux or Windows operating-systems.
Native Android/Java POS Client
A local native Android or Java client, though laborious to write, brings with it certain irreplaceable advantages.
- Local caching of transactions, before they are ATOM-ically committed to the central odoo-system using web-services
- Easier integration of a wide variety of hardware such as iButtons, barcode-scanners, receipt-printers, ID-hardware like finger-print-reader, and possibly other types of peripheral hardware.
One of problems this client expressed was that variants of products, especially size-variants, couldn’t be differentiated easily in a POS scenario on the Web-UI of odoo’s Web-POS. Larger fonts and better differentiation of variants, would reduce room for human-error.
An important deficiency of the web-POS was the lack of differentiation between cashiers. It is quite possible that multiple sales-persons use the same cash-register for checking out customers. In this case it would be important to differentiate between transactions performed by each sales-person, so that problems and performance can be traced back to a specific worker.
iButton / Dallas Key
An iButton, or a Dallas Key, is an interesting innovation from the 1990’s which allows for identification of personnel using a simple button-like electrical-component upon contact with a key-reader.
This simple addition of hardware allows for login/logout of sales-staff, and potentially also triggers the commit of transactions from the POS (local) to the odoo-server.
Several driver implementations are available for integrating the iButton into Java-applications, or possibly even Android.
We concluded that an Android/Java client connected to the odoo Server via Webservices would offer a much more reliable POS. Typically a staff-identification mechanism should be possible to be implemented into the POS over and above username/password (because they tend to be forgotten, and are a hassle to maintain if sales-staff changes often).