Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Application pour la gestion d’un restaurant
Bonsoir à tous,
Je fais suite à une discussion commencée sur un autre fil à l'adresse :
http://www.developpez.net/forums/d98...t/#post7419422
Toutes les informations concernant le sujet de cette discussion sont résumées plus précisément à partir du post #29.
D'avance merci pour toute aide ou suggestion sur le sujet.
Fiches recettes
Bonjour macgyver44,
Je propose que nous commencions par les « Fiches recettes ».
Pour amorcer la discussion, voici ce que j’avais conçu à mes débuts (tout est à casser !) :
L’objectif : calculer le prix de revient des items proposés à la carte.
Les champs avec un fond coloré (blanc ou jaune) sont gérés par l’utilisateur, les champs avec un fond transparent sont calculés par le programme.
Deux types de recettes
Une recette générique est une recette de base (par exemple : « Cabillaud »).
Une recette dérivée est une appellation commerciale de la recette générique avec – éventuellement – un ingrédient particulier (par exemple : « Filet de cabillaud rôti en persillade, à la kriek et citrons confits »).
1) Recette générique
Trois catégories
- entrées ;
- plats ;
- desserts.
Nbre personnes
(par défaut = 1) indique le nombre de portions de la préparation.
Ingrédients
La partie de gauche contient les ingrédients de la recette générique.
Pour chaque ingrédient, un menu déroulant fait apparaître, par ordre alphabétique, les items de la table des prix unitaires (PU) des matières premières.
Note : seuls les ingrédients « de valeur » sont mentionnés dans le détail (ici le cabillaud). Pour simplifier l’encodage, la garniture habituelle (féculent, décoration de légumes...) est valorisée au forfait.
2) Les recettes dérivées
La partie de droite affiche toutes les appellations dérivées de cette recette générique.
Il s’agit de l’appellation commerciale de la recette générique.
On indique dans Supplément le coût additionnel éventuel pour la préparation de cette recette dérivée. Dans ce cas, on utilisera le champ Remarque comme pense-bête, pour se rappeler ce qui justifie le supplément de prix de revient.
Trois statuts possibles
- En force (vert) : ce plat est actuellement proposé à la carte.
- En veille (orange) : actuellement hors-saison (on le reproposera la saison prochaine).
- Caduque (rouge) : gardée temporairement pour ne pas risquer d’altérer la cohérence technique (antichambre de la poubelle).
Pour alterner, double-cliquer sur le champ (EnForceEnVeille
Le prix Tarif
C’est celui qui figurera à la carte (affiché sur fond rouge si égal à zéro).
PR , PVN, Coefficient et Marge
Pour chaque appellation dérivée, le programme calcule instantanément :
- le « PR » Prix de Revient = PR de la générique + le supplément éventuel ;
- le « PVN » Prix de Vente Normal , celui qui respecterait une politique de prix, par exemple (au hasard) :
pour une entrée : un coefficient 2.5 et un prix minimum de 6.25 €,
pour un plat : coefficient 3.0, minimum 8.75 €,
pour un dessert : coefficient 4.00, minimum 3.75 € ;
- le coefficient et la marge calculés d’après le tarif et le PR théorique.
Pied du formulaire
Des critères de sélection pour limiter les enregistrements affichés.
Le formulaire est donc polyvalent, il permet :
- ajouter, supprimer, modifier des recettes génériques et/ou dérivées ;
- opérer une recherche multicritère.
-------
Peux-tu préciser
- si ces fonctionnalités te sont utiles ;
- si tu en souhaites d’autres (photo des plats, description de la recette…).
Bonjour Claude,
C'est déjà une belle première ébauche.
Je ne souhaite pas utiliser le concept d'appellations dérivées. Je préfère créer une recette distincte par plat. Par exemple : Dos de cabillaud aux petits légumes, Dos de cabillaud, mousseline … sont des recettes à part entière même si elles partagent la plupart des ingrédients.
Je te propose une construction un peu différente mais pas forcément exhaustive (cf. pièce jointe).
C'est pourquoi j'ai introduit la notion de "sous-recette" (case à cocher) et "Appel d'une recette existante" (liste déroulante basée sur toutes les recettes de la même catégorie et dont la case sous-recette est cochée). Lorsque l'utilisateur choisira une recette dans cette liste, la totalité des ingrédients sera ajoutée à la liste des ingrédients qu'elle soit déjà remplie ou non. L'utilisateur sera libre de supprimer certains ingrédients ajoutés. Qu'en penses-tu ?
Je souhaite conserver la notion de statut.
Les champs supplémentaires : Photo, Description de la recette (Progression), les divers calculs de masse totale, prix à la part et/ou au kg, prix vente HT et marges.
Je souhaite également conserver la zone de recherche plutôt positionnée en haut du formulaire.
Bonjour macgyver44,
Ça a de la gueule !
Je ne comprends pas la notion et/ou le calcul de :
- Prix de Revient : j’attendais 2.20 (22.02 : 10) ;
- Marge en € : j’attendais 12.47 (14.67-2.20) ;
- Marge en % sur TTC : ? ;
- Marge en % sur HT : ? ;
- Masse Totale : ? ;
- Prix au Kg : ?
- Prix à la part : quelle différence avec le Prix de Revient ?
Par contre, je ne trouve pas le coefficient : « P.V.H.T : coût des marchandises », habituellement utilisé (en Belqique) soit dans l’exemple 6.67 (14.67 : 2.20). Si cela pouvait être vrai !
--------
Importer les éléments d’une recette existante
J’aime bien ton idée !
Quelle est l’utilité de la notion de « Sous-recette » ?
En d’autres mots, pourquoi ne pas autoriser l’import de la liste d’ingrédients de n’importe quelle recette existante (éventuellement limiter à celles de la même catégorie) ?
Je procéderais de même pour « Progression ».
Bonsoir Claude,
En faisant vite, j'ai commis quelques erreurs !
J'ai donc rectifié certains calculs (cf. MAJ de la copie d'écran) :
- Prix de Revient : effectivement c'est bien 2,20. Toutefois, suite à cette erreur, je m'aperçois que 2 notions sont nécessaires : le prix de revient de l'ensemble de la recette et le prix de revient par personne (qui pourront évidemment être identiques si la recette est prévue pour une personne).
- La Marge : c'est bien 14,67 - 2,20, soit 12,47
- La Marge en % sur TTC : Marge / PV TTC soit 12,47/15,70, en % cela donne 79,43%
- La Marge en % sur HT : Marge / PV HT soit 12,47/14,67, en % cela donne 85%
- La Masse Totale : c'est la somme des quantités d'ingrédients utilisés. C'est vrai, j'ai un peu mélangé les "torchons et les serviettes" comme on dit chez nous ! J'ai additionné des kg et des litres. Mais, je ne vois pas bien comment faire. J'ai considéré la densité des liquides égale à 1. On pourrait limiter la somme uniquement aux ingrédients en kg. Mais, du coup, on n'intègre pas le poids des liquides (après tout, ce n'est peut-être pas bien gênant). En fait, j'ai besoin de cette masse totale pour calculer le prix de la recette au kg.
- Prix à la part : effectivement aucun intérêt.
A ma connaissance, il n'y a pas de coefficient « P.V.H.T : coût des marchandises » obligatoire. Mais, on peut très bien le prévoir.
Quant à la notion de sous-recette, cela permet de limiter la liste "Appel d'une recette existante". Cette liste contiendra toutes les recettes qui auront la case cochée pour la catégorie en cours.
Il reste à gérer, lors de l'intégration des ingrédients de la (ou les) recette(s) successives choisies dans la liste, la notion de doublon des ingrédients.
L'idée de créer une liste pour la progression est également intéressante. Cela évitera de la saisie qui n'est pas la tâche la plus intéressante.
J'espère avoir répondu clairement et précisément à tes interrogations.
Bonsoir macgyver44,
Il suffit d’ajouter un total P.R. au pied du sous-formulaire qui liste les ingrédients.... 2 notions sont nécessaires : le prix de revient de l'ensemble de la recette et le prix de revient par personne
Je ne comprends pas l’intérêt de ces deux notions, surtout « Marge / PV TTC ».- La Marge en % sur TTC : Marge / PV TTC
- La Marge en % sur HT : Marge / PV HT
Qui demande cela ?
Ici aussi, je ne comprends pas la finalité.En fait, j'ai besoin de cette masse totale pour calculer le prix de la recette au kg.
Pour faire du pain :
1,000 kg de farine ;
0,042 kg de levure ;
0,025 kg de sel ;
0,600 kg d’eau
________
1,667 kg d’ingrédients et tu obtiens… deux pains de 600 gr !
Ce n’est pas obligatoire, mais : quand le contrôleur du fisc prétend qu’une partie de mon C.A. n’est pas déclarée, il se base sur ce rapport qu’il compare à celui qu’il a constaté chez d’autres restaurateurs de la même gamme. Il additionne les factures des fournisseurs de matières premières, café/thé, vins… il multiplie par les coefficients qu’il dit « normaux » pour déterminer un chiffre d’affaires « de référence » et la discussion commence… Les fiches techniques te servent à organiser ta défense.À ma connaissance, il n'y a pas de coefficient « P.V.H.T : coût des marchandises » obligatoire.
À mon avis, c’est cher payer pour réduire cette liste :Quant à la notion de sous-recette, cela permet de limiter la liste "Appel d'une recette existante". Cette liste contiendra toutes les recettes qui auront la case cochée pour la catégorie en cours.
- il faut gérer une notion supplémentaire ;
- quand on constatera que l’item souhaité n’est pas dans la liste, il faudra d’abord corriger pour le qualifier de sous-recette et ensuite recommencer la manœuvre d’import.
À ta place, je chercherais plutôt un moyen pour trouver vite en limitant la liste à la volée en complétant un champ avec un mot-clé.
Exemple : on veut importer une recette et on se souvient que « saumon » figure dans le nom. On saisit « saum » dans un champ et la liste se déplie avec les seules recettes qui contiennent la chaine « saum » dans leur nom.
Une piste : utiliser le formatage conditionnel pour allumer en rouge les ingrédients en doublon. Un contrôle avec comme source une fonction qui compte le nombre d’occurrences de l’ingrédient. Si différent de 1, on allume en rouge !Il reste à gérer, lors de l'intégration des ingrédients de la (ou les) recette(s) successives choisies dans la liste, la notion de doublon des ingrédients.
Bonjour Claude,
Oui bien sûr c'est possible, mais je trouvais plus esthétique de le faire apparaître dans la partie Recette.Il suffit d’ajouter un total P.R. au pied du sous-formulaire qui liste les ingrédients.
Effectivement, cela n'a pas grand intérêt. On peut les laisser tomber ainsi que la masse totale.Je ne comprends pas l’intérêt de ces deux notions, surtout « Marge / PV TTC ».
Sur cette notion de coefficient sur le PVHT, j'ai bien compris la nécessité de disposer d'un tel champ.Ce n’est pas obligatoire, mais : quand le contrôleur du fisc prétend qu’une partie de mon C.A. n’est pas déclarée, il se base sur ce rapport qu’il compare à celui qu’il a constaté chez d’autres restaurateurs de la même gamme...
La case à cocher sous-recette est un peu "tordue". Il est effectivement préférable d'effectuer une recherche sur un mot-clé comme tu le suggères afin d'obtenir la liste souhaitée.À mon avis, c’est cher payer pour réduire cette liste...
Enfin, pour le contrôle des doublons, si je comprends bien :
- tu effectuerais une vérification des ingrédients en double avant leur importation
- si il apparaît que certains ingrédients sont déjà saisis, le champ s'allume en rouge
Je connais la mise en forme conditionnelle mais je ne vois pas bien comment réaliser les deux actions ci-dessus.
A quel moment a lieu l'ajout des données lorsqu'il n'y pas doublon ?
Bonjour macgyver44,
Non, le mécanisme serait général : dès qu'il y a doublon, ça s'allume.Enfin, pour le contrôle des doublons, si je comprends bien :
- tu effectuerais une vérification des ingrédients en double avant leur importation
- si il apparaît que certains ingrédients sont déjà saisis, le champ s'allume en rouge
Je connais la mise en forme conditionnelle mais je ne vois pas bien comment réaliser les deux actions ci-dessus.
A quel moment a lieu l'ajout des données lorsqu'il n'y pas doublon ?
Que ce doublon vienne d'une importation ou d'un encodage manuel "traditionnel".
Dans l’exemple en annexe, vois :
- la fonction Doublon.
- dans sfPlatIngredients, le contrôle (caché) txtDoublon et le format conditionnel de txtIngredient.
Claude,
C'est excellent. Je n'arrivais pas à imaginer comment faire.
En fait, je pensais attribuer une double clé primaire sur les champs idPlat et idIngredient de la table tblPlatsINgredients. Du coup, il était impossible d'avoir un ingrédient en double au sein d'une même recette.
Cette solution me convient très bien.
Il me semble qu’on a fait le tour des besoins pour cette partie du projet.
Peux-tu poster une db compatible Access2000,
- avec les tables utiles (on ajoutera les colonnes au fur et à mesure que l’on progresse : fournisseurs…) ;
- le formulaire des recettes ?
Bonjour Claude,
J'ai essayé de résumer un peu tout ce qui a été évoqué depuis le début de la discussion dans la bd ci-jointe concernant la partie recettes.
Réactions à brule-pourpoint.
- REWAOUH !
-J’ai un message à l’ouverture du formulaire avec Access2000 :
Probablement une fonctionnalité d’Access2010, non disponible dans Access2000. Mais je ne perçois pas de conséquence.
- Pour le calcul du PVHT, tu divises par 1.07, il serait préférable de considérer le taux de TVA comme un paramètre : il peut varier dans le temps (crise oblige) et est différent d’un pays à l’autre (12 % actuellement en Belqique).
- Je vois que tu as retenu la notion de « PV normal », mais actuellement vide.
Note : j’appelle « Prix de Vente Normal », celui qui respecterait une politique de prix, par exemple (au hasard) :
pour une entrée : un coefficient 2.5 et un prix minimum de 6.25 €,
pour un plat : coefficient 3.0, minimum 8.75 €,
pour un dessert : coefficient 4.00, minimum 3.75 €.
Le PVN est le prix qu’on voudrait pouvoir imposer, le PV TTC est celui qui est réaliste, en fonction des prix de la concurrence et de ce que le client est d’accord de payer !
- Coefficient (actuellement vide).
- Photo : tu as prévu un champ texte dans la table (pour le chemin ?). On pourrait convenir que les photos sont logées dans un sous-répertoire de celui de la db et que leur nom correspond à l’idPlat avec une extension commune. Exemple pour le tiramisu : « 1.jpg »
- Pour faire encore plus joli, on pourrait moduler la hauteur du sous-formulaire en fonction du nombre d’ingrédients à afficher pour la recette.
==========
Je dispose probablement de plus de temps de loisir que toi (privilège de l’âge !), ne bouge à rien, je reviens dans quelque temps avec une proposition.
Bonjour Claude,
Merci !- REWAOUH !
A priori, il semble que ce soit une erreur de référencement dans l'éditeur VBA (effectivement due à la version 2010). Il faut remplacer "Microsoft Office 14.0 Acess database engine..." par "Microsoft DAO 3.6 Object Library. J'ai testé sur une version 2003 (je n'ai plus 2000 !) et maintenant c'est correct. Mais je pense que tu as déjà dû trouver !-J’ai un message à l’ouverture du formulaire avec Access2000
C'était bien mon idée, mais je n'ai pas pris le temps de l'intégrer. D'autant plus que nous avons 2 TVA : 7% sur les solides et liquides non alcoolisés et 19,6% sur les alcools.Pour le calcul du PVHT, tu divises par 1.07, il serait préférable de considérer le taux de TVA comme un paramètre
Je n'arrive pas à retrouver les résultats dans l'image du post #2 avec les règles que tu indiques.- Je vois que tu as retenu la notion de « PV normal », mais actuellement vide.
- Coefficient (actuellement vide).
Idem pour le coefficient et la marge.
Cela me convient très bien.- Photo : tu as prévu un champ texte dans la table (pour le chemin ?). On pourrait convenir que les photos sont logées dans un sous-répertoire de celui de la db et que leur nom correspond à l’idPlat avec une extension commune. Exemple pour le tiramisu : « 1.jpg »
Excellente idée, mais je ne sais pas comment faire.- Pour faire encore plus joli, on pourrait moduler la hauteur du sous-formulaire en fonction du nombre d’ingrédients à afficher pour la recette.
Bonjour macgyver44,
Oui, mais ici seul le taux "solide" intervient.C'était bien mon idée, mais je n'ai pas pris le temps de l'intégrer. D'autant plus que nous avons 2 TVA : 7% sur les solides et liquides non alcoolisés et 19,6% sur les alcools.
Tu verras que j'ai ajouté une table tblParamètres et une série de fonctions dans la version que je vais bientôt poster.
Actuellement en Belgique : 6 % sur la partie "Nourriture" de la note et 21 % sur le reste.
Pour tes autres remarques, je suis occupé à les intégrer. Idem pour les recherches.
Une nouvelle version probablement dans la journée...
Rebonjour Macgyver44,
Je suis reparti de ta db. (À quoi sert la macro « Sauvegarder » ?)
J’ai modifié/complété les relations (la suppression en cascade = risque d’ennuis en cas de fausse manœuvre).
J’ai ajouté :
- des tables (tblParametres…) ;
- des fonctions (dont le calcul du PVN et du coefficient) ;
- le processus pour les photos, les images qui décorent le formulaire et la modulation de la hauteur du sous-formulaire ;
- la recherche par critères.
Je propose que tu vérifies que, fonctionnellement, cela répond aux objectifs.
Pas de problème si – dans un premier temps – tu ne comprends pas trop comment j’ai procédé, je viendrai expliquer si nécessaire quand on sera OK pour cette phase (peut-être sous la forme d’un article si d’autres forumeurs manifestent leur intérêt pour une explication plus exhaustive).
Attention, maintenant il faut ajouter dans le répertoire de la db un sous-répertoire « Images » avec les .jpg.
On peut télécharger ici la db et les images.
Bonsoir Claude,
Je n'ai qu'un mot : bravo !
La macro "Sauvegarder" est un reste de la première version que tu as envoyée. Je ne savais pas non plus à quel usage elle était destinée. C'est pourquoi, j'ai jugé utile de la conserver.
Je n'ai pas encore parcouru l'ensemble du code mis en place mais cela fonctionne parfaitement. Je pense pouvoir comprendre la majorité du code. Si j'ai un problème, je te fais signe.
La programmation de la modulation de la hauteur du sous-formulaire est vraiment astucieuse, et tout le reste d'ailleurs…
Au sujet de la partie "Recherche par critères", y-a-t-il une explication particulière sur le code couleur employé (vert / orange) ?
Cela répond à 100% aux objectifs fixés.
Bonjour Macgyver44 et les autres (s’il en est !),
@ Macgyver44
La macro est sans importance : un vieux truc que j’avais oublié. J'ai supprimé.Envoyé par macgyver44
Pour les couleurs, c’est pour signaler s’il s’agit d’un choix strict (recherche limitée aux items de la liste) ou d’un choix élargi (items de la liste ou une chaîne de caractères). Respectivement vert et orange.
@ tous ceux intéressés par le sujet
À ce stade des réflexions, voici le formulaire :
- Ce formulaire est polyvalent :
il permet d'ajouter, de modifier et de supprimer une recette (la section Détail en gris clair et foncé) ;
il permet de rechercher les recettes qui répondent à certains critères (la section En-tête en bleu).
- La taille du sous-formulaire s'ajuste en fonction du nombre d'ingrédients.
- Les ingrédients mentionnés en doublon sont allumés en rouge.
- Lors de la confection d'une nouvelle recette, on peut importer, en un clic, les ingrédients d'une recette « modèle » existante.
- Un double-clic sur la photo miniature du plat provoque l'affichage de celle-ci dans sa dimension originale en utilisant le logiciel que l'utilisateur a associé à l'extension « jpg » (pour autant que son navigateur soit Explorer).
----
Voyez cet article – en cours d’élaboration – pour trouver plus de détails sur le fonctionnement et les techniques mises en place.
----
La base de données et les images peuvent être téléchargées ici.
Le dossier « Images » doit être logé dans le répertoire de la base de données.
La base de données est en cours de construction, assurez-vous de télécharger la dernière version.
Suggestions et critiques sont les bienvenues.
Bonjour Claude,
Ce tuto est une excellente formalisation de notre discussion.
Bonjour macgyver44,
OK, je crois qu’on s’approche de quelque chose d’opérationnel pour la fiche Recette.
Il y a deux points névralgiques : le prix des ingrédients et les quantités.
Nous devrions réfléchir sur deux axes :
- comment organiser la mise à jour des prix unitaires ;
- comment contrôler la pertinence des quantités renseignées dans les fiches des recettes.
Tout n’a pas la même importance. Si dans la fiche de la recette on s’est trompé dans la quantité de sel ou qu’on a valorisé la farine au prix qu’elle coûtait il y a six mois, ça n’a guère de conséquences. Par contre renseigner 125 g de filets de sole alors qu’en réalité on en met 150 sur l’assiette et si en plus le PR est basé sur les prix d’il y a un mois… il vaut mieux ne plus se servir de l’outil !
Voici le schéma de réflexion auquel je pense :
• Sur la base des factures d’achats de matières premières, on encoderait les prix et les quantités des ingrédients « à suivre ».
- On pourrait ainsi mettre à jour les prix dans tblIngredients.
- Enregistrer une entrée dans le stock de cet ingrédient.
- Établir des statistiques par fournisseur.
• Sur la base des plats vendus, on pourrait calculer la consommation théorique de chaque ingrédient « à suivre ».
Anciens stocks + Entrées réelles – consommations théoriques = la quantité qui devrait rester.
On compare alors l’inventaire physique avec l’inventaire théorique et on se pose les bonnes questions en cas d’écart significatif :
- cela vient-il d’une erreur dans la quantité renseignée à la fiche Recette et on corrige celle-ci s’il échet ;
- commet-on des erreurs en cuisine, plats ratés à jeter ;
- cela vient-il de matières périssables que l’on a dû jeter ? Si oui, c’est intéressant d’en garder une preuve pour justifier une perte vis-à-vis d’un contrôle fiscal éventuel ;
- cela vient-il de matières qui disparaissent, auquel cas, il faut resserrer des boulons !
Es-tu d’accord avec cette démarche ?
Bonsoir Claude,
Tu as poussé l'analyse très loin.
A l'origine, je ne pensais pas faire aussi compliqué. Je pensais simplement gérer les stocks à partir de l'inventaire et des achats. C'était beaucoup plus léger.
Ceci dit, ta démarche est vraiment complète et je ne peux qu'être en accord avec tes propositions. Je suppose que tu as déjà des idées pour mettre en place cette partie. De mon côté, je ne sais pas trop par quel bout commencer.
Répondre avec citation
Partager