Discussion :

[informer]

Si je comprends bien ton modèle

1. tblDetailCommandePalette est lié à un et un seul enreg de tblDetailCommandeArticle et un tblDetailCommandeArticle peut être lié à plusieurs tblDetailCommandePalette
2. tblDetailCommandeArticle qui est lié à une et une seul tblCommande et bien sûr un tblCommande peut être lié à plusieurs tblDetailCommandeArticle

Donc pourquoi un lien entre tblCommande & tblDetailCommandePalette ?

Si c'est le cas et si tu es Ok avec ce qui est écrit ci-dessus, il faudrait supprimer le lient tblCommande & tblDetailCommandePalette !

To be continued ???

[John Parker]

1. tblDetailCommandePalette est lié à un et un seul enreg de tblDetailCommandeArticle
   Non tblDetailCommandePalette est lié à un seul enregistrement de tblCommande. Et encore, si une même commande est préparée en plusieurs fois cela peut changer
2. tblDetailCommandeArticle peut être lié à plusieurs tblDetailCommandePalette
   Exactement
3. tblDetailCommandeArticle qui est lié à une et une seul tblCommande
   Exact
4. et bien sûr un tblCommande peut être lié à plusieurs tblDetailCommandeArticle
   Exact
5. Je rajouterai que tblDetailCommandePalette peut avoir plusieurs enregistrements pour une même commande
   

Quand je parle de commande j'entend par la l'association Année + Type + Numéro Commande

[informer]

Voici le modèle que tu as implémenté dans ta base de données




La table tblDetailCommandePalette est seulement reliée à tblCommande. Donc tu ne fais qu'un suivi de la consommation des palettes mais en aucun cas de la ventilation des articles par palette?

Par contre j'identifie un lien entre ODBC_source et commande? Tu peux me l'expliquer?


De plus je ne trouve pas ta table article?

[informer]

Quand je parle de commande j'entends par la l'association Année + Type + Numéro Commande

Ok, ta clé fonctionnelle ou réelle correspond à ces 3 champs. Pour assurer l'unicité dans la table commande, un index unique doit être appliqué sur ces 3 champs. Ainsi pour le tuple (Année + Type + Numéro Commande) ne peut correspondre qu'un seul identifiant IDCommande

[John Parker]

Ok, ta clé fonctionnelle ou réelle correspond à ces 3 champs. Pour assurer l'unicité dans la table commande, un index unique doit être appliqué sur ces 3 champs. Ainsi pour le tuple (Année + Type + Numéro Commande) ne peut correspondre qu'un seul identifiant IDCommande

Je ne suis pas sûre que cela corresponde à mon besoin car si une commande n'est pas terminée, alors il faudra faire un nouvel enregistrement pour Année + Type + Numéro Commande. Le fait de faire un index unique sur ces 3 champs est en adéquation avec non?

[John Parker]

Voici le modèle que tu as implémenté dans ta base de données




La table tblDetailCommandePalette est seulement reliée à tblCommande. Donc tu ne fais qu'un suivi de la consommation des palettes mais en aucun cas de la ventilation des articles par palette?

Par contre j'identifie un lien entre ODBC_source et commande? Tu peux me l'expliquer?


De plus je ne trouve pas ta table article?

Justement, il est impossible de dire qu'un code article se trouve sur une palette bien précise puisqu'un code article peut se retrouver sur 2 type de palette différentes.

Pour la table Article (qui est une requête) j'ai du l'oublier, je te la renvoie demain quand je serai sur le PC ou j'ai Access

[informer]

Justement, il est impossible de dire qu'un code article se trouve sur une palette bien précise puisqu'un code article peut se retrouver sur 2 type de palette différentes.

Je ne comprends pas pourquoi ça te pose un problème.

1. Soit tu fais un suivi par palette et sur chaque palette, la quantité = quantité d'articles
2. Soit tu n'as pas à singulariser chaque palette et est saisi la qteArticle = quantité d'articles + qtePalette = quantité de Palette

Je te donne un exemple pour la 2ième proposition:

