Discussion :

[macgyver44]

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.

[ClaudeLELOUP]

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 (EnForceEnVeilleCaduqueEnForce…)

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…).

[macgyver44]

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.

[ClaudeLELOUP]

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 ».

[macgyver44]

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.

[ClaudeLELOUP]

Bonsoir macgyver44,

... 2 notions sont nécessaires : le prix de revient de l'ensemble de la recette et le prix de revient par personne

Il suffit d’ajouter un total P.R. au pied du sous-formulaire qui liste les ingrédients.

- La Marge en % sur TTC : Marge / PV TTC
- La Marge en % sur HT : Marge / PV HT

Je ne comprends pas l’intérêt de ces deux notions, surtout « Marge / PV TTC ».
Qui demande cela ?

En fait, j'ai besoin de cette masse totale pour calculer le prix de la recette au kg.

Ici aussi, je ne comprends pas la finalité.
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 !

À ma connaissance, il n'y a pas de coefficient « P.V.H.T : coût des marchandises » obligatoire.

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.

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.

À mon avis, c’est cher payer pour réduire cette liste :
- 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.

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.

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 !

[ClaudeLELOUP]

Bonjour macgyver44,

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 ?

Non, le mécanisme serait général : dès qu'il y a doublon, ça s'allume.
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.

[macgyver44]

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.

[ClaudeLELOUP]

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 ?

[macgyver44]

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.

[ClaudeLELOUP]

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.

[ClaudeLELOUP]

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 ?

[macgyver44]

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.

[ClaudeLELOUP]

Bonsoir Macgyver44,

Je pensais simplement gérer les stocks à partir de l'inventaire et des achats.

Je ne comprends pas, peux-tu donner un peu de détail ?


La proposition n'est pas techniquement très compliquée à mettre en place. Mais avant de commencer, il faut se demander quel effort administratif, l'utilisateur est d'accord de consentir pour tirer profit de l'outil.
Concrètement, il devra faire trois choses :
- à la réception de chaque facture, il faut encoder les quantités et prix des ingrédients « sensibles » ;
- on doit aussi encoder les quantités de plats vendus ;
- dresser l’inventaire des ingrédients sensibles en stock (par exemple toutes les semaines).
Si on décide de mettre un tel système en place, on doit concevoir les formulaires pour que l’encodage soit le moins fastidieux possible.

[macgyver44]

Bonjour Claude,

Je pensais simplement gérer les stocks à partir de l'inventaire et des achats.
Je ne comprends pas, peux-tu donner un peu de détail ?

A partir des factures d'achats, je pensais saisir les prix des ingrédients afin de mettre à jour les fiches recettes, mais pas les quantités. C'est par l'inventaire que je pensais mettre à jour les quantités (donc les stocks) sans tenir compte de la vente des plats. Mon analyse était réductrice.

Il est donc plus rigoureux de suivre ta démarche.

Si on décide de mettre un tel système en place, on doit concevoir les formulaires pour que l’encodage soit le moins fastidieux possible.

Bien sûr, il faut faciliter au maximum les saisies et les mises à jour pour l'utilisateur.

[ClaudeLELOUP]

Bonsoir Macgyver44,

Voici une proposition.
L’idée c’est de limiter l’encodage des achats aux ingrédients
- dont le coût a une influence significative sur le prix de revient des recettes ;
- dont on veut comparer le stock théorique avec le stock effectif.
On prévoira un autre moyen pour introduire les prix des ingrédients « non suivis ».



Renvois
1. Ceci fait référence au document qui sert de base à l’encodage (sans doute une facture). L'utilisateur saisit n’importe quelle valeur de son choix qui lui permettra de retrouver facilement la pièce. Par ex. le N° d’inscription au facturier des achats.
2. Les données susceptibles d’être identiques pour le poste suivant à encoder sont mises par défaut.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
Private Sub cboFournisseurFK_AfterUpdate()
  Me.cboFournisseurFK.DefaultValue = Me.cboFournisseurFK
End Sub
Private Sub txtDateAchat_AfterUpdate()
  Me.txtDateAchat.DefaultValue = "#" & Format(txtDateAchat, "mm/dd/yy") & "#"
End Sub
Private Sub txtRefAchat_AfterUpdate()
  Me.txtRefAchat.DefaultValue = txtRefAchat
End Sub

3. Cette donnée servira pour le processus d’inventaire. Éventuellement négative pour une note de crédit.
4. Cette donnée servira à la mise à jour du prix dans tblIngredient. Nécessairement supérieure à 0.

5. Calculé et affiché pour permettre un contrôle du montant facturé.

La fermeture du formulaire provoque la mise à jour de tblIngredients.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Private Sub Form_Close()
  'Mettre à jour le prix des ingrédients
  DoCmd.SetWarnings False
  DoCmd.OpenQuery "r02CreatblTempDernAchats"
  DoCmd.OpenQuery "r03MaJtblIngredients"
  DoCmd.SetWarnings True
End Sub

Si un virtuose du SQL passe par ici, il pourra nous aider à réduire le nbre des requêtes.
La démarche est la suivante :
- pour chaque ingrédient, on détermine d’abord la date du dernier achat



- on crée une table temporaire contenant l’id de l’ingrédient, le dernier prix et la date.



