Je souhaite construire une base de données permettant de connaitre la
situation des comptes palettes de nos transporteurs et clients.
Quelqu'un a t-il SVP une idée sur la structure de la base, ce n'est ni plus
ni moins des nouvements d'entrée et de sortie, mais je coince que le champ
QTE_PAL.
Faut-il gérer 1 champ "Quantité" ou bien 2 champs "Quantité", car les
mouvements d'emballages peuvent se faire dans les 2 sens (ex: Livré 33 pal
et rendu 15 pal par le client)
Existe-t-il des exemples sur lesquels je pourrai me base?
A mon avis ta question est trop ouverte pour qu'on puisse y répondre. Il faudrait connaître mieux ton besoin.
Cordialement, pgz
3stone
Salut,
| Je souhaite construire une base de données permettant de connaitre la | situation des comptes palettes de nos transporteurs et clients. | Quelqu'un a t-il SVP une idée sur la structure de la base, ce n'est ni plus | ni moins des nouvements d'entrée et de sortie, mais je coince que le champ | QTE_PAL. | Faut-il gérer 1 champ "Quantité" ou bien 2 champs "Quantité", car les | mouvements d'emballages peuvent se faire dans les 2 sens (ex: Livré 33 pal | et rendu 15 pal par le client) | Existe-t-il des exemples sur lesquels je pourrai me base?
Il ne faut créer qu'un seul champ quantité ! Les sorties seront négatives et les entrées positives.
Avec cela, des requêtes simples permettent de connaître le stock : addition de toutes les valeurs les palettes chez chaque client: regroupement par client suivi de l'addition
Ne pas oublier les champs qui permettent de "tracer": dates, détruites... etc.
| Je souhaite construire une base de données permettant de connaitre la
| situation des comptes palettes de nos transporteurs et clients.
| Quelqu'un a t-il SVP une idée sur la structure de la base, ce n'est ni plus
| ni moins des nouvements d'entrée et de sortie, mais je coince que le champ
| QTE_PAL.
| Faut-il gérer 1 champ "Quantité" ou bien 2 champs "Quantité", car les
| mouvements d'emballages peuvent se faire dans les 2 sens (ex: Livré 33 pal
| et rendu 15 pal par le client)
| Existe-t-il des exemples sur lesquels je pourrai me base?
Il ne faut créer qu'un seul champ quantité !
Les sorties seront négatives et les entrées positives.
Avec cela, des requêtes simples permettent de connaître
le stock : addition de toutes les valeurs
les palettes chez chaque client: regroupement par client suivi de l'addition
Ne pas oublier les champs qui permettent de "tracer":
dates, détruites... etc.
| Je souhaite construire une base de données permettant de connaitre la | situation des comptes palettes de nos transporteurs et clients. | Quelqu'un a t-il SVP une idée sur la structure de la base, ce n'est ni plus | ni moins des nouvements d'entrée et de sortie, mais je coince que le champ | QTE_PAL. | Faut-il gérer 1 champ "Quantité" ou bien 2 champs "Quantité", car les | mouvements d'emballages peuvent se faire dans les 2 sens (ex: Livré 33 pal | et rendu 15 pal par le client) | Existe-t-il des exemples sur lesquels je pourrai me base?
Il ne faut créer qu'un seul champ quantité ! Les sorties seront négatives et les entrées positives.
Avec cela, des requêtes simples permettent de connaître le stock : addition de toutes les valeurs les palettes chez chaque client: regroupement par client suivi de l'addition
Ne pas oublier les champs qui permettent de "tracer": dates, détruites... etc.
J'ai monté une bd pareil à ce que tu semble avoir de besoin. Il y a de fortes chances que je puisse t'aider.
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
Si ça peut te sauver du temps, et que tu as le budget, l'application que j'ai crée est à vendre.
Bonne chance !
Jonathan
Bonjour !
J'ai monté une bd pareil à ce que tu semble avoir de besoin. Il y a
de fortes chances que je puisse t'aider.
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que
l'ont laisse des palettes chez un client et quand même temps ont en
charge d'autres. Alors il faut deux champs quantités pour garder trace
de toutes ces transactions.
Le deuxième problème est qu'il existe plusieurs modèles de palette
ayant chacune une valeur $$ différente alors il faut créer un champ
quantité double pour chaque type de palette.
Je te conseil de te créer une table détaillé de tes clients et de la
mettre en relation avec ta table où tu enregistre tes données.
Si ça peut te sauver du temps, et que tu as le budget, l'application
que j'ai crée est à vendre.
J'ai monté une bd pareil à ce que tu semble avoir de besoin. Il y a de fortes chances que je puisse t'aider.
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
Si ça peut te sauver du temps, et que tu as le budget, l'application que j'ai crée est à vendre.
Bonne chance !
Jonathan
3stone
Salut,
"borntoride" J'ai monté une bd pareil à ce que tu semble avoir de besoin. Il y a de fortes chances que je puisse t'aider.
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
Si ça peut te sauver du temps, et que tu as le budget, l'application que j'ai crée est à vendre.
Avec les conseils que tu donne ci-dessus, le prix doit être mini-mini ;-))
"borntoride"
J'ai monté une bd pareil à ce que tu semble avoir de besoin. Il y a
de fortes chances que je puisse t'aider.
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que
l'ont laisse des palettes chez un client et quand même temps ont en
charge d'autres. Alors il faut deux champs quantités pour garder trace
de toutes ces transactions.
Le deuxième problème est qu'il existe plusieurs modèles de palette
ayant chacune une valeur $$ différente alors il faut créer un champ
quantité double pour chaque type de palette.
Je te conseil de te créer une table détaillé de tes clients et de la
mettre en relation avec ta table où tu enregistre tes données.
Si ça peut te sauver du temps, et que tu as le budget, l'application
que j'ai crée est à vendre.
Avec les conseils que tu donne ci-dessus, le prix doit être mini-mini ;-))
"borntoride" J'ai monté une bd pareil à ce que tu semble avoir de besoin. Il y a de fortes chances que je puisse t'aider.
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
Si ça peut te sauver du temps, et que tu as le budget, l'application que j'ai crée est à vendre.
Avec les conseils que tu donne ci-dessus, le prix doit être mini-mini ;-))
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
=> non il faut un champ type de mouvement
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
=> non il faut un champ type de palette (code article quoi)
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
=> et une table détaillée du type de palettes, et une table détaillée de tarif avec dates de début et de fin de validité
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que
l'ont laisse des palettes chez un client et quand même temps ont en
charge d'autres. Alors il faut deux champs quantités pour garder trace
de toutes ces transactions.
=> non il faut un champ type de mouvement
Le deuxième problème est qu'il existe plusieurs modèles de palette
ayant chacune une valeur $$ différente alors il faut créer un champ
quantité double pour chaque type de palette.
=> non il faut un champ type de palette (code article quoi)
Je te conseil de te créer une table détaillé de tes clients et de la
mettre en relation avec ta table où tu enregistre tes données.
=> et une table détaillée du type de palettes, et une table détaillée de tarif avec dates de
début et de fin de validité
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
=> non il faut un champ type de mouvement
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
=> non il faut un champ type de palette (code article quoi)
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
=> et une table détaillée du type de palettes, et une table détaillée de tarif avec dates de début et de fin de validité
Encore une question, un peu plus administrative : Si je dispose de 2 quantités pour un seul échange de palette ou d'emballage, à savoir QUANTITE LIVREE ET QUANTITE RETOURNEE, la quantité livrée correspond à une sortie mais la quantité retournée par la client doit-elle être considérée comme une entrée (postive) ou bien comme une sortie mais négative ?
Voici la structure des tables que je compte créés :
Table ENTETE_MOUVEMENT : - N°Mvt : N° auto - Code Tiers : Client ou Fournisseur - Date mvt : - Type mvt : ENTREE (alimentation auto et saisie manuelle) ou SORTIE (Auto ou manuelle) - Origine mvt : Alimentation AUTO (à partir des BL d'un outil de gestion commerciale) ou Saisie Manuelle - Reférence : N° de bon de livraison ou N° de bon échange palette
Table DETAIL_MOUVEMENT - N° Mvt - TypePal : Type de palette ou d'emballage consigné - Qté1 - Qté2
Dans le cas d'une SORTIE, Qté1=Qté Livrée au tiers et Qté2=Qté Retournée par le tiers Dans le cas d'une ENTREE, Qté1=Qté Reçue par le fournisseurs et Qté2=Qté Retournée au fournisseur
Puis grace à une petite moulinette, je génère une table MOUVEMENT avec tous les champs des 2 tables ci-dessus mais avec un seul champs QTE, positif ou négative en fonction du sens de la transaction en étant plus précis dans les transactions c.a.d :
- si ENTREE et AUTO Transaction pour la QTE1 = ENTREE FOURNISSEUR et QTE2 = RETOUR FOURNISSEUR - si ENTREE et MANUEL Transaction pour la QTE1 = ENTREE DIVERSE et QTE2= SORTIE DIVERSES - si SORTIE et AUTO Transaction pour la QTE1 = SORTIE CLIENT et QTE2 = RETOUR CLEINT - si SORTIE et MANUEL Transaction pour la QTE1 = SORTIE DIVERSE et QTE2= ENTREE DIVERSE
J'avoue que c'est encore un peu flou dans mon esprit, et ne voudrais pas monter une usine à gaz car de cette structure dépendra tous les états et les formulaires d'interro et de saisie.
Merci de me donner votre opinion, et chapeau à ceux qui auront lu jusqu'au bout mon poème.
Bernard
<Anor> a écrit dans le message de news:
Bonjour,
"borntoride"
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
=> non il faut un champ type de mouvement
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
=> non il faut un champ type de palette (code article quoi)
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
=> et une table détaillée du type de palettes, et une table détaillée de tarif avec dates de début et de fin de validité
Encore une question, un peu plus administrative :
Si je dispose de 2 quantités pour un seul échange de palette ou d'emballage,
à savoir QUANTITE LIVREE ET QUANTITE RETOURNEE, la quantité livrée
correspond à une sortie mais la quantité retournée par la client doit-elle
être considérée comme une entrée (postive) ou bien comme une sortie mais
négative ?
Voici la structure des tables que je compte créés :
Table ENTETE_MOUVEMENT :
- N°Mvt : N° auto
- Code Tiers : Client ou Fournisseur
- Date mvt :
- Type mvt : ENTREE (alimentation auto et saisie manuelle) ou
SORTIE (Auto ou manuelle)
- Origine mvt : Alimentation AUTO (à partir des BL d'un outil de
gestion commerciale) ou Saisie Manuelle
- Reférence : N° de bon de livraison ou N° de bon échange palette
Table DETAIL_MOUVEMENT
- N° Mvt
- TypePal : Type de palette ou d'emballage consigné
- Qté1
- Qté2
Dans le cas d'une SORTIE, Qté1=Qté Livrée au tiers et Qté2=Qté Retournée par
le tiers
Dans le cas d'une ENTREE, Qté1=Qté Reçue par le fournisseurs et Qté2=Qté
Retournée au fournisseur
Puis grace à une petite moulinette, je génère une table MOUVEMENT avec tous
les champs des 2 tables ci-dessus mais avec un seul champs QTE, positif ou
négative en fonction du sens de la transaction en étant plus précis dans les
transactions c.a.d :
- si ENTREE et AUTO Transaction pour la QTE1 = ENTREE
FOURNISSEUR et QTE2 = RETOUR FOURNISSEUR
- si ENTREE et MANUEL Transaction pour la QTE1 = ENTREE DIVERSE
et QTE2= SORTIE DIVERSES
- si SORTIE et AUTO Transaction pour la QTE1 = SORTIE
CLIENT et QTE2 = RETOUR CLEINT
- si SORTIE et MANUEL Transaction pour la QTE1 = SORTIE DIVERSE
et QTE2= ENTREE DIVERSE
J'avoue que c'est encore un peu flou dans mon esprit, et ne voudrais pas
monter une usine à gaz car de cette structure dépendra tous les états et les
formulaires d'interro et de saisie.
Merci de me donner votre opinion, et chapeau à ceux qui auront lu jusqu'au
bout mon poème.
Bernard
<Anor> a écrit dans le message de news:
ubpNfPJuFHA.2848@TK2MSFTNGP10.phx.gbl...
Bonjour,
"borntoride" <joleveille@annonceduproprio.com>
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que
l'ont laisse des palettes chez un client et quand même temps ont en
charge d'autres. Alors il faut deux champs quantités pour garder trace
de toutes ces transactions.
=> non il faut un champ type de mouvement
Le deuxième problème est qu'il existe plusieurs modèles de palette
ayant chacune une valeur $$ différente alors il faut créer un champ
quantité double pour chaque type de palette.
=> non il faut un champ type de palette (code article quoi)
Je te conseil de te créer une table détaillé de tes clients et de la
mettre en relation avec ta table où tu enregistre tes données.
=> et une table détaillée du type de palettes, et une table détaillée de
tarif avec dates de
début et de fin de validité
Encore une question, un peu plus administrative : Si je dispose de 2 quantités pour un seul échange de palette ou d'emballage, à savoir QUANTITE LIVREE ET QUANTITE RETOURNEE, la quantité livrée correspond à une sortie mais la quantité retournée par la client doit-elle être considérée comme une entrée (postive) ou bien comme une sortie mais négative ?
Voici la structure des tables que je compte créés :
Table ENTETE_MOUVEMENT : - N°Mvt : N° auto - Code Tiers : Client ou Fournisseur - Date mvt : - Type mvt : ENTREE (alimentation auto et saisie manuelle) ou SORTIE (Auto ou manuelle) - Origine mvt : Alimentation AUTO (à partir des BL d'un outil de gestion commerciale) ou Saisie Manuelle - Reférence : N° de bon de livraison ou N° de bon échange palette
Table DETAIL_MOUVEMENT - N° Mvt - TypePal : Type de palette ou d'emballage consigné - Qté1 - Qté2
Dans le cas d'une SORTIE, Qté1=Qté Livrée au tiers et Qté2=Qté Retournée par le tiers Dans le cas d'une ENTREE, Qté1=Qté Reçue par le fournisseurs et Qté2=Qté Retournée au fournisseur
Puis grace à une petite moulinette, je génère une table MOUVEMENT avec tous les champs des 2 tables ci-dessus mais avec un seul champs QTE, positif ou négative en fonction du sens de la transaction en étant plus précis dans les transactions c.a.d :
- si ENTREE et AUTO Transaction pour la QTE1 = ENTREE FOURNISSEUR et QTE2 = RETOUR FOURNISSEUR - si ENTREE et MANUEL Transaction pour la QTE1 = ENTREE DIVERSE et QTE2= SORTIE DIVERSES - si SORTIE et AUTO Transaction pour la QTE1 = SORTIE CLIENT et QTE2 = RETOUR CLEINT - si SORTIE et MANUEL Transaction pour la QTE1 = SORTIE DIVERSE et QTE2= ENTREE DIVERSE
J'avoue que c'est encore un peu flou dans mon esprit, et ne voudrais pas monter une usine à gaz car de cette structure dépendra tous les états et les formulaires d'interro et de saisie.
Merci de me donner votre opinion, et chapeau à ceux qui auront lu jusqu'au bout mon poème.
Bernard
<Anor> a écrit dans le message de news:
Bonjour,
"borntoride"
Le premier problème que moi j'ai rencontré, c'est qu'il arrive que l'ont laisse des palettes chez un client et quand même temps ont en charge d'autres. Alors il faut deux champs quantités pour garder trace de toutes ces transactions.
=> non il faut un champ type de mouvement
Le deuxième problème est qu'il existe plusieurs modèles de palette ayant chacune une valeur $$ différente alors il faut créer un champ quantité double pour chaque type de palette.
=> non il faut un champ type de palette (code article quoi)
Je te conseil de te créer une table détaillé de tes clients et de la mettre en relation avec ta table où tu enregistre tes données.
=> et une table détaillée du type de palettes, et une table détaillée de tarif avec dates de début et de fin de validité