Considérons une commande code 205 avec un article code 10 => idDetailCommandeArticle code 125 pour une quantité de 50 articles
Les palettes utilisées le sont comme suit:

• 5 palettes 10x10 = code P001 => 30 articles
• 1 Palette 20x20 = code P125 => 20 articles

Alors il y aura 2 enregistrements dans la table tblDetailCommandePalette

idDetailCommandeArticle	idDetailCommandePalette	CodePalette	QtePalette	QteProduit
125	251	P001	5	30
125	252	P125	1	20

Je te propose donc la table tblDetailCommandePalette (idDetailCommandeArticle, idDetailCommandePalette, CodePalette,QtePalette,QteProduit)

[John Parker]

Informer,

Je pense que ça répond à mon besoin!

Par contre l'information des articles préparés pour cette commande sont bien stockés dans la table tblDetailCommandeArticle?

[informer]

John

Pour moi, si la table tbldetailcommandePalette est renseignée => c'est ce qui a été préparé.

Questions:

1. Dois tu suivre leur envoi?
2. J'ai vu dans la table odbc_materiel qu'il existait d'autres éléments que palette, dois tu aussi suivre leur consommation?

Bonjour chez vous

[John Parker]

Questions:
1.Dois tu suivre leur envoi?

Pas besoin de suivre l'envoie

2.J'ai vu dans la table odbc_materiel qu'il existait d'autres éléments que palette, dois tu aussi suivre leur consommation?

Ce serait top de connaître tout ce qui a été consommé pour préparer 1 commande en effet

En résumé :

• tblcommande : contient un idcommande pour chaque combinaison Année+Type+Numéro sachant qu'il pourrait y avoir plusieurs id pour une même combinaison dans le cas ou une commande a été préparée en plusieurs fois
  
• tblDetailCommandePalette : contient le matériel utilisé pour chaque commande préparé
  
• tblDetailCommandeArticle : contient le détail des codes articles préparés avec leur quantité pour chaque commande

J'aurai donc toutes les informations nécessaires dans ces 3 tables. Il ne me restera plus qu'à faire des requêtes pour avoir 1 récap du matériel utilisé et des codes articles préparés pour chaque commande

[informer]

En résumé :

1. tblcommande : contient un idcommande pour chaque combinaison Année+Type+Numéro sachant qu'il pourrait y avoir plusieurs id pour une même combinaison dans le cas ou une commande a été préparée en plusieurs fois

Je ne comprends pas ce que tu veux dire par avoir plusieurs id. De quel ID parles tu?

Bonjour chez vous

[John Parker]

Je ne comprends pas ce que tu veux dire par avoir plusieurs id. De quel ID parles tu?

Bonjour chez vous

Je parle de la clé primaire idCommande

[informer]

je ne comprends comment tu peux avoir plusieurs idCommande pour le même tuple(date,numéro,type), peux tu me donner un exemple avec des données?

[informer]

J'ai l'intuition au vu de tes derniers commentaires que tu veux pouvoir livrer par lots. Dans ce cas il faut repenser le modèle car dans la table commande, il ne peut y avoir qu'une et une seule itération pour chaque tuple (data, number, type)

Dans le cas inverse cette table ne peut s'appeler tblCommande.

J'avais dans mon modèle initial intégré la notion de bon de livraison qui permet de lotir une commande.

[John Parker]

Informer,

Je ne sais comment te remercier du temps que tu passes à m'aider

J'ai rajouté dans la table commande un champs : date de préparation.
Ce champs est alimenté automatiquement au moment ou l'utilisateur clique sur le bouton "Ajouter", il correspond à la date du jour

DateLivraison	Numero	CodeClient	Type	CodeArticle	DescArticle	Quantite
21/01/2016	377	C00003	Type1	Article31	Description31	290

La commande 2016 Type 377 est composé de l’article31 pour une quantité de 290 pièces (voir table ODB_Source)
Admettons que cette commande soit préparée en 2 fois, une première fois le 31/07/2016 et le reste le 05/10/2016.
Voici ce que j’aurai dans la table tblCommande :

IDCommande	DatePreparation	Annee	TypeCommande	NumCommande
43	31/07/2016	2016	Type1	377
44	31/07/2016	2016	Type1	377

