[Intégré 5.8.57.5391] Masque de saisie pour les chèques et Justification des colonnes

[noftal]

Bonjour,

Je ne sais pas ce que vous en pensez, mais je trouve que les chiffres seraient plus lisibles dans les colonnes de tableau s'ils étaient tous alignés à droite. C'est le cas de certains, mais pas de tous. Certains sont en effet centrés.
Bizarrement, je ne m'en étais pas rendu compte jusqu'ici. J'en viens même à me demander s'il en a toujours été ainsi.

[Patrice15220]

Bonsoir,

En effet, certaines colonnes Nb et % sont centrées. Moi non plus, je ne m'en étais pas rendu compte jusqu'à ce jour.
Comme quoi, on regarde sans voir...

J'avais également, il y a quelques temps, demandé à Jacques pourquoi le formatage de la colonne des références bancaires était de type "0 000 000", et il m'avait été répondu qu'il était plus facile de lire un chiffre sous la forme 99 999 999 999,99. Sauf que les références bancaires ne peuvent pas excéder 7 caractères et sont formatées par les organismes bancaires sur 7 caractères significatifs (par ex. un n° de chèque : 0000152) en alpha numérique.

[Jacques Leblond]

Bonsoir,
Oui il en a toujours été ainsi, ce n'est pas quelque chose que j'ai changé.
A priori j'aligne les nombres sur la droite, mais si je ne l'ai pas fait pour certains c'est que j'ai du trouver à l'époque que le rendu était mieux centré. Le "centré" est satisfaisant si la longueur du nombre est fixe, ce qui est rarement le cas d'ou l'alignement sur la droite.

En regardant rapidement, il y en a effectivement sur les modules Performance et Valorisation des portefeuilles.
Vous en avez remarqué sur d'autres modules ?

il m'avait été répondu qu'il était plus facile de lire un chiffre sous la forme 99 999 999 999,99. Sauf que les références bancaires ne peuvent pas excéder 7 caractères et sont formatées par les organismes bancaires sur 7 caractères significatifs (par ex. un n° de chèque : 0000152) en alpha numérique.

Oui c'est valable pour du numérique ou de l'alpha, longueur fixe ou pas. C'est soit xx xx xx ... ou xxx xxx xxx ..., au delà ce n'est plus adapté pour notre cerveau de primate.
Et ne pas séquencer ne me convient pas car c'est très difficile à lire.
Note : à l'export les espaces n'existe pas.

[Patrice15220]

n regardant rapidement, il y en a effectivement sur les modules Performance et Valorisation des portefeuilles.
Vous en avez remarqué sur d'autres modules ?

A priori, non.

Oui c'est valable pour du numérique ou de l'alpha, longueur fixe ou pas. C'est soit xx xx xx ... ou xxx xxx xxx ..., au delà ce n'est plus adapté pour notre cerveau de primate.
Et ne pas séquencer ne me convient pas car c'est très difficile à lire.

Je ne partage pas ton avis, mais cela n'engage que moi. D'ailleurs lorsque l'on importe les fichiers OFX les références alphanumérique de type "00KC56B" ne sont pas séquencées ce qui est très bien.

Note : à l'export les espaces n'existe pas.

Exact et c'est parfait pour pouvoir traiter les informations dans un tableur.

[Jacques Leblond]

Dans GesFine le séquençage ne s'effectue que pour les nombres, dès qu'il y a des caractères Alpha, il n'est pas réalisé car le champ peut être renseigné comme on le souhaite, avec des "vrais" mots pourquoi pas.

J'indiquais juste que le séquençage est utile pour du numérique ou de l'alpha dès qu'il n'est pas significatif. Il n'y a qu'à voir la difficulté à lire une clé WAP de wifi.

Si tu exportes tes données de GesFine en Ofx elles ne seront pas séquencées. Le format Ofx est un format d'échange, pas de consultation.

[Patrice15220]

Il n'y a qu'à voir la difficulté à lire une clé WAP de wifi.

Sauf qu'une clé WEP comporte 26 caractères alors qu'une référence bancaire en contient 7 uniquement y compris pour les numéros de chèques avec les zéros significatifs (ex. 0000005).
Je classe.

