Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pierre Jagut
Bonsoir,
J'avoue que la structure de la base m'échappe. En général, la structure d'une base Clients-Achats est la suivante : - Table CLIENTS : NumCli, NomCli, PrenomCli, AdresseCli, etc. (description du client : civilité, téléphone, e-mail, Stop Mailing, NPAI, etc.) - Table ACHATS : NumAchat, NumCli, DateAchat, etc. (description de l'achat : mode de commande, mode de paiement, mode de livraison, ou des flags pour les devis, le paiement, etc.) - Table LIGNE_ACHAT : NumAchat, Produit, QteAchat, PrixUnitaire, PrixHT, TxTVA, PrixTTC, etc. (description du produit acheté ou flags spécifiques pour les avoirs, les retours, ...)
Bien sûr, si un achat ne peut comporter qu'un seul article, inutile de générer une table LIGNE_ACHAT. Par contre, il peut y avoir une table intermédiaire de livraison/production si l'achat peut être livré ou produit en plusieurs colis/étapes. On peut également distinguer les commandes des achats et devis. On peut encore séparer le paiement s'il peut être échelonné. Bref, c'est un modèle simple que je te présente.
Seul le NumCli (N° de client) est répété pour chaque ACHAT, pas ses coordonnées. Mais tous les achats d'un même client ont le même NumCli (pour pouvoir lui être rattaché). De même, seul le NumAchat est répété pour chaque LIGNE_ACHAT. Mais toutes les lignes d'un même achat ont le même NumAchat (pour pouvoir lui être rattaché). Mais ce n'est pas le lieu pour faire un cours sur les SGBDR et l'informatique de gestion.
Si, comme je le crains, le fichier de ton client est mal structuré et - ne rattache pas les achats à un client - doublonne les clients Je te conseille de rattrapper cela avant que le fichier soit trop volumineux. Et pour faire cela, cela passe souvent par une étape manuelle. Pour dédoublonner le fichier client, cela dépend si les coordonnées ont été saisies de manière identique ou non. Si oui, Access propose un outil de dédoublonnage. Si non, il faut travailler par approximation pour faciliter le travail, mais tout dépend du volume et de la qualité de la saisie. Pour le rattachement des achats à un client, s'il n'y a pas de clé ou d'information commune avec le fichier client, cela va être difficile.
Si, comme c'est également possible, à chaque enregistrement de la table CLIENTS correspond EXACTEMENT un enregistrement de la table ACHAT, le fait de générer un numéro séquentiel permet effectivement de faire le lien. Avant cela, je te conseille de faire une copie des tables, et de vérifier s'il n'y a pas de décalage dans le fichier. Dans ce cas, tu peux créer une nouvelle table achats comportant toutes les informations présentes dans les deux tables et concernant les achats. Puis tu devras dédoublonner la table client (cf. paragraphe ci-dessus) et créer un numéro de client unique, auquel tu rattacheras les achats.
Mais j'ai peut-être mal compris. Dis-moi ce qu'il en est. Pierre.
"NetChris" a écrit dans le message de news:bg633q$2v9$
Bonjour à tous,
Mon client dispose d'une table CLIENTS (avec doublon, car il crée des autant
et une table ACHAT (le Guide du Show Business) qui indique le nbre d'exemplaires achetés par Didier GUSTIN Bis.
Donc j'ai ajouté un champ NUMSEQ dans chacune des tables
Je crée une requete pour établir le lien entre les 2 tables, mais impossible
de mettre à jour les champs (même en manuel)
Je ne vois pas comment établir un lien fiable et mettre à jour les enregs dupliqués pour modifs de rubrique.
Chris
Bonsoir,
J'avoue que la structure de la base m'échappe.
En général, la structure d'une base Clients-Achats est la suivante :
- Table CLIENTS : NumCli, NomCli, PrenomCli, AdresseCli, etc. (description
du client : civilité, téléphone, e-mail, Stop Mailing, NPAI, etc.)
- Table ACHATS : NumAchat, NumCli, DateAchat, etc. (description de l'achat :
mode de commande, mode de paiement, mode de livraison, ou des flags pour les
devis, le paiement, etc.)
- Table LIGNE_ACHAT : NumAchat, Produit, QteAchat, PrixUnitaire, PrixHT,
TxTVA, PrixTTC, etc. (description du produit acheté ou flags spécifiques
pour les avoirs, les retours, ...)
Bien sûr, si un achat ne peut comporter qu'un seul article, inutile de
générer une table LIGNE_ACHAT. Par contre, il peut y avoir une table
intermédiaire de livraison/production si l'achat peut être livré ou produit
en plusieurs colis/étapes. On peut également distinguer les commandes des
achats et devis. On peut encore séparer le paiement s'il peut être
échelonné. Bref, c'est un modèle simple que je te présente.
Seul le NumCli (N° de client) est répété pour chaque ACHAT, pas ses
coordonnées. Mais tous les achats d'un même client ont le même NumCli (pour
pouvoir lui être rattaché).
De même, seul le NumAchat est répété pour chaque LIGNE_ACHAT. Mais toutes
les lignes d'un même achat ont le même NumAchat (pour pouvoir lui être
rattaché).
Mais ce n'est pas le lieu pour faire un cours sur les SGBDR et
l'informatique de gestion.
Si, comme je le crains, le fichier de ton client est mal structuré et
- ne rattache pas les achats à un client
- doublonne les clients
Je te conseille de rattrapper cela avant que le fichier soit trop
volumineux. Et pour faire cela, cela passe souvent par une étape manuelle.
Pour dédoublonner le fichier client, cela dépend si les coordonnées ont été
saisies de manière identique ou non. Si oui, Access propose un outil de
dédoublonnage. Si non, il faut travailler par approximation pour faciliter
le travail, mais tout dépend du volume et de la qualité de la saisie.
Pour le rattachement des achats à un client, s'il n'y a pas de clé ou
d'information commune avec le fichier client, cela va être difficile.
Si, comme c'est également possible, à chaque enregistrement de la table
CLIENTS correspond EXACTEMENT un enregistrement de la table ACHAT, le fait
de générer un numéro séquentiel permet effectivement de faire le lien. Avant
cela, je te conseille de faire une copie des tables, et de vérifier s'il n'y
a pas de décalage dans le fichier. Dans ce cas, tu peux créer une nouvelle
table achats comportant toutes les informations présentes dans les deux
tables et concernant les achats. Puis tu devras dédoublonner la table client
(cf. paragraphe ci-dessus) et créer un numéro de client unique, auquel tu
rattacheras les achats.
Mais j'ai peut-être mal compris.
Dis-moi ce qu'il en est.
Pierre.
"NetChris" <christian.dranem-TOTO@wanadoo.fr> a écrit dans le message de
news:bg633q$2v9$1@news-reader2.wanadoo.fr...
Bonjour à tous,
Mon client dispose d'une table CLIENTS (avec doublon, car il crée des
autant
J'avoue que la structure de la base m'échappe. En général, la structure d'une base Clients-Achats est la suivante : - Table CLIENTS : NumCli, NomCli, PrenomCli, AdresseCli, etc. (description du client : civilité, téléphone, e-mail, Stop Mailing, NPAI, etc.) - Table ACHATS : NumAchat, NumCli, DateAchat, etc. (description de l'achat : mode de commande, mode de paiement, mode de livraison, ou des flags pour les devis, le paiement, etc.) - Table LIGNE_ACHAT : NumAchat, Produit, QteAchat, PrixUnitaire, PrixHT, TxTVA, PrixTTC, etc. (description du produit acheté ou flags spécifiques pour les avoirs, les retours, ...)
Bien sûr, si un achat ne peut comporter qu'un seul article, inutile de générer une table LIGNE_ACHAT. Par contre, il peut y avoir une table intermédiaire de livraison/production si l'achat peut être livré ou produit en plusieurs colis/étapes. On peut également distinguer les commandes des achats et devis. On peut encore séparer le paiement s'il peut être échelonné. Bref, c'est un modèle simple que je te présente.
Seul le NumCli (N° de client) est répété pour chaque ACHAT, pas ses coordonnées. Mais tous les achats d'un même client ont le même NumCli (pour pouvoir lui être rattaché). De même, seul le NumAchat est répété pour chaque LIGNE_ACHAT. Mais toutes les lignes d'un même achat ont le même NumAchat (pour pouvoir lui être rattaché). Mais ce n'est pas le lieu pour faire un cours sur les SGBDR et l'informatique de gestion.
Si, comme je le crains, le fichier de ton client est mal structuré et - ne rattache pas les achats à un client - doublonne les clients Je te conseille de rattrapper cela avant que le fichier soit trop volumineux. Et pour faire cela, cela passe souvent par une étape manuelle. Pour dédoublonner le fichier client, cela dépend si les coordonnées ont été saisies de manière identique ou non. Si oui, Access propose un outil de dédoublonnage. Si non, il faut travailler par approximation pour faciliter le travail, mais tout dépend du volume et de la qualité de la saisie. Pour le rattachement des achats à un client, s'il n'y a pas de clé ou d'information commune avec le fichier client, cela va être difficile.
Si, comme c'est également possible, à chaque enregistrement de la table CLIENTS correspond EXACTEMENT un enregistrement de la table ACHAT, le fait de générer un numéro séquentiel permet effectivement de faire le lien. Avant cela, je te conseille de faire une copie des tables, et de vérifier s'il n'y a pas de décalage dans le fichier. Dans ce cas, tu peux créer une nouvelle table achats comportant toutes les informations présentes dans les deux tables et concernant les achats. Puis tu devras dédoublonner la table client (cf. paragraphe ci-dessus) et créer un numéro de client unique, auquel tu rattacheras les achats.
Mais j'ai peut-être mal compris. Dis-moi ce qu'il en est. Pierre.
"NetChris" a écrit dans le message de news:bg633q$2v9$
Bonjour à tous,
Mon client dispose d'une table CLIENTS (avec doublon, car il crée des autant
et une table ACHAT (le Guide du Show Business) qui indique le nbre d'exemplaires achetés par Didier GUSTIN Bis.
Donc j'ai ajouté un champ NUMSEQ dans chacune des tables
Je crée une requete pour établir le lien entre les 2 tables, mais impossible
de mettre à jour les champs (même en manuel)
Je ne vois pas comment établir un lien fiable et mettre à jour les enregs dupliqués pour modifs de rubrique.
Chris
NetChris
Je te répond Pierre dans quelques instants. Quelques problèmes à régler auparavant. Chris
"Pierre Jagut" a écrit dans le message de news:bg6bh9$f8j$
Bonsoir,
J'avoue que la structure de la base m'échappe. En général, la structure d'une base Clients-Achats est la suivante : - Table CLIENTS : NumCli, NomCli, PrenomCli, AdresseCli, etc. (description du client : civilité, téléphone, e-mail, Stop Mailing, NPAI, etc.) - Table ACHATS : NumAchat, NumCli, DateAchat, etc. (description de l'achat :
mode de commande, mode de paiement, mode de livraison, ou des flags pour les
devis, le paiement, etc.) - Table LIGNE_ACHAT : NumAchat, Produit, QteAchat, PrixUnitaire, PrixHT, TxTVA, PrixTTC, etc. (description du produit acheté ou flags spécifiques pour les avoirs, les retours, ...)
Bien sûr, si un achat ne peut comporter qu'un seul article, inutile de générer une table LIGNE_ACHAT. Par contre, il peut y avoir une table intermédiaire de livraison/production si l'achat peut être livré ou produit
en plusieurs colis/étapes. On peut également distinguer les commandes des achats et devis. On peut encore séparer le paiement s'il peut être échelonné. Bref, c'est un modèle simple que je te présente.
Seul le NumCli (N° de client) est répété pour chaque ACHAT, pas ses coordonnées. Mais tous les achats d'un même client ont le même NumCli (pour
pouvoir lui être rattaché). De même, seul le NumAchat est répété pour chaque LIGNE_ACHAT. Mais toutes les lignes d'un même achat ont le même NumAchat (pour pouvoir lui être rattaché). Mais ce n'est pas le lieu pour faire un cours sur les SGBDR et l'informatique de gestion.
Si, comme je le crains, le fichier de ton client est mal structuré et - ne rattache pas les achats à un client - doublonne les clients Je te conseille de rattrapper cela avant que le fichier soit trop volumineux. Et pour faire cela, cela passe souvent par une étape manuelle. Pour dédoublonner le fichier client, cela dépend si les coordonnées ont été
saisies de manière identique ou non. Si oui, Access propose un outil de dédoublonnage. Si non, il faut travailler par approximation pour faciliter le travail, mais tout dépend du volume et de la qualité de la saisie. Pour le rattachement des achats à un client, s'il n'y a pas de clé ou d'information commune avec le fichier client, cela va être difficile.
Si, comme c'est également possible, à chaque enregistrement de la table CLIENTS correspond EXACTEMENT un enregistrement de la table ACHAT, le fait de générer un numéro séquentiel permet effectivement de faire le lien. Avant
cela, je te conseille de faire une copie des tables, et de vérifier s'il n'y
a pas de décalage dans le fichier. Dans ce cas, tu peux créer une nouvelle table achats comportant toutes les informations présentes dans les deux tables et concernant les achats. Puis tu devras dédoublonner la table client
(cf. paragraphe ci-dessus) et créer un numéro de client unique, auquel tu rattacheras les achats.
Mais j'ai peut-être mal compris. Dis-moi ce qu'il en est. Pierre.
"NetChris" a écrit dans le message de news:bg633q$2v9$
Bonjour à tous,
Mon client dispose d'une table CLIENTS (avec doublon, car il crée des autant
et une table ACHAT (le Guide du Show Business) qui indique le nbre d'exemplaires achetés par Didier GUSTIN Bis.
Donc j'ai ajouté un champ NUMSEQ dans chacune des tables
Je crée une requete pour établir le lien entre les 2 tables, mais impossible
de mettre à jour les champs (même en manuel)
Je ne vois pas comment établir un lien fiable et mettre à jour les enregs
dupliqués pour modifs de rubrique.
Chris
Je te répond Pierre dans quelques instants. Quelques problèmes à régler
auparavant.
Chris
"Pierre Jagut" <jagut@geta.fr> a écrit dans le message de
news:bg6bh9$f8j$1@s1.read.news.oleane.net...
Bonsoir,
J'avoue que la structure de la base m'échappe.
En général, la structure d'une base Clients-Achats est la suivante :
- Table CLIENTS : NumCli, NomCli, PrenomCli, AdresseCli, etc. (description
du client : civilité, téléphone, e-mail, Stop Mailing, NPAI, etc.)
- Table ACHATS : NumAchat, NumCli, DateAchat, etc. (description de l'achat
:
mode de commande, mode de paiement, mode de livraison, ou des flags pour
les
devis, le paiement, etc.)
- Table LIGNE_ACHAT : NumAchat, Produit, QteAchat, PrixUnitaire, PrixHT,
TxTVA, PrixTTC, etc. (description du produit acheté ou flags spécifiques
pour les avoirs, les retours, ...)
Bien sûr, si un achat ne peut comporter qu'un seul article, inutile de
générer une table LIGNE_ACHAT. Par contre, il peut y avoir une table
intermédiaire de livraison/production si l'achat peut être livré ou
produit
en plusieurs colis/étapes. On peut également distinguer les commandes des
achats et devis. On peut encore séparer le paiement s'il peut être
échelonné. Bref, c'est un modèle simple que je te présente.
Seul le NumCli (N° de client) est répété pour chaque ACHAT, pas ses
coordonnées. Mais tous les achats d'un même client ont le même NumCli
(pour
pouvoir lui être rattaché).
De même, seul le NumAchat est répété pour chaque LIGNE_ACHAT. Mais toutes
les lignes d'un même achat ont le même NumAchat (pour pouvoir lui être
rattaché).
Mais ce n'est pas le lieu pour faire un cours sur les SGBDR et
l'informatique de gestion.
Si, comme je le crains, le fichier de ton client est mal structuré et
- ne rattache pas les achats à un client
- doublonne les clients
Je te conseille de rattrapper cela avant que le fichier soit trop
volumineux. Et pour faire cela, cela passe souvent par une étape manuelle.
Pour dédoublonner le fichier client, cela dépend si les coordonnées ont
été
saisies de manière identique ou non. Si oui, Access propose un outil de
dédoublonnage. Si non, il faut travailler par approximation pour faciliter
le travail, mais tout dépend du volume et de la qualité de la saisie.
Pour le rattachement des achats à un client, s'il n'y a pas de clé ou
d'information commune avec le fichier client, cela va être difficile.
Si, comme c'est également possible, à chaque enregistrement de la table
CLIENTS correspond EXACTEMENT un enregistrement de la table ACHAT, le fait
de générer un numéro séquentiel permet effectivement de faire le lien.
Avant
cela, je te conseille de faire une copie des tables, et de vérifier s'il
n'y
a pas de décalage dans le fichier. Dans ce cas, tu peux créer une nouvelle
table achats comportant toutes les informations présentes dans les deux
tables et concernant les achats. Puis tu devras dédoublonner la table
client
(cf. paragraphe ci-dessus) et créer un numéro de client unique, auquel tu
rattacheras les achats.
Mais j'ai peut-être mal compris.
Dis-moi ce qu'il en est.
Pierre.
"NetChris" <christian.dranem-TOTO@wanadoo.fr> a écrit dans le message de
news:bg633q$2v9$1@news-reader2.wanadoo.fr...
Bonjour à tous,
Mon client dispose d'une table CLIENTS (avec doublon, car il crée des
autant
Je te répond Pierre dans quelques instants. Quelques problèmes à régler auparavant. Chris
"Pierre Jagut" a écrit dans le message de news:bg6bh9$f8j$
Bonsoir,
J'avoue que la structure de la base m'échappe. En général, la structure d'une base Clients-Achats est la suivante : - Table CLIENTS : NumCli, NomCli, PrenomCli, AdresseCli, etc. (description du client : civilité, téléphone, e-mail, Stop Mailing, NPAI, etc.) - Table ACHATS : NumAchat, NumCli, DateAchat, etc. (description de l'achat :
mode de commande, mode de paiement, mode de livraison, ou des flags pour les
devis, le paiement, etc.) - Table LIGNE_ACHAT : NumAchat, Produit, QteAchat, PrixUnitaire, PrixHT, TxTVA, PrixTTC, etc. (description du produit acheté ou flags spécifiques pour les avoirs, les retours, ...)
Bien sûr, si un achat ne peut comporter qu'un seul article, inutile de générer une table LIGNE_ACHAT. Par contre, il peut y avoir une table intermédiaire de livraison/production si l'achat peut être livré ou produit
en plusieurs colis/étapes. On peut également distinguer les commandes des achats et devis. On peut encore séparer le paiement s'il peut être échelonné. Bref, c'est un modèle simple que je te présente.
Seul le NumCli (N° de client) est répété pour chaque ACHAT, pas ses coordonnées. Mais tous les achats d'un même client ont le même NumCli (pour
pouvoir lui être rattaché). De même, seul le NumAchat est répété pour chaque LIGNE_ACHAT. Mais toutes les lignes d'un même achat ont le même NumAchat (pour pouvoir lui être rattaché). Mais ce n'est pas le lieu pour faire un cours sur les SGBDR et l'informatique de gestion.
Si, comme je le crains, le fichier de ton client est mal structuré et - ne rattache pas les achats à un client - doublonne les clients Je te conseille de rattrapper cela avant que le fichier soit trop volumineux. Et pour faire cela, cela passe souvent par une étape manuelle. Pour dédoublonner le fichier client, cela dépend si les coordonnées ont été
saisies de manière identique ou non. Si oui, Access propose un outil de dédoublonnage. Si non, il faut travailler par approximation pour faciliter le travail, mais tout dépend du volume et de la qualité de la saisie. Pour le rattachement des achats à un client, s'il n'y a pas de clé ou d'information commune avec le fichier client, cela va être difficile.
Si, comme c'est également possible, à chaque enregistrement de la table CLIENTS correspond EXACTEMENT un enregistrement de la table ACHAT, le fait de générer un numéro séquentiel permet effectivement de faire le lien. Avant
cela, je te conseille de faire une copie des tables, et de vérifier s'il n'y
a pas de décalage dans le fichier. Dans ce cas, tu peux créer une nouvelle table achats comportant toutes les informations présentes dans les deux tables et concernant les achats. Puis tu devras dédoublonner la table client
(cf. paragraphe ci-dessus) et créer un numéro de client unique, auquel tu rattacheras les achats.
Mais j'ai peut-être mal compris. Dis-moi ce qu'il en est. Pierre.
"NetChris" a écrit dans le message de news:bg633q$2v9$
Bonjour à tous,
Mon client dispose d'une table CLIENTS (avec doublon, car il crée des autant
