help : informatique ...

de **ulys** » 12/09/2019 08:25

Message précédent :
Ca sert vraiment à rechercher une correspondance.

voici la formule sur la première ligne
=SI((N14+O14=0);"";SI(OU(ET((N14<=RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186));(O14<=RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186));(RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186)=3));ET((N14<=RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186));(O14<=RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186));(RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186)=2);(N14-O14<=0,4);(O14-N14<=0,4)));"OK";"NC"))

R! car la liste de recherche est sur la feuille R (première image).

de **Olaf Le Bou** » 12/09/2019 08:49

les colonnes A de la feuille R et E de ta recherche sont au format texte ??

de **ulys** » 12/09/2019 08:55

Oui. Obligatoire pour qu'il m'affiche les "0". (par exemple 0339)
Idem dans la colonne E de l'autre feuille.

de **vich** » 12/09/2019 09:50

Le problème vient, à priori, du nombre 512210 stocké avant le 0140.2. Ce doit être un des effets du "Les nombres stockés en tant que texte peuvent générer des résultats inattendus" indiqué par la doc.

En tout cas, je peux facilement reproduire le problème et il suffit de retirer ce nombre pour que ça fonctionne.

Pour résoudre le problème, il faudrait à mon avis que tous tes nombres en colonnes A et E soient des nombres stockés en tant que texte, autrement dit, que tu utilises la virgule et non le point comme séparateur.

Edit: accessoirement, il y a beaucoup de parenthèses inutiles, dans ta formule. Ça n'aide pas à la clarté.

de **MLH** » 12/09/2019 10:04

vich a écrit:Pour résoudre le problème, il faudrait à mon avis que tous tes nombres en colonnes A et E soient des nombres stockés en tant que texte, autrement dit, que tu utilises la virgule et non le point comme séparateur.

Ou bien mettre les 2 colonnes au format Texte, les convertir et ensuite trier les colonnes A et B.

vich a écrit:Edit: accessoirement, il y a beaucoup de parenthèses inutiles, dans ta formule. Ça n'aide pas à la clarté.

Moi c'est quand ce n'est pas le style de référence L1C1 que j'ai beaucoup de mal à lire les formules

On a tous nos habitudes :-D

de **Olaf Le Bou** » 12/09/2019 10:06

je ne crois pas que cela suffise, j'ai créé plusieurs listes de chiffres, et/ou de lettres et/ou de points, et même sans la référence 512210 c'est bourré d'incohérences.

j'ai essayé avec un RechercheV et c'est rigoureusement pareil. et le plus bizarre c'est que selon l'ordre des items, des OK deviennent NC et réciproquement. mais le suivi pas à pas nous dit bien que c'est la première recherche qui foire.

dans mon tableau, tout chiffre inférieur à 0333 donne un NA, ainsi que toute ref commençant par un caractère spécial.

de **ulys** » 12/09/2019 10:22

Merci en tout cas à tous

Chez moi en supprimant le 512210 (et 512110) ça ne fonctionne toujours pas. Mais de toute façon, j'en ai besoin.

Tout mes nombres sont en texte dans les deux collonnes. Par ocntre je suis obligé d'utiliser le point (sur le clavier alpha). Car mon point sur le clavier numérique donne une virgule que je ne veux pas (et que je ne peux pas paramétrer).

Pour les parenthèses en trop... oups, pourtant j'essaie de faire simple, mais j'apprends sur le tas...

Ne vous prennez pas trop la tête non plus. Dans 4 mois je quitte mon travail !

Je peux envoyer le fichier xlsx.

de **vich** » 12/09/2019 10:36

ulys a écrit:Chez moi en supprimant le 512210 (et 512110) ça ne fonctionne toujours pas. Mais de toute façon, j'en ai besoin.

