Re: [fr-users] [calc] : fonction recherche ?

Le 08/06/2011 15:03, Loïc Breilloux a écrit :
> Bonjour,
>
> je n'arrive pas à faire quelque chose, même après avoir vu le super 
> site de Christian.
>
> Voilà ce que je souhaite faire :
>
> feuille1 :
> colonne1                colonne2            colonne3
> nom_du_client    produit_achete   prix
>
>
> feuille2 :
> A1 = le_nom_d'un_client
>
> C1 = le premier_produit_achete_par_le_client_en_A1
> C2 = le prix_payé_pour_ce_produit
>
> feuille3 :
> A1 = le_nom_d'un_autre_client
> C1 = idem
> C2 = idem
>
> QUESTION :
> Comment faire pour que Calc recherche *tous* les produits que le 
> client a achetés et m'indique le nom de ce produit et son prix dans la 
> feuille2...
>
> Merci
> Loic
Bonjour,

Sur le principe, c'est effectivement la fonction RECHERCHEV qui va te 
permettre d'aller rechercher, dans ta feuille 1, le contenu d'une 
colonne située sur la même ligne qu'un nom défini en feuille 2.

Cependant, je pense que ta fonction va avoir du mal avec le fait que tu 
présentes en lignes sur ta feuille 2, des données présentées en colonnes 
sur la feuille 1 ; c'est pas grand chose, mais c'est quand-même une 
complication supplémentaire.

Surtout, je pense que la complication majeure pour RECHERCHEV, c'est le 
fait qu'un même client passe plusieurs commandes ; malheureusement, je 
me demande si ce n'est pas, un peu, le principe de la vente... En fait, 
RECHERCHEV ne saura pas, je pense, rechercher autre chose que la 
première occurrence en Feuille 1, du nom situé en A1 de ta feuille 2 ; 
et même si tu recopies 53 fois ta formule, il devrait te redonner 53 
fois les éléments de la première occurrence trouvée en Feuille 1, du nom 
situé en A1 de la feuille 2.

Ce que tu cherches à faire, c'est la spécialité d'un SGBD (système de 
gestion de bases de données), autrement dit, de Base...

Dans ce domaine là, c'est autrement plus puissant qu'un tableur et, 
surtout, ça s'adapte beaucoup mieux aux évolutions ultérieures du 
business ; par exemple, pour la gestion des éventuelles homonymies (rien 
que sur le nom de famille ce sera un truc, mais imagine que deux clients 
portent les mêmes nom et prénom, comment RECHERCHEV saura lequel tu 
cherches ?), d'autant que RECHERCHEV ne recherche que sur une colonne, 
ce qui signifie que soit tu prévois d'entrer, dans ta colonne 1, le nom 
et le prénom, soit tu renonces dès à présent à gérer les homonymies ; de 
la même façon, avec Calc, tu ne peux absolument pas garantir 
l'homogénéité de saisie d'un nom tout au long du fichier ; une vente 
enregsitrée au nom de Gérard Martin ne sera pas la même chose qu'une 
vente enregistrée au nom de G. Martin, alors que c'est peut-être le même 
client ;  idem pour une vente à Anne-Marie Durand qui ne sera pas du 
tout la même chose que la vente à Anne Marie Durand, etc, etc... ; du 
coup, RECHERCHEV ne permettra pas de cumuler les ventes à Anne-Marie 
Durand et celles à Anne Marie Durand ; tant mieux si ce sont deux 
personne différentes, tant pis si c'est la même.

Dans une version simplissime (susceptible d'évoluer), je vois le truc 
avec trois tables : une regroupant les données d'identité des clients, 
une regroupant les opérations de vente, le lien entre les deux s'opérant 
sur l'identifiant du client, mentionné pour chaque entrée de la table 
des opérations de vente (donc, pour chaque opération de vente) et la 
troisième regroupant les articles proposés à la vente (la liaison entre 
la deuxième et la troisième table s'opérant par le numéro d'identifiant 
des articles) ; l'avantage, c'est que l'identité complète du client est 
entrée une seule fois (lors de son premier achat), et que pour chaque 
opération de vente, on l'identifie par son numéro ; en cas de 
modification dans l'adresse, on peut, soit modifier les données le 
concernant dans la table des clients, soit créer cette nouvelle adresse 
comme s'il s'agissait d'un nouveau client (une option pourrait signaler 
le caractère obsolète d'une adresse, permettant ainsi de toujours faire 
le choix de la bonne adresse, tout en conservant une trace des adresses 
successives d'un même client).

Le truc, c'est que l'utilisateur peut même remplir les tables, 
directement dans Calc (lui laissant croire qu'il est dans cette 
application, alors qu'il travaille, en fait, dans Base...) puis remplir 
ses différentes feuilles au moyen d'une requête, par simple 
"cliquer/déposer" le concepteur pouvant même envisager d'introduire, 
dans la requête, un paramètre affichant une boîte de dialogue à chaque 
exécution de la requête, et permettant à l'utilisateur de renseigner le 
nom (ou plus facilement, le numéro d'identifiant) du client dont il 
souhaite obtenir les données.

Pour moi, si ton fichier doit avoir une certaine pérennité et une vraie 
fiabilité dans l'exploitation des données (je ne parle pas de fiabilité 
en tant "qu'absence de crash", LibO Base ayant quelques difficultés de 
ce côté là), je te conseille d'investir quelques heures dans 
l'apprentissage de Base ; ces quelques heures t'en feront économiser des 
dizaines d'autres dans la maintenance, la mise à jour ou le dépannage de 
ton fichier initial.

Maintenant, si ton fichier n'est pas destiné à avoir une pérennité et 
n'est destiné qu'à bricoler un peu sur les regroupements des achats des 
clients, tu dois pouvoir t'en tirer avec quelques opérations de tri, 
puis de copier/coller ; pas la peine d'aller dénicher des bricolages sur 
une formule, et pas la peine non plus d'investir du temps sur 
l'apprentissage d'un SGBD.

Espérant avoir, un peu, aidé...

A+

--
Envoyez un mail à users+help@fr.libreoffice.org pour savoir comment vous désinscrire
Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/users/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être 
supprimés