Caisse restaurant, écran cuisine et commande à table

Les logiciels de commande pour restaurants échouent en général à deux endroits : quand un inconnu peut commander sur une table qui n’est pas la sienne, et quand le total affiché au client diffère de celui de la caisse. Le module a été conçu à rebours de ces deux échecs. La session de table est ouverte par le personnel et porte un jeton à usage unique ; l’addition est le même jeu de lignes que la caisse lit ; et place_dining_order calcule chaque ligne côté serveur.

Le QR de table est un jeton à usage unique, pas un numéro

Il n’existe volontairement aucun chemin « saisissez votre numéro de table ». C’est la fonction évidente à construire, et la raison pour laquelle tant de systèmes s’abusent depuis le parking : si le seul justificatif est un numéro imprimé, toute personne ayant mangé là peut commander sur n’importe quelle table, indéfiniment. À la place, le personnel ouvre la table depuis la console, ce qui frappe un jeton à usage unique intégré au QR. Un QR photographié, une capture transmise ou l’impression de mardi dernier portent un jeton qui n’est plus courant, et ne fonctionnent pas.

Un client debout devant la table n’est ni membre du commerce ni hôte d’une session qui n’existe pas encore : sous la sécurité au niveau des lignes, il ne peut pas lire la table dining_sessions du tout. La sécurité des lignes juge qui appelle ; elle ne peut pas juger qu’une requête porte un jeton valide. Le scan passe donc par join_session_by_token, une fonction SECURITY DEFINER qui compare le jeton côté serveur, fait du premier scanneur l’hôte, et renvoie null sans dire pourquoi. Une erreur qui distinguerait « mauvais jeton » de « jeton expiré » serait un oracle de devinette.

Une fois à l’intérieur, l’hôte peut inviter le reste de la table par un lien ou par une carte en conversation, pour que l’ami arrivé en retard rejoigne la même session et que ses plats tombent sur la même addition.

Commander : options, notes, et une carte qui sait qu’elle ferme

La carte est organisée par catégorie et chaque plat peut porter des groupes d’options — le supplément, le niveau de piment, le choix de nouilles — avec écart de prix, caractère obligatoire et nombre maximal de choix. L’écart est attaché à l’option, pas tapé dans une note : c’est pourquoi le bon de cuisine et la ligne d’addition sont d’accord sur ce qui a été commandé. Les plats acceptent aussi une note libre et une quantité, et le panier reste modifiable jusqu’à l’envoi.

Horaires, dernière commande et contrôle de l’âge pour l’alcool

Les commerces règlent leurs horaires avec une marge de dernière commande. À l’approche, la carte prévient que la cuisine ferme bientôt ; au-delà, la commande est bloquée plutôt qu’acceptée puis annulée en silence. Les plats indisponibles ou en rupture le disent sur la carte, avant le geste. L’alcool porte son propre indicateur : contrôle de l’âge à partir de la date de naissance du client, et le personnel peut vérifier l’âge de toute une table d’un coup.

La file de confirmation : rien n’atteint la cuisine avant qu’une personne dise oui

Les commandes envoyées n’arrivent pas directement au passe. Elles tombent dans une file d’attente de confirmation sur l’écran cuisine, et le personnel confirme ou refuse chacune avant qu’elle ne devienne du travail. Un système qui laisse un téléphone déposer des tickets en cuisine a donné à un inconnu le pouvoir de coûter de la marchandise, et supprime le moment où un humain remarque que la table six a commandé quatre menus identiques par erreur.

Depuis l’écran cuisine, le personnel fait avancer les commandes d’un état au suivant, et la console affiche des pastilles rafraîchies toutes les quelques secondes — commandes actives, tables qui appellent, réservations en attente, nouvelles livraisons — plus un bandeau rouge dès qu’une table appelle le personnel. Les clients ont l’autre moitié de la boucle : appeler le personnel, demander l’addition, ou quitter la table.

L’addition détaillée en direct, et son partage par QR PromptPay

L’addition en direct montre exactement les lignes que lit la caisse, mise à jour au fur et à mesure que les plats sont confirmés : pas de révélation en fin de repas, pas de reconstitution de mémoire. À la fermeture de la table, l’app produit une fiche de fin — avec des suggestions d’ajout en ami pour les personnes qui ont partagé la session — puis un rappel d’avis. Les reçus restent dans un historique personnel.

Partager l’addition : combien chacun doit

La vue de partage répond à la seule question qui fait vraiment débat : ce que je dois. Chacun voit son propre sous-total à la carte plus une part égale d’un éventuel buffet posé sur la table. Un QR PromptPay peut être généré pour le montant, au format QR thaïlandais standard avec sa somme de contrôle CRC-16.

Buffet : forfait par personne, minuteur et frais de restes

Le buffet a son propre modèle plutôt que d’être simulé par un plat au prix par tête. Une formule a un prix par personne, un minuteur avec prolongations accordées par le personnel, et des effectifs adultes et enfants distincts. Les plats portent un rôle buffet — inclus, à la carte uniquement, ou inclus avec supplément — pour qu’une seule carte serve les deux publics. La facturation des restes est prise en charge avec des unités : la règle que la plupart des buffets thaïlandais impriment déjà sur la table et que la plupart des logiciels feignent d’ignorer.

Livraison, vente à emporter et réservations de table

La même carte alimente la livraison et l’emporter. Une commande porte des frais, un prestataire, une heure de retrait planifiée et une adresse, et passe par nouvelle, en cuisine, en route et terminée, avec notification des deux côtés à chaque transition. Les réservations de table prennent une date, une heure, un nombre de convives et une note, et attendent la confirmation du commerce. Un commerce qui vend aussi des produits emballés passe par le module boutique, bâti sur la même règle de tarification serveur.

Deux variantes fréquentes. Un établissement qui sert au comptoir et appelle par numéro utilise la file d’attente plutôt que des tables. Et si vous voulez d’abord savoir ce qu’ouvrir un commerce demande, la page pour les professionnels le décrit en entier.

Chaque prix est calculé sur le serveur

La règle qui sécurise tout le reste : le client ne fixe jamais un prix. place_dining_order et place_shop_order lisent les prix, les écarts d’options et les frais de livraison dans la base et ignorent ce que le téléphone a envoyé. Un champ client auquel on fait confiance est une remise en libre-service. Le même principe couvre les avis : seul un client dont la base peut prouver qu’il a mangé sur place ou commandé en livraison peut en écrire un, et la note en étoiles est recalculée par un déclencheur.