En gros, avec la date de préparation en plus, IDCommande est unique pour DatePreparation+Annee+Type+Numero

Je te remet la base avec la modification apportée:

[informer]

John

J'ai regardé les données de ODBC_SOURCE et je ne comprends pas ces données :

DateLivraison	Numero	CodeClient	Type	CodeArticle	DescArticle	Quantite
28/10/2014	265	C00012	Type1	Article25	Description25	45
28/10/2014	265	C00012	Type1	Article26	Description26	528

Comment peux tu avoir 2 lignes avec le même tuple (DateLivraison, Numero, type) qui est en contradiction avec ce tu as dit antérieurement? Il n'y a qu'une explication, voir post suivant

[informer]

John

Ton fichier ODBC_SOURCE a comme un parfum très fort de detailCommandeArticle!

Je comprends mieux pourquoi les listboxes sont alimentées par ODBC_SOURCE qui est également la table référence pour type puisque que tu ne pointes pas sur une table genre ODBC_TYPE:

Veux-tu retraiter ton fichier ODBC_SOURCE et le charger dans ton propre SI dans le respect de ton modèle ou ODBC_SOURCE doit-il rester le fichier garant de l'information (pas=> Les infos sont attachées à ce fichier?!


Pour te simplifier les requêtes des LBoxes ainsi: (Ajout de la commande DISTINCT)

Ta 1rer LBoxe, je te propose

Code :

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

SELECT DISTINCT Year([DateLivraison]) AS Annee FROM ODBC_SOURCE ORDER BY Year([DateLivraison]);

2ième

Code :

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

SELECT DISTINCT [ODBC_SOURCE].Type, Year([DateLivraison]) AS Annee FROM ODBC_SOURCE WHERE (((Year([DateLivraison]))=Forms!F_Saisie!C_A));

3ième

Code :

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

SELECT DISTINCT ODBC_SOURCE.[Numero] FROM ODBC_SOURCE WHERE (((ODBC_SOURCE.Type)=Forms!F_Saisie!C_T) And ((Year([DateLivraison]))=Forms!F_Saisie!C_A)) ORDER BY ODBC_SOURCE.[Numero];

[John Parker]

Informer,

Je te remercie pour l'optimisation de mes listbox avec DISTINCT.

Je ne peux malheureusement pas te charger le fichier original qui est confidentiel. Dans le fichier original c'est un lien ODBC vers une table oracle, une vue pour être exact.

Je ne peux donc rien écrire dans cette table, c'est pourquoi je m'en sert uniquement comme source pour mes listboxs. Ca aurait été tellement plus simple si j'avais seulement pu rajouter un champs dans cette table

[John Parker]

J'ai fait un exemple qui devrait être beaucoup plus clair.

Comme tu peux le voir dans mon exemple une partie de la commande 2016 Type1 377 a été préparée le 31/07/2016.
La commande n'est donc pas terminée au 31/07/2016.
Le reste de la commande a été préparée le 05/10/2016 dans mon exemple ce qui explique les 2 enregistrements dans la table tblCommande.

Dans la table tblDetailCommandePalette j'ai le matériel utilisé pour préparé chaque cadence pour cette commande.

La table tblDetailCommandeArticle contient les articles préparés pour chaque cadence avec leurs quantités.

Je pense que c'est plus facile à comprendre comme ça. Comme disait Napoléon : un bon croquis vaut mieux qu'un long discours!

[informer]

John

La vue oracle donnent le stock des lignes de commande c'est à dire toutes les commandes depuis l'année d'origine ou seulement le delta des les nouvelles lignes de commandes entre deux extraction?

Te faut il traiter le fichier ODBC_SOURCE pour le charger dans ta base => traitements pour ventiler les données dans tes tables tblXXXX puis faire vivre tes données hors de la table ODBC_SOURCE?

Si c'est le cas, il va falloir que tu attaches un traitement Vba sur un bouton importation puis ensuite faire tes opérations de livraison!

Il faut que tu me répondes à ces questions avant de décider d'une solution !