Discussion :

[lennelei]

Bonjour à tous,

j'ai toujours de petits soucis liés à des demandes utilisateurs qui me semblent compliquées à résoudre (et à expliquer, d'où le titre peu parlant... toutes mes excuses).

Je reprends mon dernier exemple.

voilà, j'ai toujours ma table de TAUX:

Code :

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

1
2
3
4
5
6
7
DATE       | TYPE | VALEUR
01/01/2010 |   A  |   11.5
01/01/2011 |   A  |   12.5
01/02/2011 |   A  |   13.5
01/01/2010 |   B  |   61.7
01/01/2011 |   B  |   62.7
01/02/2011 |   B  |   63.7

Et ma table VENTE:

Code :

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

1
2
3
4
DATE       |OBJET | PRIX
15/01/2010 |  O0  |  450
15/01/2011 |  O1  |  550
12/02/2011 |  O2  |  980

L'utilisateur souhaiterait deux choses :
1) pouvoir automatiser l'extraction du prix d'un objet en fonction d'un taux.
C'est à dire qu'il existe un objet de l'univers PRIX_TOTAL qui soit le résultat de VENTE.PRIX * TAUX.VALEUR. En sachant que par défaut, c'est le type A qui serait utilisé (avec une jointure entre le mois+année de VENTE.DATE et de TAUX.DATE). Dans notre exemple, on aurait donc :

Code :

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

1
2
3
4
OBJET | PRIX_TOTAL
   O0   | 450 * 11.5
   O1   | 550 * 12.5
   O2   | 980 * 13.5

Mais avec la possibilité d'inclure dans la création de la requête un objet qu'il pourrait positionner à 'B' et qui donnerait le résultat suivant :

Code :

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

1
2
3
4
OBJET | PRIX_TOTAL
   O0   | 450 * 61.7
   O1   | 550 * 62.7
   O2   | 980 * 63.7

Je serais déjà heureux que quelqu'un comprenne ceci... j'ai fait pas mal d'essai, et ce qui me bloque, c'est la notion de valeur par défaut ! Je ne vois pas comment faire en sorte que si l'utilisateur ne choisit rien, cela prenne par défaut la valeur 'A' (ps.: j'ai toutes les solutions que je veux sans cette notion de valeur par défaut: pas la peine de me proposer autre chose ). Ah, et l'utilisateur ne souhaite pas de prompt !

2) il voudrait également avoir un objet PRIX_CONSTANT tel que s'il est sélectionné, il renvoie le même taux de type 'A' pour tous les objets quelle que soit leur date et tel que la date du taux de type 'A' est la plus ancienne.
Ici :

Code :

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

1
2
3
4
OBJET | PRIX_CONSTANT
   O0   | 450 * 11.5
   O1   | 550 * 11.5
   O2   | 980 * 11.5

Je ne pense pas avoir beaucoup de réponse, mais on ne sait jamais

Merci d'avance !

[TomDuBouchon]

Bonjour,

Pourquoi peu de réponse ? C'est mal nous connaître

Bref, pour ce qui est de tes problématiques, je vais commencer par la deuxième car il n'y a rien de plus simple...

En fait, il faut importer une nouvelle fois ta table TAUX sous un alias. (Appelons-là Taux A) De là il te suffit de créer une jointure entre ta table VENTE et ta table TAUXA sur l'année et le mois et en ajoutant dans la jointure une condition :

Code :

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

TAUX.TYPE = 'A'

Enfin, tu n'as plus qu'à créer un objet spécifique avec comme formule :

Code :

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

VENTE.PRIX*TAUXA.VALEUR

Ensuite, pour ta première problématique, je comprends bien le problème, mais par contre je vois une incohérence : Tu dis que l'utilisateur veut pouvoir spécifier quelquepart qu'il faut prendre le taux B, mais ne veut pas de @prompt ... qu'est-ce qu'il veut alors ?
Sinon, tu dis avoir déjà sélectionné une solution... OK, mais dans ce cas précises-la nous afin de voir comment gérer les valeurs par défaut.

[lennelei]

Peu de réponses car je me disais que mon problème est peut être insoluble au niveau du designer :p

Cela étant, merci pour ton premier retour