[Jacques Leblond]

Le séquençage est utile au delà de 3. Un numéro de téléphone n'a que 8 caractères et le séquençage par 2 caractères s'est généralisé. Si je retrouve l'étude sur le sujet je te mettrais le lien.
J'ai voulu le vérifier en faisant des tests de rapidité, les différences sont très significatives. Quand tu lis un chiffre long, tu le séquences naturellement, le format n'est donc là que pour simplifier la lecture.

[Jacques Leblond]

Pour revenir à la remarque de Steph, j'ai parcouru tous les tableaux et fait l'alignement sur la droite de tous les nombres, j'ai vu le nombre d'opérations dans les budgets et le nombre de parts dans le bilan des opérations, le nb de parts, les frais et les différents % dans les modules Performance et Valorisation des portefeuilles.

Ce sera modifié dans la prochaine version.

[noftal]

... si vous êtes d'accord. Je ne veux pas imposer mon point de vue. C'est assez subjectif comme préférence.

[Jacques Leblond]

C'est assez subjectif comme préférence.

Hormis pour le nombre de parts et d'opérations, les modifications que j'ai effectuées donne un bon rendu et cela donne de la cohérence avec toutes les autres colonnes, parfois similaires, déjà alignées à droite.

Pour le nb de parts, le centrage n'est pas adapté lorsqu'il y a des décimales, lorsque le nombre est entier, j'ai une petite préférence pour le centrage, donc alignement à droite pour couvrir les 2 cas.

Reste le nombre d'opérations dans le budget (valeur toujours entière) où j'ai un doute car la colonne est assez large pour afficher l'entête et le nombre calé à droite prendre très peu d'espace dans la cellule. Mais par cohérence avec toutes les autres colonnes je vais rester sur un alignement à droite.

[Jacques Leblond]

L'alignement à droite de toutes les colonnes contenant des nombres a été réalisé dans la dernière version intermédiaire.

Concernant le format du champ "Référence, N°" des opérations, j'ai abandonné la mise au format automatique si le champ ne contenait que des caractères numériques au profit d'un masque de saisie activable uniquement pour les opérations de type "Chèque émis" et "Chèque reçu".
Le masque se définit dans les propriétés du compte, il peut donc être spécifique à chaque compte.
En l'absence de masque, le champ est libre.
La syntaxe du masque doit être réalisée selon cette spécification.

Quelques exemples de masque possibles :

Numéro de chèque forcé sur 7 caractères

0000000

Numéro de chèque forcé sur 7 caractères avec séquençage du champ pour une lecture facilité

0 000 000

Numéro de chèque précédé du code abrégé de la banque sur 2 ou 3 caractères avec forçage des lettres en majuscule

>LL? 0000000

A noter qu'en présence d'un masque, les caractères non renseignés seront remplacés par un tiret bas (underscore) pour leur stockage dans la base de données.

La recherche automatique du numéro de chèque est compatible avec un masque mais ce dernier ne sera renseigné que par les caractères composant le numéro trouvé.
Concrètement le numéro ne sera pas précédé de 0 pour obtenir un numéro sur 7 caractères par exemple.

Enfin la définition d'un masque doit être compatible avec les données déjà présentes dans le champ "Référence, N°" des opérations par chèque. Dans le cas contraire, le contenu du champ pourrait ne pas être récupérable dans le masque et perdu si le formulaire de l'opération est validé.

[Patrice15220]

Bonjour Jacques,

Encore merci, et je ne sais quoi te dire pour ton écoute, ta réactivité et tes développements.

[Patrice15220]

Jacques, en voulant modifier une écriture qui ne comporte pas encore de références, j'ai eu un message d'erreur :

et ceci même en supprimant le masque de saisie.

[Jacques Leblond]

Ok, je n'ai pas testé la cas ou aucune référence n'existe... ! J'ai publié une nouvelle version.

[Patrice15220]

Nouvelle version testée, c'est OK. Merci Jacques.

[noftal]

Merci Jacques !

[Jacques Leblond]

Fonctionnalité développée dans la version 5.8.57.5391.