Bonjour a tous , jai vraiment un soucis avec une base de données qui ne fonctionne pas correctement et je voudrais reprendre les relations :
En fait s'agit de la gestion d'une entité cooperative qui achete un seul produit agricole avec des planteurs et pour realiser l'activité la cooperative finance les planteurs moyennant de l'argent et cest en ce moment que le planteur fait des livraisons de ce produit en question en vue de solder le financement recu , si le planteur livre plus qu'il n'a recu en argent , le reliquat lui ai payé et le financement est ralancé Dans le cas contraire le financement est complete en vue de le relancer enfin qu'il continue de travailler ; Une fois que un certain tonnage est atteint une remorque est chargée pour la vente du produit dans une Usine ( le client)
Je pense que nous allons nous arreter a ce niveau car cest la que reside mon probleme
En fait je souhaiterais que vous essayer de m'aider a identifier les differentes tables et les relations
On voudrais aussi savoir le stock de produit en magasin pour toutes les livraisons effectuèes sachant que nous avons qu'un seul produit
On voudrais aussi gerer les chargements effectués vers la ville
Nb: les produits de livrent en sacs
Et les sacs ont un poids brut
Et que le poids net du produit s'obtient en faisait la difference entre le nombre des sacs livrés et le poids brut
Je suis disposé a vous Donner de plus amples Infos si vous le voyez bien
Merci pour votre aide
Il y a donc 3 entités : les planteurs, la coopérative et les clients.
La première question qui me vient à l'esprit : un client peut-il acheter à la coopérative (ou la coopérative peut-elle livrer au client) des produits qui viennent de différents planteurs ?
Ex : 1 planteur X vient livre 3 tonnes de produit (c'est quoi d'ailleurs ce produit ?) en 4 fois :
1 livraison 1 tonne
1 livraison 0,5 tonne
1 livraison 0,8 tonne
1 livraison 0,7 tonne
Un client peut-il venir et acheter (ou se faire livrer par la coopérative) 1 tonne, composée de 0,3 tonne de ce planteur X et 0,4 tonne du planteur Y et 0,3 tonne du planteur Z ?
En gros, il y a t'il un lien (hormis la coopérative) entre le planteur et le client ?
La structure de ta base de données va dépendre, entre autres, de cette question...
Merci déjà pour l’intérêt que vous portez à ma préoccupation mais je pense que COOPÉRATIVE ne peut pas être une table car c'est elle qui gérè tout ce process que j’ai défini dans le sujet ; aussi ne pensez vous pas que les financements accordés au planteur ne doivent ils pas être suivi d’où la nécessité de considérer la table Financement qui sera numérote et daté ; qu'en est il de la table PRODUIT (cacao) pensez vous ce n'est pas nécessaire dans cette gestion ainsi que la table LIVRAISON( numeroté et daté aussi) c'est a dire celle effectuée par les planteurs enfin les différents DECHARGEMENT effectués par la coopérative auprès des CLIENTS ne doivent pas être pris en compte dans cette gestion aussi
NB: les planteurs livrent à la coopérative ; qui a son tour collecte et vend a un client
QU'EN PENSEZ VOUS
Je n'ai jamais dit qu'il fallait créer une table coopérative et je me posais uniquement la question sur le fonctionnement de la coopérative... Car d'un côté il y aura la gestion des produits arrivant à la coopérative, et de l'autre la gestion des produits sortant, puisque tu veux le stock...
Maintenant tu nous dis que les produits sortants (clients) ne doivent pas être gérés...
Donc, qu'en est-il exactement de ces sorties de cacao ?
Je nai pas dis que les produits sortants ne doivent pas etre gerés, je me demandais pourquoi vous n'avez pas pris en compte la Table DECHARGEMENT Dans votre gestion
Au finish vous me proposez quoi
tu me dis à l'instant :
e nai pas dis que les produits sortants ne doivent pas etre gerés
et 30 minutes avant :
enfin les différents DECHARGEMENT effectués par la coopérative auprès des CLIENTS ne doivent pas être pris en compte dans cette gestion aussi
Donc, ça commence mal, faut que ce soit bien défini à l'avance si tu veux quelque chose de "carré".
Dans "ma gestion", comme tu dis, je n'ai rien pris en compte, je posais justement des questions afin de pouvoir te donner mon avis.
Si tu t'attendais à que je te donne une structure toute faite et fonctionnelle sans poser de question, bah je ne suis pas un voyant, et ma boule de Cristal est cassée...
Donc, énonces clairement les contraintes et exactement ce que tu veux gérer et ne pas gérer, et ensuite, reviens avec quelque chose de clair.
bonjour,
peux-tu partager la base de données qui ne fonctionne pas correctement?
dans quel contexte fais-tu ce travail?
quelle aide attends-tu?
t'aider a identifier les différentes tables et les relations, ou le faire à ta place?
L'aide que jattends de vous cest de m'aider a identifier toutes les tables et de me proposer les relations entres les differentes tables ( oublions l'ancienne base )
Merci
as-tu appris une technique pour réaliser ce travail?
dans quel contexte fais-tu ce travail? quelle formation as-tu suivie?
tu écris: "jai vraiment un soucis avec une base de données qui ne fonctionne pas correctement".
après t'avoir aidé, je me demande si le soucis, ce n'est ton manque de connaissance dans l'utilisation de la base de données. et donc, que tu ne vas rien gagner à refaire la conception de la base.
1_Dans ctte gestion on souhaiterais gerer les financements donnés aux planteurs
2_ Les livraisons des planteurs
3 - la situation du solde de chaque planteur
4- les chargements effectués par la cooperative vers les clients
Le stock des produits ( entrees et series)
"" enfin les différents DECHARGEMENT effectués par la coopérative auprès des CLIENTS ne doivent pas être pris en compte dans cette gestion aussi ""
En fait cest une interrogation que je me pose parce que dans votre premiere analyse vous n'en avez pas fait cas ?
Encore une fois : je n'ai rien analysé !!!!!!!!!!!!!!!!!
Je te pose des questions pour pouvoir analyser.
Alors lis bien les questions, et quand toi, tu poses une question (une interrogation), mets un "?" à la fin, et essaies de couper tes phrases avec des "," et des ".".
Bjr et merci encore, est ce que le tout ne peut pas se faire en une gestion ? Je pense quil faut faire en une seule de sorte a pourvoir determiner le stock du cacao a une date donnée
si j'étais à ta place, je commencerais à compléter une liste de champs pour chacune des tables suivantes. la détermination des relations viendra ensuite.
voici le lien : https://www.cjoint.com/c/JIikheuOvS8 ; jai essayé de faire certains liens
jai pris en compte la table Section qui est en fait la section dans laquelle chaque planteur exerce et chaque section regroupe plusieurs Planteurs
et un planteur appartient à une et une seule SECTION
aussi jai pris en compte la table Vente car un Chargement constitue une vente mais je pense aussi à la Table PRODUIT car dans le cacao on y trouve plusieurs qualités ( ordinaire ; prémium ; Utz et rainforest) et pour la vente la qualité est importante
j'attends votre avis
merci
Oui je suis d'accord et comment se fera le lien avec les autres tables et qu'est ce que vous pensez d'une table produit au cas la cooperative integrait un autre produit comme le CAFE à son activité
Pour ce que est de la table produit; à part l' identifant ( idproduit) et la designation du produit ; quels pourraient etre les autres champs a ajouter a cette table et a quelle table pourrait Elle etre reliure?
je pense que la table PRODUIT contient seulment deux champs ( idproduit et la designationproduit) de plus elle sera liée à la table LIVRAISON et l a table CHARGEMENT
merci
Je pense qu'il est important de revenir sur la table CHARGEMENT et la VENTE ; en effet le nombre de sacs chargés et le poids brut chargés sont differents successivement du nombre de sacs dechargés a l'usine et du poids dechargés à l'usine et de retour de l'usine il y a un bon NUMEROTE pour chaque vente à l'usine qui est delivré à la cooperatve qui permet de constater les ecarts de sacs et de poids ; poids net payé
je ne suggérais pas d'enregistrer moins d'information: je suggérais de garder tous les champs, et de les enregistrer dans une seule table "livraison", ou "chargement/vente".
En fait , il est question pour la cooperative de saisir les chargements effectués puis au retour de la vente de saisir les informations de la vente en faisait appel a un chargement donné enfin de ressortir les encarts a partir du champ idchargement qui constitut un clé etrangere Dans la table vente ; en effet entre la date de chargement et la date de vente il y a deux a trois jours d'ou la neccessité de differentier les deux tables
Bjr, la table dechargement se renseigne en interne alors que celle de la vente neccessite le bordereau de vente venant de l'usine
Autre chose jai oublié de prendre en compte le Financement accordé a cette cooperative et les paiements de vente
je ne lis toujours aucune raison d'avoir deux tables séparées. si tu veux avoir deux tables, assure-toi, via une clé unique, qu'il n'y ait pas deux ventes liées au même chargement.
si un chargement est destiné à une seule société, il faudrait avoir un lien entre les tables Chargement et Societe, en remplacement du lien entre Vente et Société. Toutes ces informations ("un chargement est destiné à une seule société") devraient être documentées, visibles par tous.
Vous n'avez rien dit sur le financement accordé a la cooperative et les reglements
Selon vous les tables financement et reglement sont liés a quelles tables
Je pense qu'apres ca mon probleme serait resolu
Comprenez moi jai omis les financements et les reglements dans le sujet de depart
Je voudrais juste votre avis en tant que professionel pour me guider
Merci d'avance
je ne participe pas ici en tant que professionnel.
pour mieux te guider et pour te permettre d'apprendre, je te laisse réfléchir et faire une proposition pour les financements et les règlements.
par ailleurs, comme tu n'as presque rien documenté, nous pouvons uniquement vérifier ta logique, sans pouvoir vérifier si c'est conforme à la réalité et si cela te permettra de réaliser ce dont tu as besoin.
quelques remarques:
- mon commentaire en #35
- bizarre d'avoir le même nom de champ dans les tables Produit et TypeProduit.
- un financement ne peut jamais être remboursé?
en général,, je n'utiliserais pas non plus les mêmes noms de champ pour les deux champs liés (exemple: idSection dans table Section et idSection dans table Planteur.
le financement est remboursé lors des ventes effectuées par la cooperative par des prelevements continus ( mise en compte permetant de solder le financement) sur chaque vente .
exemple RETENUE FINANCEMENT= 10 f *poids net livré à l'usine
concernat les deux clés qui se repetent dans les tables ; je ne vois pas d'inconvenient ; si il y en a explique moi
l'inconvénient, c'est le manque de clarté. mieux, dans la table Planteur, de nommer un nom lié à la fonction, par exemple SectionOccupee.
"RETENUE FINANCEMENT", c'est dans quel table?
En fait la SECTION cest la localité ou bien le village dans lequel exerce le planteur
REGLE DE GESTION: 1-Dans une SECTION on trouve plusieurs planteurs
2 - un PLANTEUR exerce Dans une et une seule SECTION
Enfin le champ RetenueFInancement se trouve Dans la table VENTE enfin d'amortir le financement sur les differentes ventes
Quand un planteur prend un financement, il est lié par un contrat de livraisons de cacao sur un tonnage bien donné par rapport a un prix connu donc cest un engagement , cest pareil pour la cooperative vis a vis de la societe, en fait le compte se fait progressivement jusqu'a ce que les financements soient epuisés et le financement se remet en place pour toute une campage ; et generalement en fin de campage les comptes sont soldés de part et d'autres
oui generalement en fin de campagne dans le cas des societes les dernieres ou avant dernieres livraisons servent a solder les financements mais dans le cas des planteurs une mise en compte en aussi effectuée par la cooperative au fur et a mesure des livraisons et le solde se fait a chaque livraison du planteur ( montant financement - le montant de la viraison effectuéé- les mise en compte) et le financement est relancé soit en partie ou totalement ; en fait la mise en compte sert à parer a tous manquements du planteur
ok, si c'est bon pour toi que tous les paiements soient associés à un transfert de marchandise, c'est bon pour moi.
je n'ai pas vu la dernière version de ta conception.
et je rappelle mes deux premières remarques en #39.
si un chargement est destiné à une seule société, il faudrait avoir un lien entre les tables Chargement et Societe, en remplacement du lien entre Vente et Société. Toutes ces informations ("un chargement est destiné à une seule société") devraient être documentées, visibles par tous.
"" Toutes ces informations ("un chargement est destiné à une seule société") devraient être documentées, visibles par tous "" "" DOCUMENTES ET VISIBLES PAR TOUS "" cela veut dire quoi au juste ?
neanmoins ce que je voudrais preciser ; cest que une societé peut recevoir plusieurs chargements et la destination d'un chargement depend de la cooperative et de certaines faveur accordées à elle
"DOCUMENTES ET VISIBLES PAR TOUS", cela veut dire que cela doit être écrit quelque part, que cela puisse être lu, compris et approuvé par les différentes personnes impliquées dans le projet. le but étant de s'assurer que ces personnes comprennent et approuvent les choix faits à la conception de la base.
Bjr , la documentation se passe comment et comment est il presenté , pourrais je avoir un model pour m'en inspiré .
En ce qui concerne la table vente et dechargement, j'inssiste a les maintenir tels qu'ils sont actuellement
Dans l'ensemble est ce que vous pensez que les elements recherchés tels que le stock du cacao , le compte planteur et le compte client peuvent ils etre obtenus sans difficultés et de facon periodique
je pense qu'il sera possible d'obtenir les différents éléments recherchés. avec du travail, mais, probablement, sans difficultés.
pour vérifier cela, tu pourrais commencer par écrire des requêtes qui obtiennent ces éléments, et les tester avec des données de test.
ces requêtes te seront de toutes façons utiles par la suite, pour faire des rapports.
Vous avez dit "" obtenir les différents éléments recherchés. avec du travail, mais, probablement, sans difficultés. "" en fait de facon nominative quels sont les elements a rechercher de sorte que je puisse m'adresser à des personnes ressources, en ce qui concerne les requetes je fairai des test pour voir si ca marche bien
je vous ramene le lien :https://www.cjoint.com/c/JImkVtpJqMG jai ajouté une nouvelle table REFOULE qui correspond a la mauvaise qualité de cacao refoulé par le client et qui retourne dans le stock au magasin ( nombre de sacs ; le le poids refoulé)
aussi je veux savoir si la table FINANCEMENTSOCIETE pourait contenir la le champ ( idsociete)enfin de savoir le financement accordé par chaque sociéteé ; pareil pour la table REFOULE ; est ce quelle doit contenir le champ (idchargement )
je trouve normal que la table FINANCEMENTSOCIETE contienne le champ (idsociete). n'est-ce pas ainsi depuis le départ?
en ce qui concerne la table REFOULE, je ne peux pas vraiment aider, car tu n'as pas expliqué pourquoi la table chargement ne contient pas (idsociete). je ne comprends pas la logique des chargements et des ventes.
avec la structure que tu proposes, un chargement peut être vendu à un client, et refoulé par un autre: est-ce correct?
vous trouvez mal que la table FINANCEMENTSOCIETE Contienne idsociete ; mais pour la saisie d'un financement il faut bien choisir la société qui le donne ; sinon comment le financement de chaque société sera t'il distingué;
en ce qui est de la table CHARGEMENT ; je précise encore que le chargement se fait avant la vente et il peut avoir 2 à 3 jours d'intervalle et c'est une fois en ville qu'on décide d'aller dans telle ou telle société
enfin la vente du cacao peut engendrer un refoulement d'une partie du cacao et cela est dû a la mauvaise qualité du produit ; ce retour est retourné dans le stock au magasin ;
essayez de me faire des suggestions en modifiant les relations que je vous envoie mais pas des critiques seulement
merci
comme tu décris peu la situation, je pose des questions pour mieux t'aider à faire les bons choix.
par ailleurs, je t'explique les conséquences de tes choix.
je suggère, au moment où la société est choisie, de modifier le champ idSociete dans la table chargement. et de ne pas avoir de champ idSociete dans les tables refoulement ni vente. si le retour se fait après une vente, il serait aussi possible de lier le refoulement à la vente, et non pas au chargement.
je vous resume:
- ajouter le champ idsociete dans la table CHARGEMENT
-retirer le champ idsociete de la table VENTE
-relier les tables REFOULEMENT et VENTE;mais par quel champ ?
NB: la table REFOULEMENT n'a pas de champ idsociete
je proposais, en fait, deux possibilités:
la première, que je préfere:
- ajouter le champ idsociete dans la table CHARGEMENT
- retirer le champ idsociete de la table VENTE
la seconde, si tu veux garder le champ idSociete dans VENTE et pas dans CHARGEMENT:
- ajouter le champ idVente dans la table REFOULEMENT
- retirer le champ idChargement dans la table REFOULEMENT
bonsoir j’ai choisi la première option mais je constate que nous ne pouvons définir à quelle société une vente a été destinée , autrement je souhaiterais que nous mettions la clé idsociete dans la table VENTE
VOICI LE LIEN https://www.cjoint.com/c/JIuqT6Ca5LU Qu'en dites vous ?
