Si vous évaluez un logiciel de workflow restaurant, la vraie question n'est pas de savoir si le POS imprime vite une addition. La meilleure question est de vérifier si la commande, la cuisine, les ingrédients, la facture, le paiement et la clôture de shift racontent encore la même histoire en fin de service.
Dans Maduuka, oui. Le workflow restaurant suit la chaîne POS -> KOT -> KDS -> production terminée -> facture -> règlement -> libération de table. Cette séparation permet d'aller vite sans laisser filer le stock, la caisse ou la responsabilité cuisine.
L'article ci-dessous montre comment cela fonctionne en pratique et pourquoi cette structure compte pour les restaurants, cafés, bars et activités hospitality qui ont besoin de contrôles plus solides qu'un simple till.
Réponse Directe
Qu'est-ce que le workflow restaurant Maduuka ?
Le workflow restaurant Maduuka est une séquence opérationnelle contrôlée qui sépare la saisie POS, la production cuisine, la déduction des ingrédients, la facturation, le règlement et la fermeture. Le système facture seulement ce que la cuisine a terminé et règle seulement via une étape de paiement liée à la responsabilité du shift.
Vue d'Ensemble
La chaîne en sept temps, de l'ouverture de table à la clôture de shift
C'est la colonne vertébrale opérationnelle du module restaurant. Elle reste simple à apprendre, tout en étant assez stricte pour rendre la réconciliation de fin de journée plus propre.
Étape 1
Ouvrir la commande client dans le POS
Étape 2
Envoyer la demande en cuisine sous forme de KOT
Étape 3
Traiter les tickets en direct sur le KDS
Étape 4
Ne rendre facturable que la production terminée
Étape 5
Créer la facture à partir des articles complétés
Étape 6
Enregistrer le règlement via des tenders contrôlés
Étape 7
Fermer la commande, libérer la table et clôturer le shift
Étape par Étape
Comment le workflow protège le service, le stock et la caisse
Le principe clé est la séparation. Chaque phase peut faire son travail, mais sans prendre silencieusement la place de la phase suivante.
1. Préparation avant service et contrôle du shift
Avant de servir, l'établissement doit être opérationnel côté tables, prix, ingrédients et journée d'activité.
Maduuka attend un module restaurant actif, des tables configurées, des produits et prix ouverts, des mappings ingrédients définis et une journée d'activité ouverte.
Le caissier doit aussi avoir un shift restaurant ouvert. Sans shift ouvert, le règlement est bloqué, ce qui garde les paiements attachés à une vraie plage de caisse.
Les états restent lisibles : commandes `open`, `closed`, `cancelled`; tables `available`, `occupied`, `reserved`, `inactive`; KOT `pending`, `started`, `completed`, `cancelled`.
2. Création de commande dans le POS
La commande devient le dossier principal de toute la session client.
Le personnel peut créer une commande restaurant en `dine_in`, `takeaway`, `delivery` ou `no_charge`.
Pour le service sur place, la table choisie est rattachée immédiatement et passe en `occupied` afin que la salle reste opérationnellement juste.
Les KOT, la facturation et le règlement restent tous rattachés à cette même commande restaurant.
3. Création des KOT et exécution sur le KDS
La demande est capturée d'abord, puis la cuisine confirme l'exécution dans une file visible.
Les articles ajoutés par le serveur ne deviennent pas tout de suite des ventes facturées. Ils passent d'abord dans le flux KOT comme instructions de production.
Un KOT exige une commande ouverte, commence en `pending`, peut encore être mis à jour tant qu'il est pending, et capture les prix de vente au moment de sa création.
Le kitchen display montre les tickets pending et started actifs, ainsi que les tickets completed ou cancelled récents pour la visibilité immédiate.
4. Déduction du stock au démarrage du KOT
Le stock ingrédient bouge quand la production devient réelle, pas quand le serveur tape la demande.
Quand la cuisine démarre un KOT, Maduuka décompose les plats en besoins BOM ou ingrédients et sort le stock selon les règles du dépôt.
La déduction est atomique. Si un ingrédient manque, le démarrage du KOT échoue au lieu de créer un faux scénario de production.
Annuler un KOT pending l'arrête simplement, tandis qu'annuler un KOT started réintègre le stock pour garder l'inventaire aligné sur le travail cuisine réel.
5. Facturation uniquement de la production terminée
La reconnaissance financière suit la production, pas l'espoir.
Seuls les articles KOT `completed` sont facturables. Les lignes `pending` et `started` n'entrent pas encore dans la facture.
Maduuka prend en charge la facturation par commande complète, par KOT sélectionnés ou par quantités partielles, ce qui aide pour les additions partagées.
Les quantités déjà facturées sont suivies afin d'empêcher une double facturation du même article KOT.
6. Règlement, clôture et libération
Le paiement passe par une seule couche de règlement contrôlée, puis la table et le shift se ferment proprement.
Le règlement exige une journée non verrouillée, un shift caisse ouvert, une facture valide et au moins un tender.
Le routage de tender prend en charge `cash`, `mobile_money`, `card`, `room_charge`, `city_ledger`, `complimentary` et `no_charge`, chacun avec sa voie comptable ou opérationnelle.
Quand le service est terminé, la commande se ferme, la table revient en `available`, et la clôture de shift compare le cash attendu au cash réel en caisse.
POS Restaurant
L'équipe salle ouvre les commandes, rattache les tables et pousse les articles dans le flux KOT sans les traiter trop tôt comme ventes facturées.
Kitchen Display
La cuisine travaille les tickets en direct à travers les états pending, started, completed ou cancelled, avec table et contexte visibles.
Pourquoi C'est Important
Pourquoi le démarrage cuisine est un meilleur point de contrôle stock que la saisie POS
Un serveur peut demander cinq plats. Cela ne prouve pas que la cuisine a produit cinq plats. Cela ne prouve certainement pas non plus que cinq plats d'ingrédients doivent déjà manquer du stock.
En déduisant les ingrédients quand un KOT démarre effectivement, Maduuka fait de la production le moment qui bouge le stock. C'est un modèle de contrôle plus propre pour les restaurants, bars et activités hospitality où l'intention de service et l'exécution cuisine divergent souvent.
Cela rend aussi les annulations plus nettes. Un KOT pending peut s'arrêter sans toucher au stock. Un KOT started peut réintégrer le stock par un chemin contrôlé au lieu de laisser un nettoyage manuel pour plus tard.
Couche de Règlement
Un routage de tender adapté au restaurant et à l'hospitality
La couche paiement ne sert pas seulement à accepter de l'argent. Elle sert aussi à envoyer chaque type de paiement vers la bonne destination opérationnelle et comptable.
Cash, mobile money et carte
Ces paiements mettent à jour les paiements de facture et les ledgers de caisse ou de compte appropriés.
Room charge
Ce tender poste la consommation restaurant sur le folio hôtel plutôt que dans le tiroir caisse.
City ledger
Ce tender dirige le montant vers les créances ou le crédit client, utile pour les comptes entreprises.
Complimentary et no charge
Ces cas ferment la facture par un chemin d'audit contrôlé au lieu de simuler un paiement cash normal.
Valeur Management
Ce que les dirigeants gagnent avec ce workflow
Le workflow restaurant devient plus crédible parce que l'état de commande, l'état cuisine, l'état de facture et la clôture de shift arrivent chacun au bon moment, au lieu d'être mélangés dans un seul geste.
Visibilité cuisine
Le KDS garde visibles les KOT pending, started, completed et cancelled au lieu de laisser la cuisine travailler dans le flou.
Discipline ingrédient
Le stock bouge au démarrage du KOT, pas à la saisie serveur, ce qui rapproche exécution cuisine et inventaire.
Discipline de facturation
L'établissement ne peut facturer que la production terminée, ce qui réduit les litiges et les additions fragiles.
Responsabilité caisse
Le règlement est bloqué sans shift ouvert, et la clôture compare caisse d'ouverture, tenders cash, pay-ins, pay-outs et cash réel.
Souplesse hospitality
Le room charge et le city ledger permettent au même workflow de servir un restaurant seul ou une exploitation reliée à l'hôtel.
Réconciliation de nuit plus propre
État de commande, état KOT, état de facture et clôture de shift racontent une histoire plus cohérente en fin de journée.
Ce que cela change dans l'exploitation quotidienne
Une table peut rester ouverte pendant que de nouveaux KOT sont ajoutés. La cuisine peut terminer certains articles pendant que d'autres avancent encore. La facturation peut se faire par articles complétés, par commande complète ou par quantités choisies. Le règlement peut partir en cash, carte, mobile money, folio hôtel ou city ledger. Ensuite, et seulement ensuite, la commande se ferme et la table revient en `available`.
C'est pourquoi ce workflow sert au-delà du restaurant classique. Il convient aussi aux bars, cafés, fast casual et hôtels qui ont besoin que la facturation restaurant parle proprement au room charge. Si vous voulez la vue fonctionnelle complète, consultez la page module restaurant. Pour le stock ingrédient, les déductions BOM, les transferts et le réapprovisionnement, consultez la page gestion de stock. Si votre activité a aussi besoin de facturation sur chambre, voyez comment cela s'intègre sur le module hôtel.
FAQ
Questions fréquentes sur le workflow restaurant
Quel est le contrôle clé du workflow restaurant Maduuka ?
Le workflow sépare la saisie de demande, l'exécution cuisine, la facturation et le règlement. Un serveur peut ouvrir une commande, mais seule la production cuisine terminée devient facturable et seul un règlement contrôlé enregistre le paiement.
À quel moment Maduuka déduit-il le stock restaurant ?
Le stock ingrédient est déduit quand la cuisine démarre le KOT, pas quand le serveur crée la commande et pas quand la facture est ensuite réglée.
Une même table peut-elle avoir plusieurs tickets cuisine ?
Oui. Une commande restaurant peut porter plusieurs KOT, ce qui convient aux boissons, plats, desserts et autres ajouts en cours de service.
Pourquoi Maduuka facture-t-il seulement les articles KOT complétés ?
Parce que l'établissement doit facturer ce que la cuisine a réellement produit, pas simplement ce qui a été demandé. Cette règle protège la confiance client et la qualité de réconciliation.
Étape Suivante
Voyez ce workflow face à votre propre modèle de service
Si votre équipe a besoin d'un lien plus solide entre la salle, la cuisine, la caisse et les rapports de fin de journée, le bon test n'est pas une brochure. C'est de vérifier si votre flux restaurant tient encore sous pression.
