Discussion :

[delphin4512]

Bonjour,

J'essaie de mettre en place une base qui permette de gérer les stocks (quantité - lot - date péremption) en fonction de ce qui est utilisé en production puis envoyé au client. Je n'ai pas besoin de toutes les notions de prix, temps, gestion du personnel...
Pour les entrées en stock, j'ai crée une table avec les champs suivants : N°automatique, Date réception, N°BL fournisseur, N° commande, Code société, Code article, Quantité livrée, unités, n° lot , date péremption, statut, dérogation, stock.
En parallèle, j'ai aussi les tables Article, fournisseur, famille article, lieu de stockage, une table client.

Les articles que nous réceptionnons sont utilisés pour fabriquer des produits; Plusieurs articles sont utilisés dans la fabrication d'un produit. Les articles peuvent être communs à plusieurs produits. Il y a des semi ouvrés c'est à dire des produits fabriqués qui peuvent ensuite être utilisés pour la fabrication d'un produit qui sera ensuite commercialisé. Chaque produit ou semi fini a une composition connue et reste toujours identique un peu comme une recette.
Quand on lance une fabrication, il doit y avoir un débit des stocks articles et des semi finis avec leur numéro de lot et date de péremption (très important). Le produit fabriqué doit être" libéré" pour être disponible pour la vente au client.
Je souhaiterai pour gérer le traçabilité de chaque article, semi fini, produit fini, chaque lot.
Je souhaiterai générer l'ordre de fabrication et les bons de livraison au client et pouvoir identifier le chacun des stocks (article, semi fini, produits finis, ...)

Mes connaissances sont assez basiques en access. Est ce que quelqu'un peu m'aider?
Si vous avez besoin précisions, n’hésitez pas à me demander.
Merci beaucoup pour votre aide

[delphin4512]

Bonsoir à tous,

s'il vous plait, j'ai vraiment besoin d'un petit coup de pouce pour mon problème. est ce que quelqu'un peut m'aider?
Merci pour votre aide.

[Oppenheimer]

Bonjour !
Access a des possibilités limitées en termes de processus industriel. Il faut garder à l'esprit qu'une base de données ne représente pas les traitement. Une solution de contournement consiste évidemment à exploiter vos champs date. Une requête permettrait de comparer les date, ou de sélectionner les dates d'une table qui sont supérieures à celles d'une autre.

Bonjour,

J'essaie de mettre en place une base qui permette de gérer les stocks (quantité - lot - date péremption) en fonction de ce qui est utilisé en production puis envoyé au client. Je n'ai pas besoin de toutes les notions de prix, temps, gestion du personnel...
Pour les entrées en stock, j'ai crée une table avec les champs suivants : N°automatique, Date réception, N°BL fournisseur, N° commande, Code société, Code article, Quantité livrée, unités, n° lot , date péremption, statut, dérogation, stock.
En parallèle, j'ai aussi les tables Article, fournisseur, famille article, lieu de stockage, une table client.

Ca m'a l'air pas mal du tout; vous avez même pensé à séparer la catégorie (FamilleArticle).

Les articles que nous réceptionnons sont utilisés pour fabriquer des produits; Plusieurs articles sont utilisés dans la fabrication d'un produit. Les articles peuvent être communs à plusieurs produits. Il y a des semi ouvrés c'est à dire des produits fabriqués qui peuvent ensuite être utilisés pour la fabrication d'un produit qui sera ensuite commercialisé. Chaque produit ou semi fini a une composition connue et reste toujours identique un peu comme une recette.
Quand on lance une fabrication, il doit y avoir un débit des stocks articles et des semi finis avec leur numéro de lot et date de péremption (très important). Le produit fabriqué doit être" libéré" pour être disponible pour la vente au client.
Je souhaiterai pour gérer le traçabilité de chaque article, semi fini, produit fini, chaque lot.
Je souhaiterai générer l'ordre de fabrication et les bons de livraison au client et pouvoir identifier le chacun des stocks (article, semi fini, produits finis, ...)