Pour le second point (en premier dans ta réponse), ça n'est malheureusement pas aussi simple (sauf si j'ai mal compris ta réponse). En effet, il ne doit plus y avoir de liens direct entre l'année et le mois : on prend le premier taux de la période des ventes demandées. Si tu regardes l'exemple dans mon premier post, tu vois que tous les taux sont identiques alors que les dates diffèrent.
C'est à dire que si l'utilisateur demande des ventes de mai 2005 à avril 2010, le taux retourné sera celui de mai 2005 pour toutes les lignes !

En gros, une requête SQL simplifiée serait quelque chose du genre :

Code :

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

1
2
3
4
5
6
7
SELECT VENTE.OBJET, VENTE.PRIX*TAUX.VALEUR
FROM VENTE, TAUX, ...
WHERE TAUX.TYPE='A'
   AND VENTE.... <= autres critères sur les ventes ou sur d'autres tables
   AND TAUX.DATE=(SELECT MIN(VENTE.DATE)
                    FROM VENTE
                    WHERE VENTE..... <= même critères sur les ventes que ci-dessus)

Je dis simplifiée puisqu'entre TAUX.DATE et VENTE.DATE, il ne faut comparer que l'année et le mois (pas le jour), mais c'est pour ne pas surcharger et pour donner l'idée.
Mais je ne sais pas comment faire la requête imbriquée en BO...

Pour mon premier point (ta seconde question donc), l'utilisateur aurait voulu avoir un objet "TYPE DE TAUX" par exemple qui, mis en Conditions dans un générateur de requête, lui aurait permis de choisir son taux à partir d'une liste de valeur; ce qui n'est pas très compliqué (un Objet valant TAUX.TYPE suffit pour cela)... par contre, si ce "TYPE DE TAUX" n'est pas utilisé en Conditions, il voudrait que ce soit le taux A qui soit utilisé par défaut... ce que je trouve beaucoup plus compliqué, car pour moi, si tu ne mets pas cet objet, tu te retrouves avec une jointure incomplète et donc des valeurs multipliées !

En fait, le problème global est évidemment beaucoup plus compliqué, mais pour simplifier, la solution retenue est d'avoir un objet "TAUX PAR DEFAUT", un objet "TYPE DE TAUX" et un objet "TAUX".
L'utilisateur peut faire sa requête avec l'objet "TAUX PAR DEFAUT" ou utiliser les 2 objets "TYPE DE TAUX" et "TAUX" pour accéder à un autre taux.

[TomDuBouchon]

OK, en effet c'est plus compliqué mais tout autant faisable.

En fait, il faut remplacer l'alias par une table dérivée (mp : Et oui Jul et Doc, on ne se refait pas que voulez-vous ): "clic_droit > ajouter une table dérivée" dans laquelle tu spécifies vouloir ramener les informations de ta table TAUX en y appliquant les conditions que tu souhaites (en ordre SQL classique)

Pour le deuxième point, j'y réfléchis et je reviens vers toi

[TomDuBouchon]

En fait, si tu dois passer par plusieurs objets, rien ne t'empêche de créer un objet-filtre nommé "Taux par défaut" et qui pointe sur le taux A.

Mais comme ton utilisateur a l'air... disons... "exigeant", je ne sais pas s'il appréciera que les objets ne se soient pas visualisables tous au même endroit.

[lennelei]

En fait, il faut remplacer l'alias par une table dérivée (mp : Et oui Jul et Doc, on ne se refait pas que voulez-vous ): "clic_droit > ajouter une table dérivée" dans laquelle tu spécifies vouloir ramener les informations de ta table TAUX en y appliquant les conditions que tu souhaites (en ordre SQL classique)

Mais tu peux faire cela en ne sachant pas par avance quelle sera l'année à ramener ?

Par exemple, un coup je vais ramener des ventes de 2005 à 2011, et le taux sera donc celui de 2005... le coup suivant, les ventes seront pour l'année 2010, et le taux devra donc être celui de 2010.

En tout cas, merci pour les pistes, je vais y jeter un oeil (mais lundi : là, c'est le ouikend).

edit: quand je parle d'un critère dans ma pseudo requête, je parle bien sûr d'un critère construit lors de la conception du rapport par l'utilisateur, non pas lors de la création de l'univers

[lennelei]

Bon, je vais passer à Résolu même si ça n'est pas le cas : on a réussi à simplifier le besoin original, mais même comme ça, c'est pas super propre

Merci quand même