Bug Numbers specifique à Yosemite?

[Dj No Smile]

Bonjour, je me trouve dans une situation étrange :

J'ai une feuille de calcul que j'ai faite dans numbers et qui fonctionnait parfaïtement sous snow Leopard. J'ai (malheureusement) depuis fait la MAJ vers Yosemite et il s'est avéré qu'une formule ne fonctionnait plus. Je n'ai aucune erreur affichée mais le résultat reste "0". J'ai d'abord pensé que c'était parce que je lançais toujours la version 2 de Numbers. J'ais donc fait la MAJ vers la version 3 mais le problème persiste. Je me dis qu'il y a peut-être une astuce que je n'ai pas saisi mais je ne vois aucune raison qui expliquerait le fait que cette formulation ne fonctionne tout à coup plus du tout...

Voici la formule :

Code

=SOMME.SIS(base tva; Facturier de sortie::Listing::Date; ">="&B1; Facturier de sortie::Listing::Date; "<"&EDATE(B1;3) )

Evidemment, les cases "Facturier de sortie::Listing::Date" est "B1" sont toutes les deux des dates. Visiblement, il n'aime pas les concaténations dans la definition des 2 conditions :

Code

">="&B1
"<"&EDATE(B1;3)

En effet, si je note les dates équivalentes en dur, tout fonctionne parfaïtement :

Code

">= 1/10/2014"
"< 1/1/2015"

Quelqu'un aurait une idée? J'avoue que je sèche un peu la...

Merci d'avance

[KOENIG Yvan]

Bonjour
Désolé, je ne passe pas tous les jours sur les forums.

Pour être sûr que ce que je décris est compréhensible je décris tous les composants.
Le document de travail contient deux feuilles.
La seconde nommée "Facturier de sortie" contient une table nommée "Listing".
Cette table est dotée d'une ligne de titre.
En D1 j'ai saisi : "Date"
En D2 : 31/12/2014
En D3 : 05/01/2015
En D4 : 06/01/2015
En D5 : 14/07/2015


La première feuille est dotée d'un nom sans importance et contient une table au nom tout aussi dépourvu d'intérêt.
Cette table est également dotée d'une ligne de titre.
En B1 j'ai saisi la date 01/01/2015
En C1 j'ai saisi : =si( lignes($A) ≠ lignes(Facturier de sortie::Listing::$Date); "les tables doivent avoir le même nombre de lignes";"")
Le message apparaîtra si je ne prends pas garde à doter les deux tables du même nombre de lignes comme l'exige la fonction SOMME.SIS.

En C2 : 10
En C3 : 20
En C4 : 30
En C5 : 40


En E2 j'ai saisi la formule :
=SOMME.SIS(C; Facturier de sortie::Listing::Date; ">="&$B$1; Facturier de sortie::Listing::Date; "<"&EDATE($B$1;3) )
et j'obtiens le résultat attendu : 50

J'ai la vague impression que votre problème est du au fait que vous avez omis de bloquer la référence sur $B$1.

Yvan KOENIG (VALLAURIS, France) samedi 24 janvier 2015 16:37:03

Ce message a été modifié par KOENIG Yvan - 24 Jan 2015, 16:28.

[Dj No Smile]

Bonjour,

Pas de problème, merci déjà de m'aider

J'ai tenté de bloquer la référence à B1 comme proposé, et ça n'a rien changé.

Chose étonnante, si je produit un document neuf et encode ce type de formule, comme vous l'avez fait, tout fonctionne à merveille et même et ce que l'on bloque ou non la référence à B1... Le problème est donc ailleurs...

Ce que je ne comprends pas, c'est que ce document de travail fonctionnait parfaitement avant et que je n'ai absolument rien changé aux formules...

Encore plus étonnant, j'ai créé une nouvelle feuille dans ce document avec un tableau avec en B1, la date et en B2, la formule et tout a parfaitement fonctionné. Mais, lorsque je copie-colle la formule dans la feuille originale (qui a la même date en B1), j'ai à nouveau 0 comme résultat... Même chose si je fait un nouveau tableau dans la feuille principale

Encore plus étrange, si dans ces tableaux/feuille test je change la référence B1 (la date) et que je met cette référence à la case du tableau original, alors le résultat vaut à nouveau 0 alors que toutes les cases B1 contiennent bien la date 1/10/2014 00:00:00...

Ça commence furieusement à ressembler à un bug...