Mes connaissances sont assez basiques en access. Est ce que quelqu'un peu m'aider?
Si vous avez besoin précisions, n’hésitez pas à me demander.
Merci beaucoup pour votre aide

Si tous les gens qui font une table Access sans relation avouaient avoir des connaissances "assez basiques en Access" au lieu de persister dans l'erreur, la vie serait plus facile! Mais il me semble que vous avez néanmoins des compétences en modélisation, non?

Pour moi, dans une première vue ce matin, je considère que vous êtes sur la bonne voie. En ce moment, j'ai pas trop de temps, mais sachez que j'aurais du temps vers midi pour approfondir.

Juste: Si un produit nécessite plusieurs articles, mais qu'un article peut aussi être impliqué dans plusieurs produits, il vous faudra alors scinder cette relation plusieurs-à-plusieurs (qui empêche les correspondance), quitte à nommer cette table d'un nom artificiel (tbl_produit_article).

-Une question à se poser: Est-ce qu'un semi-ouvré peut mener à plusieurs produits finis ?

[delphin4512]

Bonjour,
Merci d'avoir répondu!!!

Bonjour !
Access a des possibilités limitées en termes de processus industriel. Il faut garder à l'esprit qu'une base de données ne représente pas les traitement. Une solution de contournement consiste évidemment à exploiter vos champs date. Une requête permettrait de comparer les date, ou de sélectionner les dates d'une table qui sont supérieures à celles d'une autre.

Ca m'a l'air pas mal du tout; vous avez même pensé à séparer la catégorie (FamilleArticle).

Oui effectivement j'ai fait une famille article.

Si tous les gens qui font une table Access sans relation avouaient avoir des connaissances "assez basiques en Access" au lieu de persister dans l'erreur, la vie serait plus facile! Mais il me semble que vous avez néanmoins des compétences en modélisation, non?

Je bidouille un peu, j'ai appris toute seule. j'arrive à faire des formulaires, des requêtes simples mais pas de codes.

Pour moi, dans une première vue ce matin, je considère que vous êtes sur la bonne voie. En ce moment, j'ai pas trop de temps, mais sachez que j'aurais du temps vers midi pour approfondir.

Juste: Si un produit nécessite plusieurs articles, mais qu'un article peut aussi être impliqué dans plusieurs produits, il vous faudra alors scinder cette relation plusieurs-à-plusieurs (qui empêche les correspondance), quitte à nommer cette table d'un nom artificiel (tbl_produit_article).

-Une question à se poser: Est-ce qu'un semi-ouvré peut mener à plusieurs produits finis ?

oui une semi ouvré peut mener à plusieurs produits finis.
Voici les relations que j'ai créées pour l'instant
relations tables 1.docx

Je pense que j'arrive à faire une entrée de stock d'articles . j'ai également défini la composition d'un article à fabriquer à savoir pour fabriquer un produit fini alpha, j'ai besoin :
- 0.5 unité article A
- 1 unité semi fini B
- 2 unités d'un article C
ce que je n'arrive pas à faire c'est je veux fabriquer 100 unités du produit alpha (en lui attribuant un n° lot, une date de péremption) et qu'il déduise automatiquement l'ensemble des éléments le composant en terme de quantité, n° lot. Je sais que c'est faisable car je l'ai déjà auparavant mais je n'arrive pas à le créer. Le lancement de cette production peut aller dans un stock production puis faire un mouvement de stock pour le libérer quand la production est fini et le mettre en stock PF.
Là j'avoue je suis un peu perdu pour la réalisation.
Si tu peux m'aider ce sera avec joie.
Merci d'avance.
Bonne soirée

[Oppenheimer]

Bonsoir Delphine,

J'ai lu votre message il y a un petit moment déjà, ainsi que les relations, mais j'ai dû m'absenter car une amie a vu des choses en chaîne dans mon marc de café. Mais bref, c'est une autre histoire.

