Modélisation base de données fabrication produits

Bonsoir à toutes et à tous.

Je me tourne vers vous afin d'obtenir vos conseils pour créer une base de données concernant des informations de fabrication de produits.

Mon entreprise fabrique des produits à partir de différents éléments (Matières premières, Additifs)
L'utilisation des produits est réglementé et pour cela nous définissons une catégorie d'utilisation (un seul choix possible sur 5 disponibles) ainsi que les animaux cibles (plusieurs choix possibles).
Ces produits produits peuvent répondre ou non à un objectif nutritionnel (liste de 30 choix possibles).
De plus nous définissons un mode d'emploi du produits.

Mon soucis c'est que je n'arrive pas à modéliser la base pour pouvoir créer un produit avec un formule spécifique contenant:
- la liste des matières premières utilisées (code interne, désignation) ainsi que les pourcentages dans la composition
- la liste des additifs (Type d'additifs, code réglementaire, désignation, source) et qté par kg de produit
- la liste des constituants analytiques (dépend de la catégorie, de la composition et de l'objectif nutritionnel), une liste avec un choix multiple et la possibilité de renseigner pour chaque constituant analytique sa teneur.
- la liste de acides aminés(désignation et teneur) si présent dans le produit.

Je joins un fichier excel présentant les différentes données définissant un produit.

Par avance merci de votre aide et vos conseils

Bonjour,

Un début d'ébauche de modèle:
Pièce jointe 255607

tProd: produits fabriqués
tTmp : types de matière première (matière première, additif, ...)
tMP: les matières premières
tObjNut: les objectifs nutritionnels
tProdMp: matières premières entrant dans les produits
tProdQNut: les objectifs nutritionnels des produits

A partir de tProdMp il sera possible de lister tous les éléments entrant dans chaque produit
A partir de tProdQNut il sera possible de lister tous les objectifs nutritionnels de chaque produit

A développer.
Point particulier: comment intégrer les unités (kg, %, ...)

Bonne continuation.

Merci EricDgn pour la base,

les unités concernent les quantités de MP, Add, ...., présent dans un produit(formule).
Cette unité peut êre différente selon le produit fini.
En rajoutant un champ par l'assistant liste de choix dans la table tPropMp, penses tu que cela soit gérable?

Autre question, comment faire pour gérer les version des formules produits en cas de modification d'une formule tProd.
Est-il possible de créer une table qui servirait d'archive pour les différentes version de formules?

Quel tuto utiliser pour créer un formulaire me permettant de renseigner une formule avec toutes les informations?

Par avance merci de votre réponse.

Bonjour,

Citation:

---

les unités concernent les quantités de MP, Add, ...., présent dans un produit(formule).
Cette unité peut êre différente selon le produit fini.
En rajoutant un champ par l'assistant liste de choix dans la table tPropMp, penses tu que cela soit gérable?

---

Oui, cela devrait convenir. Il faut sans doute aussi décider si la base fera une gestion de stock ou pas.
Dans le modèle ci-dessous, le stock pourrait être suivi. Si pas utile, supprimer les 2 champs [Mp_UnNum] et [MpQ] de la table tMp.
Pièce jointe 255773
De même il faut décider si ce projet va aussi établir les coûts des formules.
Je suppose quand même que stock et coûts sont déjà suivis avec d'autres applications.

Citation:

---

gérer les version des formules produits

---

C'est tout à fait possible. Il suffit de prévoir dans la table tProd des champs qui enregistrent la date fin [PrDatFin] et le numéro du produit remplacé [Pr_PrNum]. Il sera possible de créer un processus qui recopie la recette ancienne, à laquelle il faudra seulement aller corriger le/les éléments modifié/s.

Citation:

---

créer un formulaire me permettant de renseigner une formule avec toutes les informations

---

En fait, un formulaire consiste pour l'essentiel à "présenter" d'une façon agréable le résultat d'une requête. Il faut donc commencer par construire la/les requête/s qui contiennent les informations souhaitées. Cela fait, on crée le/s formulaire/s de présentation/utilisation.

Citation:

---

Quel tuto ?

---

Il y a vraiment de nombreux tutoriels disponibles, dont ceux présentés sur ce site: Les meilleurs cours et tutoriels Access. Il y en aussi un tas d'autre sur YouTube.
Personnellement, pour apprendre je préfère avoir un document "papier" à côté de mon pc: livre ou tutoriel imprimé !

Bonne continuation.

Bonjour,

La finalité de la base de donnée est la gestion de la documentation technique et règlementaire des différents produits.
Les différentes évolutions peuvent venir d'une modification règlementaire ou d'une modification de formule.

J'ai modifié la base Pièce jointe 255801

J'ai donc rajouté un table avec les unités.

Pour la gestion des version je rajoute donc une date de début et de fin d'utilisation d'une formule avec la raison de la modification.
Sera-t-il possible ensuite de récupérer l'historique des modification des formules.
Autre problématique possible, la modification impacte une MP, cette modification va impacter l'ensemble de formules contenant cette MP ainsi que tout les documents, comment peut on gérer les modifications de version des formules?

Merci de ton aide

Bonjour,

J'ai un peu continué à regarder comment organiser les données, et abouti à cette ébauche de modèle:
Pièce jointe 255830
qui permet de produire une requête donnant en résultat la composition résultant d'un mélange de "matières premières" (avec cependant une petite contrainte: il faut exprimer chaque partie apportée par une matière première en % du produit final).

Citation:

---

Sera-t-il possible ensuite de récupérer l'historique des modification des formules.
Autre problématique possible, la modification impacte une MP, cette modification va impacter l'ensemble de formules contenant cette MP ainsi que tout les documents, comment peut on gérer les modifications de version des formules?

---

A mon avis si la composition d'une MP change, pour conserver un historique il faudra recréer tous les produits affectés. Cela devrait pouvoir s'effectuer assez facilement à l'aide d'une macro (y compris l'indication du motif). Il est d'ailleurs possible que le changement de composition d'une MP entraine une modification des % de l'une ou l'autre des autres MP entrant dans la fabrication de certains des produits.

Pour faciliter la compréhension des liaisons entre tables, personnellement je place systématiquement les 1 à gauche et les n (infini) à droite.

Tant que le "modèle" de la base de données n'est pas bien établi, il n'est pas nécessaire d'y mettre beaucoup de données. Y mettre juste assez pour tester.

Bonne continuation.

Bonsoir,
Je vous remercie pour le début de ce développement.

Personnellement la gestion de stock de Mp dans cette BDD ne me servira pas car mon but est de pouvoir créer une base de donnée me permettant de tenir à jour l'ensemble de la documentation des produits finis (Environ 50 produits et pour chaque produits entre 5 et 10 documents selon les demandes)

Citation:

---

qui permet de produire une requête donnant en résultat la composition résultant d'un mélange de "matières premières" (avec cependant une petite contrainte: il faut exprimer chaque partie apportée par une matière première en % du produit final).

---

Actuellement, je reçoit des formules définies sur lesquelles j'ai la composition exprimée en % de MP dans le produit fini.
J'ai les valeurs des constituants analytiques pour le produit fini. J'ai donc crée la table tProdCn afin de pouvoir définir les constituant analytiques des PF.
A partir de ces informations, je dois définir l'ensemble des informations pour l'ensemble des documents. (Mode d'emploi, constituants analytiques, composition, liste des additifs,vitamines,antioxydants,....)
Les constituants analytiques n'ont donc pas besoin d'être liés aux matières premières mais uniquement au produits finis.

Pièce jointe 256130

La documentation que je dois gérer est faite dans 6 langues différentes pour la majeur partie, certains produits sont traduits en 10 langues.
Peux-ton intégrer dans chaque table la traduction des informations dans différentes langues ou faut-il crée pour chaque table une table dans chaque langue concernée?

Pièce jointe 256136

Citation:

---

A mon avis si la composition d'une MP change, pour conserver un historique il faudra recréer tous les produits affectés. Cela devrait pouvoir s'effectuer assez facilement à l'aide d'une macro (y compris l'indication du motif). Il est d'ailleurs possible que le changement de composition d'une MP entraine une modification des % de l'une ou l'autre des autres MP entrant dans la fabrication de certains des produits.

---

Toute modification d'une MP entraine la modification de la formule concernée.
Une autre obligation de modification peut venir de la règlementation qui modifie des informations que nous devons reprendre dans nos différents documents.
La gestion des version et historique me permettra de garder un historique des formules et des versions des documents.

Citation:

---

Pour faciliter la compréhension des liaisons entre tables, personnellement je place systématiquement les 1 à gauche et les n (infini) à droite.

---

Merci pour cette information, cela m'a permis de mieux comprendre rapidement l'interaction des différentes tables.

Pièce jointe 256140

Bonjour,

Si je comprends bien, l'objectif de la bd est de produire des étiquettes et des notices d'utilisation, et d'en conserver l'historique.
Les données spécifiques à la constitution des textes ne m'apparaissent pas clairement dans les tables actuelles. Je ne retrouve cela que dans la table tObjNut.
Dans cette table, dans le champ [ObjNutAutInd], il est mentionné 2 choses: "Indiquer sur l'emballage: ..." et "Indiquer dans le mode d'emploi: ..."
A mon avis il faudrait distinguer autant de champs qu'il y a d'indications (de rubriques) à prévoir pour une étiquette, pour un mode d'emploi.
A noter qu'un champ Texte ne peut contenir que 255 caractères au maximum. Les textes inscrits à titre d'exemples dans le champ [ObjNutAutInd] sont déjà de 245 caractères. S'il en faut plus, il faudra utiliser des champs Memo (avec ses avantages et ses inconvénients).
Il faudra donc tester en prenant l'étiquette la plus complète/compliquée et le mode d'emploi le plus complet/compliqué à élaborer pour vérifier qu'il est vraiment possible de les établir.

Pour ce qui est langues, je suis d'avis que les diverses traductions doivent se trouver dans une même table, cela pour être absolument certain d'éviter toute erreur au niveau des identifiants (éviter que le texte n° 1256 dans une langue ne corresponde pas au texte traduit n° 1256 d'une des autres langues). Il pourrait cependant y avoir autant de tables que de catégories d'information.

Bonne continuation.

Bonjour,

Citation:

---

Si je comprends bien, l'objectif de la bd est de produire des étiquettes et des notices d'utilisation, et d'en conserver l'historique.

---

Oui, nous réalisons énormément de documents différents soit avec une partie ou l'ensemble des informations contenues dans cette base. (Fiches techniques, certificats, fiches de vérification d'étiquetage, documents règlementaires,...)

Citation:

---

Les données spécifiques à la constitution des textes ne m'apparaissent pas clairement dans les tables actuelles. Je ne retrouve cela que dans la table tObjNut.

---

Les différentes rubriques utilisées peuvent être listées comme ci dessous.
Nom du produit, Catégorie du produit, Animaux cibles, Objectif Nutritionnel, Poids unitaire ou volume unitaire,Durée d'utilisation, Composition (en mg/kg et mg/unité), Constituants analytiques acides aminés (selon règlementation), Additifs (selon la règlementation) oligo-éléments, vitamines, microorganismes, substances aromatiques,......,Posologie, Mode d’emploi, Condition de conservation, Date Limite d’Utilisation Optimale*(DLUO), Autres mentions (selon obligations règlementaire) de 1 à 10 obligations, Adresse du responsable de l’étiquetage - commercialisation, N° Fabricant Vétalis, Tableau d'apports journaliers

Citation:

---

Dans cette table, dans le champ [ObjNutAutInd], il est mentionné 2 choses: "Indiquer sur l'emballage: ..." et "Indiquer dans le mode d'emploi: ..."
A mon avis il faudrait distinguer autant de champs qu'il y a d'indications (de rubriques) à prévoir pour une étiquette, pour un mode d'emploi.
A noter qu'un champ Texte ne peut contenir que 255 caractères au maximum. Les textes inscrits à titre d'exemples dans le champ [ObjNutAutInd] sont déjà de 245 caractères. S'il en faut plus, il faudra utiliser des champs Memo (avec ses avantages et ses inconvénients).

---

La table tObjNut me permettra d'avoir la liste des obligations concernant les critères auxquels les produits doivent répondre et d'avoir les information concernant l’étiquetage des produits. Je l'ai donc séparé en deux tables, une contenant le nom de l'objectif et une deuxième contenant les obligations.
Quels sont les avantages et les inconvénients d'un champ Memo ?

Citation:

---

Pour ce qui est langues, je suis d'avis que les diverses traductions doivent se trouver dans une même table, cela pour être absolument certain d'éviter toute erreur au niveau des identifiants (éviter que le texte n° 1256 dans une langue ne corresponde pas au texte traduit n° 1256 d'une des autres langues). Il pourrait cependant y avoir autant de tables que de catégories d'information.

---

J'ai renseigné quelques tables avec des champs dans les différentes langues, pour le moment 4 mais à terme il y en aura 10 au moins.
C'est pour cela que je me demande si j'ai bien compris votre conseil concernant l'intégration des langues.

Sera-t-il possible de créer un document dans une langue définie par sélection des champ par différentes requêtes ou bien faudrat-il que je crée les document à l'aide de la fonction Etat ?

Par avance merci de votre aide.

Pièce jointe 256792

Bonjour,

Je pense préférable de laisser momentanément la partie gestion des langues sur le côté. Il sera assez simple de construire un code qui fait basculer les textes d'une langue dans une autre. Donc, commencer par obtenir ce que l'on veut en français.

Pour construire une étiquette, il faut nécessairement passer par des requêtes. Etats et formulaires ne sont que des "présentations" de résultats de requêtes.

Sinon, le découpage des tables m'a l'air ok.

Il faudrait donc maintenant essayer de construire les requêtes qui vont permettre d'avoir les données à imprimer dans une étiquette (ensuite même chose pour une notice d'utilisation) et en afficher les résultats dans des formulaires grossiers. Il faut vraiment éviter de passer trop de temps à fignoler des formulaires tant que l'on n'est pas encore certain du bon découpage des tables, et à ce stade oublier les états.

Points de détail: pour les noms, mettre en première lettre t pour table, r pour requête, f pour formulaire, sf pour sous-formulaire, e pour état et jamais d'accent ni d'espace (à remplacer par _).

Bonne continuation.

Bonjour,

Je vous remercie grandement pour votre aide, cela me permet d'apprendre beaucoup de choses sur Access.
Ce que je pensai simple au départ peut s'avéré bien complexe, mais je veux réussir à finaliser cette base de donnée.

Citation:

---

Je pense préférable de laisser momentanément la partie gestion des langues sur le côté. Il sera assez simple de construire un code qui fait basculer les textes d'une langue dans une autre. Donc, commencer par obtenir ce que l'on veut en français.

---

J'ai supprimé les informations des différentes langues.

Citation:

---

Pour construire une étiquette, il faut nécessairement passer par des requêtes. Etats et formulaires ne sont que des "présentations" de résultats de requêtes.

---

Je rajoute un document type afin de voir un type de document que nous réalisons.
Pièce jointe 260184

Citation:

---

Sinon, le découpage des tables m'a l'air ok.

---

Lorsque je reçoit une formule, j'ai les informations suivantes:
liste des MP utilisées (MP et additifs sans distinction), % de chaque composant, % des constituants analytiques et teneur en différents additifs.
A partir de ces informations, je doit pouvoir crée un ensemble de documents contenant différentes information et vérifier différentes obligations réglementaires (teneur en additifs, apport journalier max non dépassés, ...)

J'ai rajouté une table pour le mode d'emploi car celui-ci peut être différent selon les animaux cibles d'un produit.
Est-il possible de créer une table avec l'ensemble des informations d'étiquetage que nous utilisons et de sélectionner celles que nous mettons sur un produit ?

Je pense qu'il faudrait créer une table spécifique pour les constituants analytiques car les teneurs sont spécifiques à un produit ou utiliser la table tCn

Pour les teneurs en additifs, je pense également devoir faire un table pour enregistrer les teneurs pour chaque produits.

Est-il possible de crée des tableaux (apports journalier) en réalisant des calculs avec les teneurs de certaines mp et / ou additifs?

Citation:

---

Il faudrait donc maintenant essayer de construire les requêtes qui vont permettre d'avoir les données à imprimer dans une étiquette (ensuite même chose pour une notice d'utilisation) et en afficher les résultats dans des formulaires grossiers. Il faut vraiment éviter de passer trop de temps à fignoler des formulaires tant que l'on n'est pas encore certain du bon découpage des tables, et à ce stade oublier les états.

---

Pour les requêtes, j'ai commencé mais j'ai encore quelques soucis avec les liaisons des tables dans les requêtes et l'imbrication d'une requête dans une autre.

Encore merci de votre aide

Pièce jointe 260181

Oui, cela ne sera pas si simple. Il y a vraiment beaucoup de variantes à gérer !

En général il faut mettre des liaisons de type 2 ou 3. Une liaison de type 1: un à un, signifie qu'il n'y a que 1 enregistrement avec le même identifiant dans chacune des 2 tables (et dans ce cas, il faut vérifier l'utilité d'avoir 2 tables et non une seule).
Exemple de type 2: Inclure TOUS les enregistrements de la table « tModEmplAnim » et seulement ceux de la table « tProdAnim » pour lesquels les champs joints sont égaux.

Il y a quelque chose qui ne va pas avec les tables tObjNut et tObjNutObl par rapport à l'objectif ultérieur d'avoir d'autres langues. A mon avis une seule table devrait suffire, en indiquant bien tout de suite les champs "en français" (…fr), les champs des traductions devant être ajoutés ultérieurement. Dans l'attaché, la table tObjNutObl a été supprimée (après ajout de champs dans tObjNut). A regarder.

Ai modifié les propriétés de la zone de liste déroulante de tMp_tTmp dans table tMp.

Il y a aussi une question relative aux tables tModEmplAnim et tObjNut. Quelles différences y a-t-il entre les modes d'emploi mentionnés dans ces 2 tables.

Table tModEmplAnim: un même mode d'emploi pourra-t-il être utilisé pour plusieurs animaux-cibles différents (ce que laisse supposer la liaison avec la table tProdAnim).

Cordialement.

Citation:

---

Oui, cela ne sera pas si simple. Il y a vraiment beaucoup de variantes à gérer !

---

Oui je confirme, il y a beaucoup de choses à gérer pour la création de la documentation. :arf:
la règlementation nous impose beaucoup de choses à faire apparaitre sur les packaging des produits, c'est pourquoi j'ai crée la table ObjNutImportExcel qui est une importation du fichier excel avec lequel nous travaillons actuellement.
Il y a environ 5 à 6 textes qui concerne cette problématique.

Citation:

---

Il y a quelque chose qui ne va pas avec les tables tObjNut et tObjNutObl par rapport à l'objectif ultérieur d'avoir d'autres langues. A mon avis une seule table devrait suffire, en indiquant bien tout de suite les champs "en français" (…fr), les champs des traductions devant être ajoutés ultérieurement. Dans l'attaché, la table tObjNutObl a été supprimée (après ajout de champs dans tObjNut). A regarder.

---

Pour le moment, et afin d'éviter de me perdre, il vaut mieux construire la base en français et une fois développée, introduire les traductions.

Citation:

---

Il y a aussi une question relative aux tables tModEmplAnim et tObjNut. Quelles différences y a-t-il entre les modes d'emploi mentionnés dans ces 2 tables.

---

La table tModEmplAnim correspond, par analogie aux médicaments, à la posologie recommandée pour l'utilisation du produit selon l'espèce animale.
La table tObjNut reprend les obligations réglementaires concernant les informations à faire apparaitre sur le packaging du produit.

Citation:

---

Table tModEmplAnim: un même mode d'emploi pourra-t-il être utilisé pour plusieurs animaux-cibles différents (ce que laisse supposer la liaison avec la table tProdAnim).

---

Non, les doses et les quantités varie selon l'espèce et le type d'animal.

J'ai également crée une table avec les apports maximum journalier pour chaque oligo éléments. est-il possible de calculer à partis des informations rentrées dans la base produit avec les teneur en MP le dépassement ou non de ces limites selon les animaux concernés et l'oligo-élément désiré.

Je vais créer un récapitulatif de toutes les obligations concernant l'étiquetage des produits et je vais essayer d'intégrer cela dans la base de donnée.
Vaut-il mieux l'intégrer selon le texte réglementaire ou bien crée une base avec toutes les obligations et venir cocher celles qui correspondent aux produits?

J'ai intégré dans l'archive des présentation de documents.

Cordialement.
Pièce jointe 263104

Si un mode d'emploi est spécifique à un animal-cible, il faudrait faire le lien au niveau des modes d'emploi plutôt qu'au niveau du produit.
Par ailleurs il me semble qu'il y a à la fois
- un "mode d'emploi",
- des "précautions d'emploi selon réglementation", et
- des "précautions d'emploi selon objectifs nutritionnels"
et que cela devrait être ramené dans la même table.
Après avoir renommé la table (juste pour avoir des libellés aussi court que possible), cela donne
Pièce jointe 264149
Difficile de dire si cela convient vraiment.
Il faudrait maintenant faire des ébauches de formulaires et d'états pour vérifier que l'on peut effectivement rassembler convenablement les informations.
Bonne continuation !

Je reviens sur le forum après un petit moment d'absence, le projet est toujours d'actualité pour ma part.

J'ai créé des Etats, de formulaires de des requêtes pour avoir un aperçu des données que je peux extraire.
Dans l'état eProdMp, je n'arrive pas a faire apparaitre la liste es mp du produit sous forme de liste avec comme séparateur une virgule.
Cette présentation sous forme de liste continue me sera utile dans d'autre états.

Est-il possible d'exporte une partie des informations dans un modèle de document Word, si oui comment faire ? (Certificat de libre vente)

Citation:

---

Si un mode d'emploi est spécifique à un animal-cible, il faudrait faire le lien au niveau des modes d'emploi plutôt qu'au niveau du produit.

---

Le mode d'emploi correspond à la posologie pour chaque animal, le terme posologie ayant une connotation médicamenteuse, nous ne désirons pas l'utiliser.

Citation:

---

Par ailleurs il me semble qu'il y a à la fois
- un "mode d'emploi",
- des "précautions d'emploi selon réglementation", et
- des "précautions d'emploi selon objectifs nutritionnels"
et que cela devrait être ramené dans la même table.

---

Les précautions particulière concernant les obj nut sont spécifiques à un obj nut, je pense qu'il est préférable de les intégrer dans la table tobjnut
Pour les autres obligations règlementaires, est-il possible de créer une table avec l'ensemble des précautions dans laquelle nous viendrons cocher une case définissant les obligations se rapportant au produit?

Merci de votre aide précieus dans l'avancement de ce projet.

Pièce jointe 274936

Bonjour,

Pour ce qui est de créer une liste des mp sur une ligne, une solution est d'utiliser la fonction décrite sur ce post: QueryFieldAsSeparatedString (à placer dans un module).
Comme elle va donner la même ligne pour chaque mp contenue dans le produit, dans le sous-état il faudra indiquer qu'il faut "masquer les doublons" si le champ calculé est mis dans la partie Détail. Une autre façon est de placer ce champ calculé en tête de groupe, ce qui fait qu'il ne viendra qu'une seule fois (solution utilisée en attaché).

Pour le reste, je n'ai pas vraiment encore regardé.

Bonne continuation.

Ajout 17/5: voir également ce post: Concaténer plusieurs enregistrements dans une seule colonne

Bonjour,

Pour l'export vers Word, c'est tout à fait possible. Un tutoriel: Le publipostage avec Access
Il est aussi possible de faire un simple export d'un état vers un fichier Word (onglet Données externe, groupe Exporter, bouton Word).

Pour le reste, c'est également faisable.

Bonne continuation.