Si vous evaluez 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 verifier si la commande, la cuisine, les ingredients, la facture, le paiement et la cloture de shift racontent encore la meme histoire en fin de service.
Dans Maduuka, oui. Le workflow restaurant suit la chaine POS -> KOT -> KDS -> production terminee -> facture -> reglement -> liberation de table. Cette separation permet d'aller vite sans laisser filer le stock, la caisse ou la responsabilite cuisine.
L'article ci-dessous montre comment cela fonctionne en pratique et pourquoi cette structure compte pour les restaurants, cafes, bars et activites hospitality qui ont besoin de controles plus solides qu'un simple till.
Reponse Directe
Qu'est-ce que le workflow restaurant Maduuka ?
Le workflow restaurant Maduuka est une sequence operationnelle controlee qui separe la saisie POS, la production cuisine, la deduction des ingredients, la facturation, le reglement et la fermeture. Le systeme facture seulement ce que la cuisine a termine et regle seulement via une etape de paiement liee a la responsabilite du shift.
Vue d'Ensemble
La chaine en sept temps, de l'ouverture de table a la cloture de shift
C'est la colonne vertebrale operationnelle du module restaurant. Elle reste simple a apprendre, tout en etant assez stricte pour rendre la reconciliation de fin de journee plus propre.
Etape 1
Ouvrir la commande client dans le POS
Etape 2
Envoyer la demande en cuisine sous forme de KOT
Etape 3
Traiter les tickets en direct sur le KDS
Etape 4
Ne rendre facturable que la production terminee
Etape 5
Creer la facture a partir des articles completes
Etape 6
Enregistrer le reglement via des tenders controles
Etape 7
Fermer la commande, liberer la table et cloturer le shift
Etape par Etape
Comment le workflow protege le service, le stock et la caisse
Le principe cle est la separation. Chaque phase peut faire son travail, mais sans prendre silencieusement la place de la phase suivante.
1. Preparation avant service et controle du shift
Avant de servir, l'etablissement doit etre operationnel cote tables, prix, ingredients et journee d'activite.
Maduuka attend un module restaurant actif, des tables configurees, des produits et prix ouverts, des mappings ingredients definis et une journee d'activite ouverte.
Le caissier doit aussi avoir un shift restaurant ouvert. Sans shift ouvert, le reglement est bloque, ce qui garde les paiements attaches a une vraie plage de caisse.
Les etats restent lisibles : commandes `open`, `closed`, `cancelled`; tables `available`, `occupied`, `reserved`, `inactive`; KOT `pending`, `started`, `completed`, `cancelled`.
2. Creation de commande dans le POS
La commande devient le dossier principal de toute la session client.
Le personnel peut creer une commande restaurant en `dine_in`, `takeaway`, `delivery` ou `no_charge`.
Pour le service sur place, la table choisie est rattachee immediatement et passe en `occupied` afin que la salle reste operationnellement juste.
Les KOT, la facturation et le reglement restent tous rattaches a cette meme commande restaurant.
3. Creation des KOT et execution sur le KDS
La demande est capturee d'abord, puis la cuisine confirme l'execution dans une file visible.
Les articles ajoutes par le serveur ne deviennent pas tout de suite des ventes facturees. Ils passent d'abord dans le flux KOT comme instructions de production.
Un KOT exige une commande ouverte, commence en `pending`, peut encore etre mis a jour tant qu'il est pending, et capture les prix de vente au moment de sa creation.
Le kitchen display montre les tickets pending et started actifs, ainsi que les tickets completed ou cancelled recents pour la visibilite immediate.
4. Deduction du stock au demarrage du KOT
Le stock ingredient bouge quand la production devient reelle, pas quand le serveur tape la demande.
Quand la cuisine demarre un KOT, Maduuka decompose les plats en besoins BOM ou ingredients et sort le stock selon les regles du depot.
La deduction est atomique. Si un ingredient manque, le demarrage du KOT echoue au lieu de creer un faux scenario de production.
Annuler un KOT pending l'arrete simplement, tandis qu'annuler un KOT started reintegre le stock pour garder l'inventaire aligne sur le travail cuisine reel.
5. Facturation uniquement de la production terminee
La reconnaissance financiere 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 complete, par KOT selectionnes ou par quantites partielles, ce qui aide pour les additions partagees.
Les quantites deja facturees sont suivies afin d'empecher une double facturation du meme article KOT.
6. Reglement, cloture et liberation
Le paiement passe par une seule couche de reglement controlee, puis la table et le shift se ferment proprement.
Le reglement exige une journee non verrouillee, 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 operationnelle.
Quand le service est termine, la commande se ferme, la table revient en `available`, et la cloture de shift compare le cash attendu au cash reel en caisse.
POS Restaurant
L'equipe salle ouvre les commandes, rattache les tables et pousse les articles dans le flux KOT sans les traiter trop tot comme ventes facturees.
Kitchen Display
La cuisine travaille les tickets en direct a travers les etats pending, started, completed ou cancelled, avec table et contexte visibles.
Pourquoi C'est Important
Pourquoi le demarrage cuisine est un meilleur point de controle 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'ingredients doivent deja manquer du stock.
En deduisant les ingredients quand un KOT demarre effectivement, Maduuka fait de la production le moment qui bouge le stock. C'est un modele de controle plus propre pour les restaurants, bars et activites hospitality ou l'intention de service et l'execution cuisine divergent souvent.
Cela rend aussi les annulations plus nettes. Un KOT pending peut s'arreter sans toucher au stock. Un KOT started peut reintegrer le stock par un chemin controle au lieu de laisser un nettoyage manuel pour plus tard.
Couche de Reglement
Un routage de tender adapte au restaurant et a l'hospitality
La couche paiement ne sert pas seulement a accepter de l'argent. Elle sert aussi a envoyer chaque type de paiement vers la bonne destination operationnelle et comptable.
Cash, mobile money et carte
Ces paiements mettent a jour les paiements de facture et les ledgers de caisse ou de compte appropries.
Room charge
Ce tender poste la consommation restaurant sur le folio hotel plutot que dans le tiroir caisse.
City ledger
Ce tender dirige le montant vers les creances ou le credit client, utile pour les comptes entreprises.
Complimentary et no charge
Ces cas ferment la facture par un chemin d'audit controle au lieu de simuler un paiement cash normal.
Valeur Management
Ce que les dirigeants gagnent avec ce workflow
Le workflow restaurant devient plus credible parce que l'etat de commande, l'etat cuisine, l'etat de facture et la cloture de shift arrivent chacun au bon moment, au lieu d'etre melanges dans un seul geste.
Visibilite cuisine
Le KDS garde visibles les KOT pending, started, completed et cancelled au lieu de laisser la cuisine travailler dans le flou.
Discipline ingredient
Le stock bouge au demarrage du KOT, pas a la saisie serveur, ce qui rapproche execution cuisine et inventaire.
Discipline de facturation
L'etablissement ne peut facturer que la production terminee, ce qui reduit les litiges et les additions fragiles.
Responsabilite caisse
Le reglement est bloque sans shift ouvert, et la cloture compare caisse d'ouverture, tenders cash, pay-ins, pay-outs et cash reel.
Souplesse hospitality
Le room charge et le city ledger permettent au meme workflow de servir un restaurant seul ou une exploitation reliee a l'hotel.
Reconciliation de nuit plus propre
Etat de commande, etat KOT, etat de facture et cloture de shift racontent une histoire plus coherente en fin de journee.
Ce que cela change dans l'exploitation quotidienne
Une table peut rester ouverte pendant que de nouveaux KOT sont ajoutes. La cuisine peut terminer certains articles pendant que d'autres avancent encore. La facturation peut se faire par articles completes, par commande complete ou par quantites choisies. Le reglement peut partir en cash, carte, mobile money, folio hotel ou city ledger. Ensuite, et seulement ensuite, la commande se ferme et la table revient en `available`.
C'est pourquoi ce workflow sert au-dela du restaurant classique. Il convient aussi aux bars, cafes, fast casual et hotels qui ont besoin que la facturation restaurant parle proprement au room charge. Si vous voulez la vue fonctionnelle complete, consultez la page module restaurant. Pour le stock ingredient, les deductions BOM, les transferts et le reapprovisionnement, consultez la page gestion de stock. Si votre activite a aussi besoin de facturation sur chambre, voyez comment cela s'integre sur le module hotel.
FAQ
Questions frequentes sur le workflow restaurant
Quel est le controle cle du workflow restaurant Maduuka ?
Le workflow separe la saisie de demande, l'execution cuisine, la facturation et le reglement. Un serveur peut ouvrir une commande, mais seule la production cuisine terminee devient facturable et seul un reglement controle enregistre le paiement.
A quel moment Maduuka deduit-il le stock restaurant ?
Le stock ingredient est deduit quand la cuisine demarre le KOT, pas quand le serveur cree la commande et pas quand la facture est ensuite reglee.
Une meme 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 completes ?
Parce que l'etablissement doit facturer ce que la cuisine a reellement produit, pas simplement ce qui a ete demande. Cette regle protege la confiance client et la qualite de reconciliation.
Etape Suivante
Voyez ce workflow face a votre propre modele de service
Si votre equipe a besoin d'un lien plus solide entre la salle, la cuisine, la caisse et les rapports de fin de journee, le bon test n'est pas une brochure. C'est de verifier si votre flux restaurant tient encore sous pression.