Ce n'est pas "que" le nombre 512210, mais toute la série qui est avant. Alphabétiquement parlant, les 6 nombres (ou plus) qui se situent avant devraient se trouver après. Amha, c'est cela qui fait foirer la fonction RECHERCHE.
En remplaçant 5212210 par 00512210 par exemple, ça remarche.
La question est donc pourquoi se trouvent-ils placés au dessus ? Ça ne doit pas être le résultat du tri (en tout cas, quand j'essaie chez moi, il sont bien placés après), donc j'imagine que c'est voulu ?

de **ulys** » 12/09/2019 10:43

C'est bien le résultat du tri pourtant.

Il me tri ça comme ça :
0339
0401
0403
0451
0490
0583
0584
0586
0587
0642
0733
0767
0778
1206
1207
1331
1456
1458
1486
1487
1547
1578
1595
1846
2415
2425
2427
2469
3874
3875
3876
4054
4100
4101
4102
4112
4113
4116
4117
4119
4121
4306
4309
4316
4317
4318
4319
4320
4339
4346
4469
4471
4472
4473
4474
4477
4527
4528
4529
4997
5602
5603
5605
5606
5607
5608
5609
5610
6052
6100
6101
6108
6109
6110
6115
6116
6119
6120
6123
6124
6127
6128
6130
6132
6134
6136
6138
6143
6144
6145
6146
6147
6148
6149
6151
6152
6153
6154
6156
6157
6162
7793
8122
8350
76177
76178
76180
76185
76274
76275
76276
76279
76281
76473
91067
91068
91072
91076
91077
93051
93054
512110
512210
0140.2
0141.1
0303.1
0395A
0995.1
0996.1
0997.2
0998.2
1436.1
1459.1
1511.1
1512.1N
2416.R
2428.1N
2429.1N
2430.1N
2431.1N
2432.1N
2433.1N
2434.1N
2435.1N
2436.1N
2437.1N
2438.1N
2501.R
2502.R
4103.1
4104.2
4109.2
4110.1
4129.1
4512.2
6102.1
6104.1
6105.1
6105.1R
6106.1
6107.1
6111.1
6112.2
6113.1
6117.2
6118.1
6121.2
6122.1
6126.1
6129.1
6131.1
6133.1
6141.1
6150.1
6155.1
M
P2205
P2238
P2249
P2271
P2282
P2650
P2675
P2679
P2690

de **MLH** » 12/09/2019 10:50

En remplaçant la fonction RECHERCHE par un RECHERCHEV, j'obtiens le retour NC pour les 3 valeurs. Par contre, j'ai un #N/A pour les lignes 93051 et 93054

Et sinon fonctionnellement qu'est-ce que tu veux faire avec ces données ? Quel est la logique de la formule ?

de **vich** » 12/09/2019 10:55

ulys a écrit:C'est bien le résultat du tri pourtant.

Donc le tri chez toi fait la différence entre nombres stocké sous forme de texte et "vrai" texte. Bizarre, ce n'est pas le cas chez moi.
Essaie peut-être en définissant le point et non la virgule somme séparateur décimal.

NB: pourquoi ne peux/veux-tu pas utiliser la virgule dans ton fichier ?

Edit: ha ben non, tu as des données purement texte, dans ta liste :cry2:

de **ulys** » 12/09/2019 10:55

MLH a écrit:En remplaçant la fonction RECHERCHE par un RECHERCHEV, j'obtiens le retour NC pour les 3 valeurs. Par contre, j'ai un #N/A pour les lignes 93051 et 93054

Et sinon fonctionnellement qu'est-ce que tu veux faire avec ces données ? Quel est la logique de la formule ?

En fonction de la référence (0140.2 – 6110 …) j’ai une tolérance de 2 ou 3.
Donc en fonction, ma mesure est OK ou NC.
Quand la tolérance est de 2 je n’ai pas le droit d’avoir un écart de +0.4 entre les deux mesures.
Certaines références n’ont qu’une seule mesure (pas celles avec la tolérance de 2 normalement).
Je veux que ce soit vide quand je n’ai pas de mesure.

de **ulys** » 12/09/2019 10:59

vich a écrit:
ulys a écrit:C'est bien le résultat du tri pourtant.

Donc le tri chez toi fait la différence entre nombres stocké sous forme de texte et "vrai" texte. Bizarre, ce n'est pas le cas chez moi.
Essaie peut-être en définissant le point et non la virgule somme séparateur décimal.

NB: pourquoi ne peux/veux-tu pas utiliser la virgule dans ton fichier ?

Je ne peux changer la définition du point comme séparateur. (séparateur allemand apparement)
Tout est bloqué par notre service IT allemand qui ne sait pas le faire d'office (nous sommes sous Citrix).

Parceque la référence deviendrait fausse (c'est certainement du chippotage de ma part :oops:

).

de **vich** » 12/09/2019 11:26

Je peux comprendre, j'ai travaillé pour une boite allemande pendant 16 ans (Siemens, pour ne pas la nommer)

Proposition suivante: si c'est toi qui fait le tri, peux-tu essayer de cliquer sur le bouton "Trier" plutôt que directement sur le tri descendant (fig 1) ? Logiquement, tu devrais avoir un premier popup, cliquer sur OK, deuxième popup (fig2), vérifier que l'option "trier séparément les nombres et les nombres stockés en tant que texte" est cochée. Ceci devrait changer ton tri. Voir ensuite si, du coup, ton problème est résolu ...

de **ulys** » 12/09/2019 11:42

Là ca marche maintenant.
Bon j'ai eu du mal à faire venir ce pop-up.

Parcontre maintenant, pour la référence qui n'existe pas dans la liste il me met des OK ou NC au hasard... mais c'est moins grave.

merci

de **Charlus** » 12/09/2019 12:05

ulys a écrit:Parcontre maintenant, pour la référence qui n'existe pas dans la liste il me met des OK ou NC au hasard... mais c'est moins grave.

Tu peux compléter ta fonction recherche :
=RECHERCHEV(Valeur recherchée;base de recherche;position de la valeur à renvoyer;FAUX)

ça donnerait ça
RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186;FAUX)

