Bug avec la fonction CONCATENER
j'utilise la fonction CONCATENER sur une plage de cellules.
ces cellules contiennent toutes des dates formatées en date (option français et calendrier grégorien)
donc la résultante est une date.
Or cette résultante apparait IRREMEDIABLEMENT sous format standard (donc par exemple pour le 11 juin 1921 il s'affiche le nombre 42896) !!!
il apparait donc impossible de faire afficher le résultat sous format date (11-juin-21)
Est-ce une particularité de la fonction CONCATENER??
je précise que dans cette même cellule où s'affiche mon résultat, si j'entre la même date : elle s'ffiche bien en format DATE (11-juin-21)
Merci de vos réponses
Bonjour,
Tu peux mettre 1 exemple de fichier?
Je vois pas trop ce que tu compte faire à concaténer des dates.
Bonne journée
bonjour,
essayez :
=texte(concatener(vos valeurs);"jj/mm/aa")ou le format texte qui vous convient
et en mettant la cellule résultat au bon format (format date au lieu du format standard ?)
Bonjour
astragor a écrit :et en mettant la cellule résultat au bon format (format date au lieu du format standard ?)
Non toute concaténation, quelle soit faite par CONCATENER ou & ou autre, ne tient pas compte du format.
Il faut donc utiliser TEXTE comme suggéré par njhub, exemple
=A5&" "&TEXTE(B5;"jj/mm/aaaa")&" "&TEXTE(C5;"# ##0,00 €")bonjour à tous
à quoi peut bien servir de concaténer du texte et une date
bonjour,
jmd a écrit :bonjour à tous
à quoi peut bien servir de concaténer du texte et une date
a résoudre le pb d'affichage du numéro du jour, après opérations sur les dates,
pour afficher non pas le n° du jour mais bien la date,
ce qui est le résultat attendu dans la demande initiale
njhub a écrit :bonjour,
jmd a écrit :bonjour à tous
à quoi peut bien servir de concaténer du texte et une date
a résoudre le pb d'affichage du numéro du jour, après opérations sur les dates,
pour afficher non pas le n° du jour mais bien la date,
ce qui est le résultat attendu dans la demande initiale
pour afficher une date (qu'elle soit calculée ou saisie au clavier ) il suffit mettre la cellule au format voulu. Pas besoin de concaténer.
En fait j'explique mon problème à résoudre :
je dois aller chercher, dans un fichier à plusieurs feuilles formatées de manière identique, une case avec une date à l'aide de RECHERCHEV.
Mais si la recherche échoue, je ne veux pas N/A mais ""
Il y a douze onglets, donc avec la fonction SI ça fait imbriquer une formule énorme...
à moins qu'il y ait une autre solution?
Celle que j'ai trouvée avec mes petits moyens, c'est CONCATENER :
j'ai utilisé deux astuces trouvées à tâtons :
1-- pour avoir un chiffre en cas de RECHERCHEV infructueuse, j'ai ajouté l'argument "1" dans CONCATENER, et j'ai ensuite ajouté "-1" au total pour respecter la condition du SI (>0)
2-- pour résoudre le problème de format, j'ai simplement ajouté +0 à la fin dans la condition VRAI
Voici ma formule complète pour les experts qui pourraient peut-être me simplifier tout ça :
=
SI(
CONCATENER(
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX));"1")-1;
(
CONCATENER(
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Lesueur'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsSignes'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]CompromisFCPIANGLES'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]MandatsRetires'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]VendusFCPIANGLES'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeRetour'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]Vendus'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasInteret'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]contactsFCPI'!$P$4:$AA$1001);2;FAUX));
SI(ESTNA(RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX));"";RECHERCHEV(AA12;('[LESUEUR FCPI ANGLES V7.xlsm]PasDeNums'!$P$4:$AA$1002);2;FAUX))) +0
);"")
Merci à tous
beuhhhh (pleurs)
on voulait un fichier
Effectivement une formule de 3550 caractères mérite d'être simplifiée.
Vous faites votre recherche dans un second fichier, [LESUEUR FCPI ANGLES V7.xlsm]
pourquoi ne pas la faire directement dans le fichier concerné?
En rajoutant une feuille "Rechhe" qui reprendrait en A1 l'information que vous entrez en AA12
et à la ligne 1002 en colonne Q de chacun des onglets :
=SI(ESTERREUR(RECHERCHEV(Rechhe.A1;$P$4:$Q$1001);2;0);"";RECHERCHEV(Rechhe.A1;$P$4:$Q$1001);2;0))Puis pour rappatrier ces données dans l'onglet "Rechhe"
en B2 :
=Lesueur.Q1002en C2 :
=MandatsSignes.Q1002en D2 :
=CompromisFCPIANGLES.Q1002en E2 :
=MandatsRetires.Q1002en F2 :
=VendusFCPIANGLES.Q1002en G2 :
=PasDeRetour.Q1002en H2 :
=Vendus.Q1002en I2 :
=PasInteret.Q1002en J2 :
=contactsFCPI.Q1002en K2 :
=PasDeNums.Q1002En B3 :
=concatener(B2;"-";C2;"-";D2;"-";E2;"-";F2;"-";G2;"-";H2;"-";I2;"-";J2;"-";K2)Finalement en remplacement de votre formule initiale
=('[LESUEUR FCPI ANGLES V7.xlsm]Rechhe'!B3)Re
jmd a écrit :bonjour à tous
à quoi peut bien servir de concaténer du texte et une date
Il m'est arrivé de l'utiliser pour fabriquer des mentions à partir de plusieurs cellules, souvent pour du publipostage...
Mais ici effectivement ce n'est pas le souci...
ok merci de prendre du temps pour problème. c'est vraiment sympa;
1/ le problème c'est que cette formule est copiée dans tout un tableau, incrémentée donc AA12 puis AA13 etc...
2/ il me semble que l'on pourrait mettre la formule n'importe où pas forcément dans Q2 de chaque onglet?
d'autre par le fichier LESUEUR FCPI est partagé sur Dropbox avec un client et je ne veux pas qu'il soit géné par ces calculs qui ne le concernent pas. à moins aussi de vérrouiller les cellules concernées....
Bonjour à tous !
Je profite d'un moment libre pour livrer sur ce sujet, non une solution (car je n'ai pas encore compris la teneur exacte de la question
D'abord il me semble que c'est typiquement un sujet où l'absence de fichier illustrant clairement le résultat à atteindre produit une discussion partant en tous sens dont le résultat a de fortes probabilités de ne pas être particulièrement positif (il me semble aussi que je rejoins l'avis implicite de jmd sur ce point).
Je suis toujours effaré quand je vois une formule qui dépasse 3 lignes !
CONCATENER : je considère que c'est le prototype de fonctions complètement inutiles que peut parfois produire Microsoft. Elle n'ajoute en effet strictement rien à ce que l'on peut faire avec l'opérateur & et son utilité est de ce fait pratiquement nulle.
Alors qu'un =CONCATENER(A1:A12;" - ") qui produirait la concaténation des valeurs de la plage en les séparant par des tirets entourés d'espaces (ou tout autre séparateur que l'on passerait à la fonction) serait d'une grande utilité, force est de constater qu'Excel ne dispose que de peu de fonctions pour manipuler des chaînes et que l'on n'y parvient en les utilisant qu'au prix de formules complexes !
En regard, VBA offre en contrepartie nettement plus de possibilité en la matière, et d'un maniement considérablement plus aisé... A tel point que bâtir une fonction personnalisée en VBA est le plus souvent plus simple à concevoir et plus rapide à réaliser que contruire une formule avec des fonctions classiques pour tenter d'aboutir au même résultat.
Cordialement
re à tous
je suis d'accord avec MFerrand concernant la nécessité de joindre un fichier pour toute question sur le forum
https://forum.excel-pratique.com/forum-excel-pratique/2-suggestions-t68316.html suggestion n°2
je suis en complet désaccord avec lui concernant VBA
VBA est difficile à manipuler sans formation solide et sans pratique régulière.
VBA augmente en complexité dès qu'on crée 2 macros qui se chevauchent. Par charité, oublions classeurs avec 5 macros, ingérables.
VBA n'est pas stable (en cas d'évolution de Windows, de Mac, de tableur (OOO) ou de plateforme comme le Cloud et tout autre système de tableurs qui concurrence Excel). Bon en même temps les TCD que j'adore ne sont pas toujours bien supportés mais c'est mieux.
avec l'évolution des formations scolaires (de mauvaise qualité, MFerrand tu confirmes ? ) on va bientôt voir des gens qui ont "appris" VBA mais ne savent pas faire une addition avec = et + et qui voudront une macro pour calculer 1+1
concernant les formules à rallonge, il suffit de les éclater en 3 ou 4 cellules pour mieux les maîtriser. Je ne m'en prive pas en créant souvent 3 colonnes de pointage au lieu d'une seule pour mieux comprendre la manoeuvre.
Ainsi décomposée, une longue formule devient le plus souvent compréhensible et modifiable même avec un petit niveau Excel.
Au fait, pourquoi Microsoft cache VBA dès l'installation d'Excel ?
avec ce long discours, je ne veux fâcher personne, MFerrand tu sais bien.
amitiés excelliennes à tous.
Terrible !
avec ce long discours, je ne veux fâcher personne, MFerrand tu sais bien.
Pas de souci de ce point de vue !
Au fait, pourquoi Microsoft cache VBA dès l'installation d'Excel ?
Je suppose que lorsqu'un utilisateur d'Excel est en mesure d'accéder à l'éditeur VBA, il a acquis une connaissance d'Excel suffisante pour éviter de faire des catastrophes avec VBA, si on résume... Et si c'est le cas, Microsoft a tout à fait raison de ne pas ouvrir l'accès à VBA par défaut lors de l'installation.
Mais on ne peut pas dire que ce soit vraiment caché, l'accès est documenté, et l'expérience montre qu'on peut y accéder facilement sans avoir aucune idée de ce qu'on fait...
VBA est difficile à manipuler sans formation solide et sans pratique régulière.
Hélas non !
Mais je suis bien d'accord que cela exige quelques connaissances minimales et qu'il convient de les acquérir, puis de les accroître avec l'usage. On a vu des internautes arriver sans connaissance en la matière, qui s'y sont mis et ont progressivement maîtrisé leur sujet, et même de façon assez rapide... trop peu nombreux certes, mais la démarche est possible et elle donne des résultats, comme en tout domaine.
VBA augmente en complexité dès qu'on crée 2 macros qui se chevauchent. Par charité, oublions classeurs avec 5 macros, ingérables.
D'abord, quand on pense macro, on est déjà dans l'erreur ! On doit penser projet et recours à la programmation justifié par la nature du projet, on doit concevoir le projet et son programme d'utilisation, dans son ensemble et dans ses parties, dans le détails et avec toutes les interactions susceptibles de se produire, avant de penser à écrire la première ligne de code...
Et je dirai que pour un projet simple un programme simple se matérialisera en moyenne par une vingtaine de procédures, si on programme correctement, de façon dite modulaire, de façon à avoir des procédures qui ne font en général qu'une chose et la font bien... Il m'est arrivé de voir des macros à rallonge fourre-tout, dont on n'arrive plus à savoir ce qu'elle fait ou pas, dont le nombre de lignes de code est supérieur à celui de mes 20 procédures évoquées mises bout à bout, toujours remise en chantier pour essayer de la faire fonctionner normalement, mais telle que conçue elle ne le pourra jamais !
Je laisse de côté le cas de macros destinées à faire une opération une fois, que l'on trouve trop longue ou pénible à réaliser manuellement (surtout quand quelqu'un d'autre fait la macro !
VBA n'est pas stable (en cas d'évolution de Windows, de Mac, de tableur (OOO) ou de plateforme comme le Cloud et tout autre système de tableurs qui concurrence Excel). Bon en même temps les TCD que j'adore ne sont pas toujours bien supportés mais c'est mieux.
Là tu es un peu de mauvaise foi !
Ensuite, les problèmes entre plateformes ne sont pas nouveaux et aucune responsabilité côté VBA ! On connaît des problèmes avec Mac parce que Microsoft n'a pas fait d'effort particulier pour les résoudre et Apple n'a pas non plus fait en sorte qu'Office fonctionne parfaitement sur son système... VBA n'est pas utilisable sous Open Office, c'est fort dommage mais il faudrait changer les règles commerciales... !
En fait, nous aurions tendance à être plutôt d'accord et je trouve dommageable que tu te refuses l'utilisation d'un outil susceptible de rendre des services, ne serait-ce que dans les cas où Microsoft n'apporte pas d'autre solution. Que tu ne souhaites pas recourir à VBA est une chose mais mettre un interdit systématique en est une autre... Je n'ai pas recours aux TCD, je ne raffole guère non plus des tableaux Excel, et il se trouve que je n'ai pas besoin d'en utiliser dans mes activités propres, mais si le cas survenait et que cela m'apporte une solution plus simple, je n'hésiterais pas... !
concernant les formules à rallonge, il suffit de les éclater en 3 ou 4 cellules pour mieux les maîtriser. Je ne m'en prive pas en créant souvent 3 colonnes de pointage au lieu d'une seule pour mieux comprendre la manoeuvre.
Ainsi décomposée, une longue formule devient le plus souvent compréhensible et modifiable même avec un petit niveau Excel.
Bien sûr tu as raison sur ce point !
Ceci dit, dans mes propres fichiers je préfère souvent éclater sur des cellules relais masquées plutôt que d'utiliser une matricielle complexe qui sera plus gourmande en ressources que l'ensemble des formules simples résultant de l'éclatement. Ce qui n'empêche pas de saivoir faire les deux !
Ensuite, des formules trop longues peuvent résulter du fait que l'on veut faire faire trop de choses à une seule formule, mais aussi de la méconnaissance de certaines fonctions que l'on pourrait substituer à celles qu'on utilise et qui raccourcirait, ou de façon de formuler permettant aussi de raccourcir...
Mais dans tous les cas, le choix du recours à VBA ou non doit reposer sur d'autres critères... Il est bien évident que s'il s'agit de se tourner vers VBA parce qu'on n'est pas capable de formuler correctement, je ne bougerai pas le petit doigt pour apporter mon aide !
Mais dans les cas où VBA s'avère plus simple, plus pratique et plus efficace, on aurait tort de ne pas y recourir...
Et je dois dire que s'agissant de manipulations de chaînes, j'ai fait suffisamment de fonctions personnalisées pour pouvoir constater que c'est toujours plus simple qu'avec formules et plus rapide (temps d'écriture de la fonction inclus !) Et ce faisant j'ai le sentiment qu'on ne fait que pallier les insuffisances de Microsoft en matière de fonctions relatives aux chaînes de texte !
On peut certes dans un certain nombre de cas aller puiser dans les matricielles texte de Boisgontier, je ne m'en prive pas ! Et souhaitant toujours savoir comment faire par formules si j'y parviens, j'étudie les solutions possibles, mais au moment de la décision je me tourne en principe toujours vers le plus simple...
Et lorsqu'on a du texte brut à traiter pour en extraire un certain nombre de données, l'envisager avec des manipulations (manuelles) et des formules peut à la rigueur se concevoir si c'est une opération unique, mais selon les cas et si elle doit être répétée, le recours à VBA peut éventuellement apporter une solution...
Et je laisse de côté les cas où les formules alourdissent quelque peu un classeur... Moi qui fait en sorte de ne pas avoir de classeur qui atteigne et dépasse 1 Mo !
avec l'évolution des formations scolaires (de mauvaise qualité, MFerrand tu confirmes ? ) on va bientôt voir des gens qui ont "appris" VBA mais ne savent pas faire une addition avec = et + et qui voudront une macro pour calculer 1+1
Les macros pour faire 1+1, on a déjà vu le cas !
Je ne sais pas si les formations scolaires sont de mauvaise qualité, je ne me prononcerai donc pas sur ce point. Il est certain que ce n'est plus ce qu'on a connu antan !
Bonne journée.