:S

Bon, je pourrais réencoder toute ma première feuille mais j'aimerais bien comprendre, surtout si ça risque de se reproduire...

[KOENIG Yvan]

Pouvez-vous m'envoyer le document capricieux ?
Mon adresse est koenig <point> yvan <at> sfr <point> fr.

Puisque le document fonctionnait sous Snow-Leopard, il a subi plusieurs conversions de format.
La structure des documents d'iWork dans son incarnation la plus récente est complètement différente des structures mises en œuvre précédemment.
Du coup, je ne suis pas outre-mesure surpris que le réencodage qu'il a subi s'accompagne de quelques effets pervers.
Ne comptez pas sur moi pour nier l'éventualité de bugs dans une application que je considère, dans sa version 3.x comme un jouet alors que la version 2.x était un outil.
Il ne se passe pas de semaine sans que je sois contacté par des utilisateurs dont les documents refusent de s'ouvrir.
Heureusement, grâce à trois scripts je peux souvent les dépanner en leur permettant d'extraire des données stockées par la fonction système "Versions" une version fonctionnelle de leur document.
Dans le cas précis qui nous intéresse ici, je vous suggère ceci :
Pour chaque table, tout sélectionner
appliquer le format texte
copier
coller dans un document TextEdit en format texte.
enregistrer chaque fichier texte ainsi créé.
Quand tout sera terminé,ouvrir ces fichiers texte - ce sont des fichiers Tab Separated Values - avec Numbers.
Dans l'un des documents Numbers ainsi créés, reconstruisez la structure initiale de feuilles et tables en récupérant les tables recréées.
Quand tout sera en place, redéfinissez les formats des différentes cellules.
Vous retrouverez vos formules et - normalement - cette fois elles fonctionneront correctement.

Enfin, n'oubliez pas que la règle de base est de toujours conserver plusieurs versions successives des documents importants.
Dupliquer la dernière version ne sert à rien. Si elle a été corrompue lors de l'enregistrement, ses copies le seront également.

Bon courage.

Yvan KOENIG (VALLAURIS, France) dimanche 25 janvier 2015 10:58:46

[Dj No Smile]

Bonne idée. Je peux vous envoyer ça ce soir mais je vais d'abord tenter la reconstruction d'un document à partir des données.

Je suis tout à fait d'accord avec la version 3... Le plus étonnant est que le bug était déjà présent alors que j'ouvrais mon document avec la version 2 sous Yosemite (que je n'avais pas mis à jour justement pour éviter les restrictions de la version 3....). Par contre, je ne peux pas garantir qu'il était là tout de suite étant donné que j'ai édité une feuille secondaire plusieurs fois avant de revenir à la feuille principale. Ceci dis, j'ai essayé de revenir à une ancienne version via time machine et jamais, la page principale n'a fonctionné correctement...

Par contre, du coup, j'hésite sur un point : J'ai encore la version 2 de Numbers. Est-ce que je crée mon nouveau document sous cette version (qui présente le bug malgré tout) ou sous la 3?

[KOENIG Yvan]

Je ne peux choisir pour vous.
Tout ce que je peux ajouter, c'est que si votre document manipule des tables dotées de nombreuses lignes, Numbers 3.x sera plus réactif.
Je manipule actuellement des tables de 54500 lignes et la version 3.5.2 est bien plus réactive. Par contre, pour gérer mon compte bancaire je reste sur la version 2.3 avec des tables de moins de 2000 lignes.
Indication utile : le même tableur voit la taille de son fichier multipliée par environ 10 en passant de 2.3 à 3.5.2.
J'ai presque honte de ça mais, pour mes discographies de jazzmen, j'ai adopté LibreOffice.
La réactivité est bonne et surtout, les documents au format ODT sont bien moins encombrants que les fichiers Numbers.

Yvan KOENIG (VALLAURIS, France) dimanche 25 janvier 2015 12:41:32

PS: dans votre document, quel est le format attribué à la cellule B1 ? Automatique ou Date et heure ?
Lorsque je dois effectuer des comparaisons à une date, je spécifie explicitement le format Date et heure.
Parfois même, je ne stocke pas la date mais j'utilise une formule : =DATE(année; mois; jour)
Ce faisant, je suis à l'abri d'une modification malencontreuse du format au niveau système.


Ce message a été modifié par KOENIG Yvan - 25 Jan 2015, 12:37.