Retour sur le code sprint POS chez Akretion

J’ai eu le plaisir d’être accueilli dans les locaux lyonnais d’Akretion du 7 au 10 juillet pour développer deux briques communautaires du module Point Of Sale d’Odoo(ex-OpenERP) :

• la gestion des afficheurs clients LED (typiquement deux lignes de vingt caractères)
• l’envoi du montant au lecteur de carte bancaire ou éventuellement à l’imprimante de chèques (protocole CONCERT)

Chaque fonction est intégrée via deux modules distincts : l’un modifie le serveur OpenERP et le front-end Javascript du POS et l’autre joue le rôle de driver au sein du proxy hardware développé par OpenERP SA embarqué dans la POSbox. L’ensemble du code est actuellement disponible sur Launchpad et devrait bientôt être mergé dans un projet de l’OCA sur Github.

Au cours de ce code sprint j’ai également commencé à développer un module pos_payment_method_option permettant:

• de spécifier dans l’objet account.journal si l’utilisation de cette méthode de paiement doit déclencher l’ouverture du tiroir caisse
• spécifier dans account.journal si le restant dû doit être saisi automatiquement
• spécifier dans account.journal si la vente doit être validée automatiquement (éviter l’écran de rendu monnaie)
• afficher les boutons correspondant aux méthodes de paiement sur deux colonnes

Bien qu’il reste encore pas mal de choses à peaufiner dans les modules front-end que j’ai écrits, cela ne m’a pas empêché de rêver aux extensions possible du POS.

Les modules suivants devraient être disponibles dans les Addons officiels en v8 :

• menu de sélection du client
• gestion des tables
• gestion des imprimantes ticket coté cuisines
• gestion des promotions et de la fidélité

Ces modules représentent une grosse avancée mais comme toujours, certaines fonctions pourraient être ajoutées :

• la segmentation des tickets par vendeurs avec un code, un code-barres ou une clé Dallas personnelle
• la synchronisation des tickets en cours pour chaque vendeur sur toutes les caisses
• le partage d’un périphérique (le lecteur de CB par exemple) entre plusieurs caisses alors que cette caisse possède sa propre POSbox pour l’afficheur client et l’imprimante tickets. Cela implique la connexion à plusieurs POSbox pour chaque caisse et le routage des flux au sein du proxy.
• l’accès au backend en mode ResponsiveDesign afin de pouvoir saisir un nouveau client ou une nouvelle commande aisément depuis un écran tactile sans devoir recréer des vues spécifiques
• gestion de la réservation des tables de restaurant
• gestion des formules : une ligne d’en tête portant le prix et des lignes filles portant les composants à déstocker parmi un choix restreint. La détection automatique des formules à partir des éléments serait aussi un plus mais pourrait se frotter à une explosion combinatoire
• le changement de méthodes de règlement à posteriori (avant la clôture de la session)
• la réimpression de tickets à posteriori
• pour les commerçants qui souhaitent utiliser l’écran de rendu monnaie, ajouter un bouton avec image pour chaque billet ou pièce possible permettant d’incrémenter le paiement en cash
• la clôture « en aveugle » de la caisse (en option) : le responsable clôture la caisse sans avoir accès au chiffre d’affaire théorique ni au fond de caisse qui en découle. Cette technique est parfois utilisée pour détecter les vendeurs faisant trop d’erreurs ou essayant de taper dans la caisse
• imprimer les tickets à la demande. Notez que s’il on choisit de valider automatiquement une vente dès l’appuie sur le bouton « Cash », il faudra soit prévoir de stocker le ticket précédent (sérialisé pour l’impression) dans un PosModel.last_order_xml soit prévoir un bouton permettant l’impression du ticket pour la vente en cours lors de sa validation
• gestion plus fine des droits coté client : un manager doit rentrer son code pour supprimer un ticket ou une ligne, modifier un prix, mettre une quantité négative ou saisir un rabais manuellement

Comme l’a suggéré Anthony Lesuisse (CTO d’OpenERP SA) sur Twitter, il serait aussi intéressant de développer un afficheur client à base d’écran LCD classique branché en HDMI sur la POSbox. Cela serait plus gourmand en énergie et en place sur le comptoir mais ça apporterait un confort visuel et une grande souplesse. L’on pourrait pousser le concept jusqu’à intégrer des publicités du commerçant ou bien de tiers. L’afficheur client deviendrait une source de revenu complémentaire en transformant le commerçant en une régie publicitaire. Les annonceurs pourraient même associer leur annonce à des produits vendus avec un système d’enchères comme le fait GoogleAdds… C’est beau de rêver.