Je serais ravi de vous aider plus à fond, mais je souhaite que vous équi-répartissiez vos tables de manière à ce que je puisse y voir le plus claire possible. J'ai compris que les tables "inter" étaient ces tables à clés étrangères (vous ne les composez pas en clé primaire ?), mais pour le reste, je m'interroge sur le sens de "MP".

-L'idéal serait que les tables intermédiaires figurent réellement entre les tables qu'elles lient (au sens géométrique, du schéma), et que les jointures s'entrecoupent le moins possible. Croyez-vous que vous arrivez à me faire ça ? -Si vous pouvez ensuite cliquer sur Rapport de relations, mettre en orientation Paysage, et imprimer cela en Pdf, de sorte que je puisse voir plus facilement, ce serait super.

Bonne soirée à vous aussi!

[delphin4512]

Bonjour,

Ci joint le schéma des relations plus clair (j'espère). Relations pour Gestion des stocks.pdf
Effectivement les tables inter n'ont pas de clés primaires. c'est nécessaire?
Pour les définitions :
Article ou MP (défaut de langage) : ce sont les éléments achetés à un fournisseur
Semi fini (abréviation SF) : ce sont les éléments fabriqués puis réutilisés dans la fabrication du produit fini
Produit fini ou PF : ce sont les éléments commercialisés

Qu'est ce que c'est une table à clé étrangère?

J'espère que ce sera plus clair pour vous.
Merci
bonne journée.

[Oppenheimer]

Bonjour Delphine,

Merci pour vos relations Pdf; je vais les voir d'ici 1-2 heures. (Je vous réponds depuis un téléphone mobile).

Les clés étrangères sont ce qui référence les clés primaires dans vos tables inter. Normalement, il y a possibilité de les composer comme une clé primaire - afin que la composition des deux soit unique, quand chacune des deux peut être répétée, séparément. Mais moi, ça me pose un problème de cardinalité; Access m'avertissant de ce problème. Du coup, je dois rajouter un "ID" numérique comme champ unique primaire. Si vous aviez pu composer vos étrangères en primaire avec succès, j'aurais été intéressé.

Quand j'aurai vu vos nouvelles relations, je répondrai à votre question spéciale, (il me semblait que vous en aviez une - je relirai).

À tout.

[Felykanku]

Bonsoir . Ton problème est accès simple. Pour plus des precisions Je vous r'envoie a l'adresse https://support.office.com/fr-fr/art...2-7e7e21e80c6b . Si Ca ne marche pas contacter Moi.

[Oppenheimer]

Bonsoir Delphine,

Je réponds plus précisément - enfin, j'essaie.

ce que je n'arrive pas à faire c'est je veux fabriquer 100 unités du produit alpha (en lui attribuant un n° lot, une date de péremption) et qu'il déduise automatiquement l'ensemble des éléments le composant en terme de quantité, n° lot. Je sais que c'est faisable car je l'ai déjà auparavant mais je n'arrive pas à le créer.

-Pour moi, le schéma que vous avez ne pose pas de problème, ou s'il y en a un, je ne vois pas où il est; (et il faudrait alors commencer à vous demander si vous avez fait un modèle conceptuel, puis un modèle logique (je connais la méthode Merise)).

Le lancement de cette production peut aller dans un stock production puis faire un mouvement de stock pour le libérer quand la production est fini et le mettre en stock PF.
Là j'avoue je suis un peu perdu pour la réalisation.
Si tu peux m'aider ce sera avec joie.
Merci d'avance.
Bonne soirée

Juste une question pratique; je suppose que le stock des articles n'est pas le même que celui des produits finis ? -Je pose la question comme ça.

Par contre, les Article ont une date de dernière réception, ce qui est bien, mais vos ProduitFini n'ont pas de tel attribut temporel. Pas étonnant en ces conditions que vous n'arriviez pas à gérer votre flux.

Selon votre configuration, peut-être que même le lieu de Stockage devrait avoir DateMiseEnStock, et DateDepartDuStock; à voir.

Il y a aussi les Semi_Finis qui ont un lieu de stockage non référencé.

-Pensez encore à composer vos clés étrangères en clé primaire. Ca ne coute rien d'essayer, c'est même un réflexe. Moi, j'obtiens un problèmes de discernement par Access de la cardinalité plusieurs, mais je n'arrive pas à détecter la racine de mon problème; ça devrait être faisable.

-Enfin, pensez à peupler vos tables, de disons 2 enregistrements tests à chaque fois, en commençant par vos tables Famille et Stock, puis Article et ProduitFini; enfin, vos tables intermédiaires.

[delphin4512]

Bonjour,

Merci mais ce lien ramène à comment faire un formulaire. mais ce n'est pas ce qui me gène pour l'instant.
Sauf si quelque chose m'échappe....

Bonsoir . Ton problème est accès simple. Pour plus des precisions Je vous r'envoie a l'adresse https://support.office.com/fr-fr/art...2-7e7e21e80c6b . Si Ca ne marche pas contacter Moi.

Bonne soirée

[Oppenheimer]

Bonjour,

Merci mais ce lien ramène à comment faire un formulaire. mais ce n'est pas ce qui me gène pour l'instant.
Sauf si quelque chose m'échappe....



Bonne soirée

Bonsoir Delphine,

La réponse de FelyKanku était hors sujet.

[delphin4512]

Bonsoir,

Effectivement les stock articles et les stocks produits finis sont des stocks différents

Ci joint l'ensemble des tables liés aux articles achetés entrant dans la composition des éléments fabriqués.Relations Articles.pdf
J'ai commencé à remplir ces tables. Les problèmes :
- Les champs Qté en stock, Qté en commande, Datedernière réception : comment fait on pour que le calcul se fasse?
Je souhaite fonctionner en FIFO (First in first Out). du coup je me demande si c'est vraiment la date de derrière réception dont j'ai besoin?

A ces tables sont associés les formulaires : Fiche_Article, Fiche_Fournisseur (avec un sous formulaire contact), Formulaire Réception_MP
Formulaires -1.docx

Sur la table des Produit fini, j'ai ajouté un champ Date_DerniereEntreeStock

Sur la table de Semi-finis j'ai ajouté la relation avec le lieu de stockage

J'ai aussi commencé à peupler mes tables, je ne l'avais pas précisé.

j'ai ajouté une clé primaire sur les tables intermédiaires sur vos conseils mais je n'ai pas compris leur rôle.
Relations pour Gestion des stocks-2.pdf

Est ce que cela correspond à ce que tu suggères?

Merci pour ton aide.
Bonne soirée

[Oppenheimer]

Bonsoir,

Effectivement les stock articles et les stocks produits finis sont des stocks différents

Ci joint l'ensemble des tables liés aux articles achetés entrant dans la composition des éléments fabriqués.Relations Articles.pdf
J'ai commencé à remplir ces tables. Les problèmes :
- Les champs Qté en stock, Qté en commande, Datedernière réception : comment fait on pour que le calcul se fasse?

-Je me posais la même question il y a un an. Mais une base de données ne devrait pas stocker de champ calculé à partir d'un autre, ni dérivé d'une autre manière, afin d'éviter la circonlocution, pour citer un problème bénin. Le mieux est de stocker des requêtes, qui vont s'assurer de refaire les calculs à la demande, au cas où des champ requis ont changé de donnée entre temps. À mon avis, c'est la meilleur méthode.

Je souhaite fonctionner en FIFO (First in first Out). du coup je me demande si c'est vraiment la date de derrière réception dont j'ai besoin?

Mmm... Il faudrait se demander la date de dernière réception: de quoi?

Vu votre schéma, il s'agit de parties d'articles, toutes requises - je pense donc que votre schéma est bon pour cela. Par contre, vous voulez sans doute parler des Article: une fois un article complété, il doit être le premier à partir au stock. C'est pourquoi une DateEntreeEnStock (sous stockage) ne me paraît pas superflue.

A ces tables sont associés les formulaires : Fiche_Article, Fiche_Fournisseur (avec un sous formulaire contact), Formulaire Réception_MP
Formulaires -1.docx

Sur la table des Produit fini, j'ai ajouté un champ Date_DerniereEntreeStock

-Il faut faire très attention au nom d'attribut. Si c'est un produit fini, c'est plutôt sa première entrée en stock à lui. Et est-ce vraiment un attribut de ProduitFini? -C'est vrai, je vous l'ai suggéré en dernier message, mais je me demande si ce ne serait pas plutôt un attribut du Stockage, répertoriant toutes les entrées et sorties.

Essayons de prendre du recul: Si le Stockage d'Article est toujours différent du Stockage de ProduitFini, cela fait-il vraiment sens de lier Article et ProduitFini à cette table selon le lieu ?
À mon sens, il faudrait plutôt lier Article et ProduitFini à Stockage selon DateDepartVersStock, le lieu restant un attribut-clé, vu qu'il différencie le Stockage exact.

Sur la table de Semi-finis j'ai ajouté la relation avec le lieu de stockage

J'ai aussi commencé à peupler mes tables, je ne l'avais pas précisé.

j'ai ajouté une clé primaire sur les tables intermédiaires sur vos conseils mais je n'ai pas compris leur rôle.
Relations pour Gestion des stocks-2.pdf

Est ce que cela correspond à ce que tu suggères?

Merci pour ton aide.
Bonne soirée

Rôle de la clé primaire composée de clés étrangères (pour des valuers de 0 à 1):

Code :

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

1
2
3
4
5
6
-----PK-----
--FK-||-FK2-
0    ||   0
0    ||   1
1    ||   0
1    ||   1

Les FK peuvent chacune être redondante, mais l'ensemble est unique - voilà le rôle de la PK:

Je n'ai pas encore regardé le détail. Je m'interroge sur les multiples fichiers de relations, mais je réponds sur Mac en ce moment, et ma souris a un mauvais comportement sur ce site; je vais sans doute re-démarrer sous Windows.

[Oppenheimer]

Je viens de voir les relation. Ca m'a l'air bien.

Par contre, penser à lier les éléments au Stockage selon les dates de transferts, (son lieu peut rester la clé de cette table).

[delphin4512]

Bonjour,

Voici mes dernières réflexions

-Je me posais la même question il y a un an. Mais une base de données ne devrait pas stocker de champ calculé à partir d'un autre, ni dérivé d'une autre manière, afin d'éviter la circonlocution, pour citer un problème bénin. Le mieux est de stocker des requêtes, qui vont s'assurer de refaire les calculs à la demande, au cas où des champ requis ont changé de donnée entre temps. À mon avis, c'est la meilleur méthode.

Cela à l'air logique. Je pense que les champs Qté en stock, Qté en commande, Datedernière réception (ce dernier champ sera à voir sur le point suivant) doivent être des requêtes dont le résultat s'affiche dans le formulaire (formulaire que j'ai nommé fiche Article); je vais essayer de le faire.
Du coup est ce nécessaire de laisser ces champs dans la table T_Article?

Mmm... Il faudrait se demander la date de dernière réception: de quoi?

dans ce cas c'était la dernière réception dudit article qui serait équivalente à la dernière entrée en stock. A mon avis elle a un intérêt de renseignement mais n'interviendra pas dans d'éventuels calculs pour du FIFO

Vu votre schéma, il s'agit de parties d'articles, toutes requises - je pense donc que votre schéma est bon pour cela. Par contre, vous voulez sans doute parler des Article: une fois un article complété, il doit être le premier à partir au stock. C'est pourquoi une DateEntreeEnStock (sous stockage) ne me paraît pas superflue.

Tout à fait je suis d'accord, je vais essayer

-Il faut faire très attention au nom d'attribut. Si c'est un produit fini, c'est plutôt sa première entrée en stock à lui. Et est-ce vraiment un attribut de ProduitFini? -C'est vrai, je vous l'ai suggéré en dernier message, mais je me demande si ce ne serait pas plutôt un attribut du Stockage, répertoriant toutes les entrées et sorties.

cet attribut est valable pour les deux à la fois pour les articles et pour les produits finis, voir les semi ouvrés. En effet, si il y a plusieurs lots d'un même article, les premiers lots d'articles entrée en stock seront les premiers lots utilisés pour la fabrication du produit fini (ou semiouvrés), De même, pour les premiers produits finis expédié au client.

Essayons de prendre du recul: Si le Stockage d'Article est toujours différent du Stockage de ProduitFini, cela fait-il vraiment sens de lier Article et ProduitFini à cette table selon le lieu ?

la table stock est surtout pour avoir des saisies cohérentes quand on indique le lieu de stockage. peut être ai je mal modélisé? ou il y a quelque chose que je n'ai pas encore saisie?

À mon sens, il faudrait plutôt lier Article et ProduitFini à Stockage selon DateDepartVersStock, le lieu restant un attribut-clé, vu qu'il différencie le Stockage exact.

Ne faudrait il pas que je crée une table de mouvement?

Rôle de la clé primaire composée de clés étrangères (pour des valuers de 0 à 1):

Code :

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

1
2
3
4
5
6
-----PK-----
--FK-||-FK2-
0    ||   0
0    ||   1
1    ||   0
1    ||   1

Les FK peuvent chacune être redondante, mais l'ensemble est unique - voilà le rôle de la PK:

Je n'ai pas encore regardé le détail. Je m'interroge sur les multiples fichiers de relations, mais je réponds sur Mac en ce moment, et ma souris a un mauvais comportement sur ce site; je vais sans doute re-démarrer sous Windows.

Le numéro de lot unique pourrait elle joué ce rôle?

Il y a un point qui est trouble pour moi. Comment faire pour que la fabrication d'un produit fasse déduire les articles du stock en fonction de la "recette" de la fabrication? une idée?
Merci et bonne soirée

[delphin4512]

Bonjour,
Finalement j'ai retiré la quantité en commande et la date de dernière réception car il n'y avait pas d’intérêt par rapport aux champs définis (on ne gère pas les commandes).
Par contre je souhaite conserver Qté en stock qui pour les stocks est important. Je n'ai pour l'instant pas réussi à faire la requête et l'insérer dans le formulaire mais je n'ai pas fini d'essayer.

Par contre je n'arrive pas à modéliser pour faire des débits de stock. je ne comprends pas comment faire pour créer un ordre de fabrication qui me débit les stocks d'articles et semi ouvré en fonction des quantités et numéros de lot présents dans les stocks avec gestion du FIFO. Je patoge....

Merci et bonne journée.

[Oppenheimer]

Bonjour Delphine!

Excusez, j'ai pris un week-end de libre, puis ai-je été absorbé par un problème fondamental - qui selon ma compréhension concernait le modèle logique, mais c'était pas évident en première approche (les réminiscences ont fini par me venir), d'ailleurs, pour mes interlocuteur, ce n'était pas forcément le cas.

J'ai en outre remarqué que ce qui était appliqué au modèle conceptuel ne l'était plus pour certain à partir du modèle logique! Ce qui fait craindre des pratiques biaisées.

J'ai finalement trouvé un contre-exemple qui invalidait ma proposition pour un cas particulier.

Je reviens à vous vers midi. À+.
--
Erratum: Je me suis trompé d'horaire, et reste.

[Oppenheimer]

Cela à l'air logique. Je pense que les champs Qté en stock, Qté en commande, Datedernière réception (ce dernier champ sera à voir sur le point suivant) doivent être des requêtes dont le résultat s'affiche dans le formulaire (formulaire que j'ai nommé fiche Article); je vais essayer de le faire.
Du coup est ce nécessaire de laisser ces champs dans la table T_Article?

-Selon moi, QteStock et QteCmd ne sont pas dérivées l'une de l'autre. Dans l'absolu, ça peut être le cas (un stock est une somme de commandes moins une somme de ventes), ce qui pourrait signifier qu'il ne faudrait jamais enregistrer le stock... Dans votre solution, je devine que vous n'avez pas l'opportunité de restaurer toutes les commandes et vente, à moins éventuellement de le faire depuis le début d'année, un peu comme le fait la compta.
Si vous concevez votre solution en un temps t quelconque, je pense que vous pouvez adopter le principe selon lequel le stock ne dérive pas des commandes, vu que vous partiriez d'un stock pré-existant, et que vous n'avez pas l'historique de toutes les commandes et ventes depuis la création de l'entreprise.

dans ce cas c'était la dernière réception dudit article qui serait équivalente à la dernière entrée en stock. A mon avis elle a un intérêt de renseignement mais n'interviendra pas dans d'éventuels calculs pour du FIFO

Je vous fait confiance.

cet attribut est valable pour les deux à la fois pour les articles et pour les produits finis, voir les semi ouvrés. En effet, si il y a plusieurs lots d'un même article, les premiers lots d'articles entrée en stock seront les premiers lots utilisés pour la fabrication du produit fini (ou semiouvrés), De même, pour les premiers produits finis expédié au client.

Mmm... Là, il y a plusieurs choses.

D'abord, il faut avoir conscience d'une "convention": d'aucuns pensent qu'une relation par date (en clé étrangère) n'est pas idéale. Il faut reconnaître que si c'est un horodatage à la seconde, rentrer ça pour une clé étrangère est fastidieux. Parmi eux, de hauts pontes penseraient même qu'il ne faut pas impliquer des clés naturelles (soit: ayant un sens intrinsèque). Ca semble contredire 3NF, mais ils rétorquent que 3NF parle de clés au niveau conceptuel, du coup, comme on est dans le modèle physique, ils s'autorisent à ré-introduire des dépendances transitives dont on avait voulu se débarasser précédemment. Vous n'êtes pas "obligée" de comprendre le détail, mais personnellement, je pense que si c'est pour agir ainsi, autant faire du NoSQL ou de l'Excel.

-Pour moi, cette partie n'est pas capitale. Par contre, quand je vous mentionnait qu'il ne fallait pas stocker de champ dérivé, ça incluait: pas de champ identique (l'identité étant une forme triviale de dérivation au sens de la logique); à moins de vouloir faire vos relations par dates, (je ne me rappelle plus exactement votre schéma), ce qui ramènerait au paragraphe juste ci-dessus - après, à vous de voir ce que vous pensez de la "convention".

À vrai dire, elle me paraît comme un mélange entre sécurité et aussi une pratique borderline, (ce n'est que mon point de vue). Il faut se demander si un employé lambda peut être amené à gérer la base de donnée. )À mon sens, cacher la clé à l'utilisateur, pour donner un exemple, serait une méthode suffisante, qui n'empêcherait des clés sémantiques.)

la table stock est surtout pour avoir des saisies cohérentes quand on indique le lieu de stockage. peut être ai je mal modélisé? ou il y a quelque chose que je n'ai pas encore saisie?

-Pour moi, comme dit, votre DB est correcte, mais je ne l'ai pas testée. Ce que je voulais dire, c'est que le lieu peut être la clé, par contre, pour les relations, peut-être une jointure selon la date. (Mais d'aucuns sont contre des relations par date, pour rappel).

Ne faudrait il pas que je crée une table de mouvement?

Cela me paraît antinomique. Pour rappel, une DB représente essentiellement l'aspect statique. Pour les traitements, il doit exister quelque chose d'autre, mais j'ai déjà du mal sur le plan théorique, (c'est plus compliqué que pour les données).

Le numéro de lot unique pourrait elle joué ce rôle?

-Je mentionnais cela pour vos tables "inter". J'ai finalement réussi à effectuer cela pour ma bibliothèque. Un numéro de lot n'est pas composé de divers champs (il me semble), et il concerne vos Article et non vos tables "inter", (si je me rappelle bien).

Il y a un point qui est trouble pour moi. Comment faire pour que la fabrication d'un produit fasse déduire les articles du stock en fonction de la "recette" de la fabrication? une idée?
Merci et bonne soirée

-Si le modèle que vous avez conçu est satisfaisant, tout va s'opérer par l'entremise des relations. Il faut bien garder en mémoire que vous voyez, sur le modèle Access, vos relations entre vos tables au sein desquelles figurent de noms d'attributs. Mais dans le concret, ces relations opéreront entre des enregistrements correspondants.

Donc si votre modèle est correct, vos relations devraient faire tout le boulot. (C'est ça l'avantage d'un SGBDR.)

[Oppenheimer]

Bonjour,
Finalement j'ai retiré la quantité en commande et la date de dernière réception car il n'y avait pas d’intérêt par rapport aux champs définis (on ne gère pas les commandes).
Par contre je souhaite conserver Qté en stock qui pour les stocks est important. Je n'ai pour l'instant pas réussi à faire la requête et l'insérer dans le formulaire mais je n'ai pas fini d'essayer.

Mmm... je comprends pour ce qui vous est nécessaire, mais si vous partez d'un stock, et que vous ne comptez que les débits, votre stock finira évidemment par atteindre zéro (ou un négatif), ce qui peut être déroutant.

Par contre, pour interagir avec un formulaire, on utilise généralement du VBA, et je ne connais pas suffisamment ce language.

Par contre je n'arrive pas à modéliser pour faire des débits de stock. je ne comprends pas comment faire pour créer un ordre de fabrication qui me débit les stocks d'articles et semi ouvré en fonction des quantités et numéros de lot présents dans les stocks avec gestion du FIFO. Je patoge....

Merci et bonne journée.

À mon sens, vous ne pouvez pas esquiver les commandes. Votre modèle me paraissait très bien! Mais vous devez passer par une phase de test, avec des données-tests, (c'est un rappel).

Si vous l'avez fait, essayez de décrire votre protocole (méthode) de la manière la plus élémentaire possible.

[delphin4512]

Bonjour,

Mmm... je comprends pour ce qui vous est nécessaire, mais si vous partez d'un stock, et que vous ne comptez que les débits, votre stock finira évidemment par atteindre zéro (ou un négatif), ce qui peut être déroutant.

Je me suis mal exprimée je pense. Évidemment je ferai une entrée de stock quand on recevra la marchandise pour alimenter mon stock (table_Réception MP)pour avoir un stock positif mais je ne gérerai pas une commande dans le sens ou la commande serait passée par ce base de données comme le ferait un ERP. Je me contenterai de faire l'entrée de stock.
Justement la grande question est comment je compte les débits. Je pense que quelque chose m'échappe.

Par contre, pour interagir avec un formulaire, on utilise généralement du VBA, et je ne connais pas suffisamment ce language.

D'accord. je ferai donc des recherches sur ce point.

À mon sens, vous ne pouvez pas esquiver les commandes. Votre modèle me paraissait très bien! Mais vous devez passer par une phase de test, avec des données-tests, (c'est un rappel).

Si vous l'avez fait, essayez de décrire votre protocole (méthode) de la manière la plus élémentaire possible.

Je vais faire ça : essayer de rentrer plus de données pour alimenter ma base. Ce que je n'arrive pas à comprendre c'est que pour les articles j'ai une fiche article (T_Article) qui défini mes articles achetés et une table T_Réception MP qui va servir pour mes entrées de stock.
J'ai des tables qui définissent mes Produits finis et semi ouvrés un peu comme des recettes mais j'ai rien pour faire les mouvements un peu comme l'équivalent de la table T_RéceptionMP . c'est normal?
Merci et bonne soirée