ITMOR POS Android : prendre les commandes en salle et les retrouver dans uniCenta

Article d’archive. Texte préparé le 2 novembre 2026, mis en ligne le 7 novembre 2026.

ITMOR POS Android organise la prise de commande en salle autour d’uniCenta. Le point de contrôle est simple : une commande saisie sur le téléphone doit être retrouvée sur le ticket attendu, au bon état et sans ambiguïté pour la caisse.

L’idée est de relier la salle à la caisse à partir du catalogue existant. Le serveur sélectionne les produits, ajuste les quantités, ajoute les consignes et transmet un ticket ouvert. Voici le fonctionnement de cette version, ses choix techniques et les conditions nécessaires pour l’intégrer à l’organisation d’un établissement.

Une répartition claire entre le serveur et la caisse

L’application permet de parcourir les catégories, rechercher un produit par nom, référence ou code, puis constituer un panier. Elle affiche les montants en dirhams et accepte des notes par ligne ainsi qu’une note générale. Le catalogue est chargé depuis la base utilisée par uniCenta : il n’est pas nécessaire de maintenir une seconde carte indépendante dans le téléphone.

Le mobile crée un ticket partagé non encaissé, attribué à l’utilisateur uniCenta choisi lors du paramétrage. Le poste de caisse conserve l’encaissement, l’impression, les remboursements et la clôture. Cette séparation aide à définir les responsabilités : la salle prépare et transmet ; la caisse reprend et finalise selon la procédure de l’établissement.

Un exemple concret pendant le service

Prenons un exemple fictif : à la terrasse, un client commande deux thés à la menthe et un café. Le serveur sélectionne les articles, indique « sans sucre » sur la ligne concernée et utilise le repère « Table 7 ». Après vérification du panier, il touche « Envoyer à la caisse ». Le ticket peut ensuite être repris dans les tickets partagés d’uniCenta.

Ce repère sert à nommer la commande. Dans cette version, il ne réserve pas une table du plan restaurant. De même, l’envoi ne déclenche pas automatiquement une impression en cuisine. L’équipe doit donc décider qui reprend les tickets et qui transmet les préparations. L’application facilite un passage d’information ; la procédure de service doit préciser la suite.

Le bénéfice attendu est de limiter les ressaisies et les déplacements consacrés à la saisie, tout en rendant les consignes consultables. Aucun gain chiffré n’est annoncé : il dépend notamment du réseau, du catalogue, de la formation et de la façon dont la caisse traite les commandes reçues.

Sous le capot : Android, WebView et accès MySQL local

La version 0.2.0 fonctionne à partir d’Android 8, API 26, avec une cible de compilation déclarée API 35. Son interface repose sur trois fichiers HTML, CSS et JavaScript embarqués dans une WebView. Une passerelle Java interne prend en charge les opérations natives ; les accès à la base sont exécutés en dehors du fil d’interface.

Android documente le principe de cette liaison entre JavaScript et code natif dans son guide WebView. Dans ITMOR POS, les pages de l’interface sont locales et la navigation externe est bloquée. Cette organisation permet de travailler séparément sur la présentation et sur la connexion au logiciel de caisse.

Pour cette version, le téléphone utilise directement MySQL Connector/J 5.1.49 sur le réseau local ; aucun serveur REST supplémentaire n’est requis pour ce mode de connexion. Le téléphone et le serveur MySQL doivent être joignables sur ce réseau. Le PC hébergeant la base doit rester disponible et son adresse locale doit être correctement renseignée.

Préserver la cohérence du ticket envoyé

L’envoi est réservé à une base déclarant uniCenta 4.6.3. Avant l’écriture, l’application relit les produits et vérifie les prix. Si un tarif a changé depuis le chargement du catalogue, elle demande une actualisation plutôt que d’enregistrer silencieusement un montant ancien. Les produits à options, à pesée, à prix variable ou à fiscalité complexe sont réservés à la caisse.

L’écriture regroupe le ticket et sa confirmation dans une transaction. Les tables concernées doivent utiliser InnoDB. Un identifiant de requête durable permet de reconnaître un envoi déjà accepté : renvoyer la même demande récupère sa confirmation ; réutiliser cet identifiant avec un contenu différent est refusé. La documentation JDBC de Java SE 17 explique les mécanismes généraux de validation et d’annulation des transactions ; le contrôle des doublons relève ici de la logique d’ITMOR.

Ce qui reste possible lorsque le Wi-Fi coupe

Après un premier chargement, le catalogue et le brouillon restent consultables sans connexion. En revanche, l’envoi exige le réseau : il n’existe pas d’expédition automatique différée dans cette version. Lorsqu’une réception est incertaine, l’interface conserve l’envoi à vérifier et protège le panier. Il faut reprendre cette opération, plutôt que recréer immédiatement une commande identique.

Cette distinction est utile pour l’organisation : voir une commande à l’écran du téléphone ne signifie pas qu’elle est disponible à la caisse. Le serveur doit s’appuyer sur la confirmation de réception et signaler les envois encore à vérifier avant de changer de poste ou de terminer son service.

Une mise en service progressive

• Commencer sur une copie de la base : vérifier la version, le catalogue et l’ouverture d’un ticket de contrôle dans uniCenta.
• Configurer un accès MySQL dédié, limité au réseau et aux droits nécessaires, puis tester la couverture Wi-Fi dans les zones de service.
• Faire un essai à deux téléphones : commandes simultanées, consignes, tarif modifié et reprise après perte de réponse.
• Définir qui surveille les tickets reçus, qui imprime et comment traiter une commande restée en attente.

Les identifiants sont chiffrés au repos avec Android Keystore, mais cela ne chiffre pas automatiquement les échanges MySQL : le transport dépend du paramétrage TLS. Cette connexion locale et son pilote ancien nécessitent une validation sur l’installation concernée. Pour prolonger la réflexion métier, retrouvez aussi la démarche de développement d’une caisse à partir du terrain.

Adapter la solution à votre établissement

Vous souhaitez équiper vos serveurs, adapter votre caisse ou améliorer votre organisation ? Contactez ITMOR pour présenter votre projet. Précisez votre activité, la version de votre logiciel, le nombre de postes et les difficultés à résoudre : ces éléments permettront de définir une intervention adaptée.

Références et périmètre

Présentation technique du 2 novembre 2026, fondée sur les sources et le guide d’ITMOR POS 0.2.0. Références de fond consultées le 2 novembre 2026 : Android Developers, WebView ; Oracle, API JDBC Connection, Java SE 17. Application indépendante, non éditée ni certifiée par uniCenta. Le scénario de service est fictif ; aucun résultat de déploiement commercial n’est revendiqué.