Pourquoi un point de vente doit posséder ses données

La plupart des « modes hors ligne » sont un cache devant un serveur. Ils fonctionnent jusqu’au moment qui compte : la ligne tombe en plein ticket, l’application est tuée, le courant s’en va. Alors le cache et le serveur ne sont plus d’accord, et quelqu’un passe la soirée à rapprocher. Une caisse qui vend pour vivre ne peut pas être un cache.

La règle

Chaque écriture de la caisse arrive d’abord dans la base de la caisse, puis dans une file de sortie durable. La caisse n’a jamais besoin du serveur pour vendre. Internet ne sert qu’à synchroniser. Rien de ce qui est en attente ne peut être perdu à une perte réseau, un arrêt brutal, une coupure de courant ou un redémarrage.

Ce qu’il faut

• Une base embarquée avec des transactions, pour qu’un ticket et sa ligne de file de sortie soient écrits ensemble ou pas du tout.
• Des événements en ajout seul : un ticket est une liste de ce qui s’est passé, jamais une ligne que l’on modifie. Une annulation est aussi un événement.
• Une identité client : chaque ticket et chaque événement portent un identifiant créé sur la caisse, pour que le serveur accepte chacun exactement une fois, quel que soit le nombre d’envois.
• Une séquence et une chaîne de hachage par caisse, pour que l’ordre des tickets soit prouvable et qu’un trou soit visible.
• Tout ce qu’il faut pour vendre sur l’appareil : prix, taxes, promotions, taux, billets, claviers et les droits effectifs de chaque utilisateur.
• Des exercices, pas des promesses : chaque flux passant par la file de sortie est testé avec la ligne coupée, l’application tuée, le courant perdu et SAP arrêté.

Ce que cela apporte

Un caissier qui n’attend jamais. Une boutique qui continue de vendre pendant une panne. Un grand livre exact parce que le serveur enregistre ce qui s’est passé, dans l’ordre, une fois. Et un chemin de mise à jour qui ne peut pas perdre une vente, parce que la base de la caisse est le registre et que le serveur en est une copie.