odoo, Android-Client, iButton, Offline-Mode and other POS Challenges

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.

Power Failures

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.

Variant Sizes

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.

Multiplie Cashiers

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.

Conclusion

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).

References

  1. Wikipedia – 1-Wire Device Communication Buy-System
  2. iButton Products & Applications
  3. An Example Of How To Interface To Dallas Semiconductor’s iButton And 1-Wire Network
  4. odoo POSBOX