View source | View content page | Page history | Printable version   

Projects:OfflineImprovements/Functional Specification



The Web POS supports offline operation, using several HTML5 technologies which allows it to persistently store both masterdata and transactional data. Support for offline operation is essential for most customers, because the sales operations can never be stopped, and need to happen immediately, and therefore the Web POS should be able to handle situations such as Internet connectivity loss, or backend server issues, in such a way that the cashier doesn't lose the ability to operate the application and register new sales tickets.

However, the current implementation of offline mode has been problematic in some cases. After analysing experiences of real customers, and comparing their feedback with our internal experiences, we have concluded the following:

This project aims to do the necessary refactor to prevent the last two cases, and ensure that the Web POS application is always available and ready to be used to register new sales in all possible circumstances.

Causes of the current problems

The main cause the Web POS doesn't behave correctly when in a state of partial, or intermittent, offline state, is that it treats every remote request as being fully independent. This means that every remote request is always executed, even if the previous ones didn't succeed. This has several bad consequences:

Main proposal

The main change we propose is in the way we manage the offline state. Currently, the Web POS is aware of the current state (as described by the last request), and it even shows it in the UI, although it's a bit hidden in the menu:


This state, however, is not really used for anything other than for user info. Every remote request is independent, and always triggered.

The main change we propose is to have global management of the online/offline status, with the following fundamental ideas:

These changes need to be combined with some changes in the way complex processes with multiple requests (specifically the login process) are done, so that they always follow the same pattern:






Current questions/doubts

Conclusion: Will be configurable, as it depends on customer situation and expectations. Default config will be that every request failure moves the Web POS to offline, but will be configurable via preference.

Conclusion: Transition to online by default will be a process which will require both several requests, and also triggered over a longer period of time. It will also be configurable.

Retrieved from ""

This page has been accessed 1,562 times. This page was last modified on 9 November 2017, at 11:04. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.