N.B. On doit passer par la création d’une table tampon, car s’il s’agissait d’une requête de sélection, elle ne pourrait servir pour mettre tblIngredients à jour :



- on met à jour tblIngredients






Dans la table tblIngredients, j’ai ajouté une colonne « DateDernAchat », on adaptera le formulaire F_Recettes pour alerter si cette date est trop ancienne (par exemple pour les ingrédients « non suivis ».


Qu'en penses-tu ?

J'adapterai la note explicative en fonction de tes commentaires.


La db mise à jour est ici.

[ClaudeLELOUP]

Bonjour chers lecteurs,

Macgyver44 et moi avons échangé quelques e-mails afin de réduire la longueur de ce fil.
Cela nous a permis de corriger quelques imperfections.
Voici où nous en sommes :
- le formulaire F_Recettes a peu évolué : le prix est maintenant coloré d’orange si la date du dernier achat se situe dans un passé plus éloigné que le paramètre « DelaiPrixActu » (dans tblParametres).
- le formulaire F_Achats se présente comme ceci :





Les points délicats sont :
- le report du prix le plus récent dans tblIngredients ;
- le traitement des corrections d’erreurs éventuelles dans des enregistrements anciens.

Le fonctionnement est décrit en détail dans la note de synthèse que vous pouvez consulter ici. Vous y trouverez également le lien pour télécharger la DB qui a servi à la mise au point.

Vos réactions sont bienvenues.

[ClaudeLELOUP]

Bonjour,
Macgyver44 et moi avons continué nos échanges…
Nous avons ajouté un formulaire pour saisir le nombre de plats vendus :



Le formulaire nous permet donc de comptabiliser les ventes date après date. Ces données nous serviront à calculer la consommation théorique de chaque ingrédient composant le plat.
À ce stade,








- Nous pouvons donc calculer les quantités de chaque ingrédient qui ont – en théorie – été mises en œuvre pendant une période.



- Nous avons d'autre part comptabilisé les achats d'ingrédients. Nous pouvons donc calculer les quantités d'ingrédients achetées pendant une période





« La » question : le stock effectivement constaté correspond-il à la théorie ?

Concrètement, si en début de période
• nous avions x kg de dos de cabillaud,
• que nous en avons acheté y kg
• et que, théoriquement, nous en avons utilisé z kg,
est-ce que dans le frigo, il reste bien (x + y - z) kg ?

Voici le formulaire qui fait un nœud avec toutes ces données :



On y affiche pour chaque ingrédient que l’on décide de suivre, ce qui devrait, théoriquement, se trouver en stock (inventaire précédent + achats de la période – consommations de la période).
L’utilisateur complète la colonne « Inventaire » avec les quantités qu’il constate réellement.
La colonne « À justifier » affiche la différence et « Commentaire » permet d’y consigner l’explication.
Deux fonctionnalités à signaler : un double-clic sur un montant « Achats » ou « Consom » affiche le détail dans un formulaire qui s’ouvre juste en dessous du montant cliqué (ou au-dessus, si la place n’est pas disponible à l’écran).



Conclusion

L'ensemble de ces quatre outils :
- les fiches recettes ;
- l'enregistrement des achats d'ingrédients « à surveiller » ;
- l'enregistrement des plats vendus ;
- l'analyse de l'inventaire
permet de maitriser la composition du coefficient, l'une des clés de la rentabilité d'un restaurant.
Access convient très bien pour la réalisation d'une telle application.

À cette adresse, vous trouverez tous les détails et la base de données.

Remarques et suggestions sont les bienvenues.

Cordialement,
Macgyver44 et ClaudeLELOUP

[foster53]

Bonjour à tous,
j'ai lu avec intérêt le tuto de Claude et ai commencé à utilisé la base de donnée créée.
Je tente de l'adapter à mon projet de table d'hôte. En clair j'ai supprimé la partie "Inventaire" qui n'a que peu d’intérêt dans ce cas.
Je bloque sur un détail concernant les taux de TVA...
En effet dans les recette le prix de vente HTVA est calculé à directement dans le formulaire à partir du tx TVANour. Hors je souhaite pouvoir proposer des menu/recettes avec vin et apéritif.... J'aurais donc aimé pouvoir lier directement chaque ingrédient à un taux de TVA (peut-être en ajoutant à la table ingrédient un champs CategorieIng?) puis ajouter au sous-formulaire IngredientRecette une colonne avec le prix TTC de chaque Ingrédient.

Concrètement, admettons que je souhaite proposer une Recette "Ardoise du terroir" avec:
- 150g de gigot de brebis fumé
- 150g de terrine d'agneau aux noisettes
- 150g de saucisson de brebis
- 150g de Chaource
- 150g de Langre
- 120mL de Champagne
- 120mL de Bourgogne Rouge

Dans ce cas il faudrait appliquer au tx à 20% uniquement pour le champagne et le bourgogne...

Merci d'avance pour vos réponses.

[miranacdg]

Bonsoir,
Je viens de voir votre fil de discussion qui m'intéresse beaucoup car je suis sur ce même projet aujourd'hui: rapprochement des fiches techniques avec les ventes, le stock, la marge
N'auriez-vous pas une version Excel par hasard? Je suis sur Mac et je n'ai malheureusement pas Access.

Cordialement

Mirana R.