ça te renverra un #NA de mémoire.

de **vich** » 12/09/2019 12:19

ulys a écrit:merci

Avec plaisir

Un des problèmes liés aux "correcteurs automatiques". Tu as beau lui dire que c'est du texte, la fonction TRI se dit "mais il est bête, le gars, c'est pas du texte mais du numérique", et du coup le traite comme tel. Alors que la fonction RECHERCHE, elle, se base uniquement sur un tri alphabétique :roll:

.

Pour être complet, la valeur #N/A est une valeur de retour possible de la fonction RECHERCHE, et donc, il faudrait tester cette possibilité à chaque utilisation de RECHERCHE (à l'aide de la fonction ESTNA). Mais ... ça va encore compliquer ta formule

, donc si tu changes bientôt de boulot

de **MLH** » 12/09/2019 12:41

vich a écrit:
ulys a écrit:merci
Tu as beau lui dire que c'est du texte, la fonction TRI se dit "mais il est bête, le gars, c'est pas du texte mais du numérique", et du coup le traite comme tel.

C'est ce que j'appelle la pseudo intelligence embarquée dans Excel

Et les formats dans Excel... des fois je n'ai qu'une envie...
:Violence:

de **vich** » 12/09/2019 12:57

Moi de même

de **Anianka** » 12/09/2019 13:10

oui, j'allais le dire, il manque le FAUX a la fin pour n pas retourner les valeurs proches.
par contre, du coup il faut gérer le faite que certaines recherches ne retournent rien (#N/A)

par contre je ne comprend pas ta formule.
Si je comprend bien, tu veux faire ça :

1 : il te faut le seuil dans les colonnes A:B (en faisant une somme tu t'en fous du tri si tu n'as pas de doublons, si pas trouvé, seuil à 0)
==> SOMME.SI('R'!A:A;E14)
2 : il te faut la valeur absolue du delta entre les 2 mesures :
==> ABS(N14 - O14)
3 : après tu veux tester tes valeurs pour dire OK/NC :
-- Si N14 et O14 sont <= seuilET seuil = 3 ==> OK
-- Si N14 et O14 sont <= seuilET seuil = 2 ET delta <= 0.4 ==> OK
-- Sinon : NC

du coup, c'est j'ai pas trouvé de solution pour faire en recherchev total car les matrices A:B et N:O ne font pas la meme taille.
Est-ce que tu peux rajouter en colonne Q la formule suivante pour chercher le seuil
= SOMME.SI('R'!A:A;E14;'R'!B:B)
et en colonne R le delta :
= ABS(O14-N14)

et du coup, ta formule de contrôle devient simplement :
=SI(E14="";"";SI(ET(MAX(N14;O14)<Q14;OU(Q14=3;ET(Q14=2;R14<=0,4)));"OK";"NC"))

de **ulys** » 12/09/2019 13:17

Charlus a écrit:
ulys a écrit:Parcontre maintenant, pour la référence qui n'existe pas dans la liste il me met des OK ou NC au hasard... mais c'est moins grave.

Tu peux compléter ta fonction recherche :
=RECHERCHEV(Valeur recherchée;base de recherche;position de la valeur à renvoyer;FAUX)

ça donnerait ça
RECHERCHE(E14;'R'!$A$2:$A$186;'R'!$B$2:$B$186;FAUX)

ça te renverra un #NA de mémoire.

Ca marche ! :ok: