Page 1 sur 1

Template Facture

Publié : 23 décembre 2013, 20:29
par dinobib
Bonjour,

Je suis en train créer un modèle de Facture et je coince sur quelques points.

Au niveau de la date, j'ai cherché sur internet, mais je ne trouve pas les valeurs possibles pour les dates.
Je voudrais modifier le résultat {{ date | date_format: MM/dd/yyyy }}
afin que le format donne un résultat en toutes lettres : vendredi 23 mars 2013 par exemple.
Quel format devrais-je utiliser pour cela si c'est bien implémenté ?
D'après mes recherches j'ai cru comprendre qu'il fallait certainement que soit définit la locale de la date pour pouvoir obtenir ce type de résultat.

Autre point qui me gêne, c'est le fonctionnement du champ {{ address }}.
Dans un premier temps, l'import dans icompta d'un client du carnet d'adresse ne fonctionne pas (la fenêtre de choix qui s'affiche est entièrement vide) et après avoir créé les clients, le champ adresse ne comporte qu'une ligne. Je n'arrive pas ainsi à faire ressortir la rue et le code postal et la ville sur des lignes séparés. Il y aurait-il une astuce, avec une notation de type Regex \n pour indiquer au système de sauter une ligne ?

J'en profite pour indiquer que le confort d'édition du modèle est très loin d'être optimum.
Pour ce qui est du remplacement automatique des guillemets par exemple, j'ai lu dans un autre post du forum que vous indiquiez de désactiver ce remplacement au niveau du système et cela vas à l'encontre des bonne pratiques. C'est plutôt au niveau de ce champ de texte que vous devriez indiquez que ce remplacement ne doit pas s'opérer. Beaucoup de logiciels proposent d'ailleurs d'activer ou non les substitutions dans leur programme afin d'éviter d'avoir a activer ou désactiver au niveau système. De même ce champ de modification de modèle aurait tout intérêt à être un champ de texte brut alors qu'ici il se comporte comme un champ de texte RTF, ce qui n'est ni souhaitable, ni pratique.

Beaucoup de choses on été dites sur cette v5 en bon et en moins bon. Sans refaire le débat, pour ma part, je dirais que certaines nouveautés (notamment les factures) sont vraiment le bienvenu mais que très clairement c'est raté question UI et UX. Beaucoup d'actions évidentes et rapides auparavant (ce qui faisait tout l'attrait du programme) sont au final plus complexes et le nouvel habillage en plus d'être moche (c'est un avis et donc forcément subjectif) fait surtout perdre inutilement beaucoup de place. "L'encapsulage" des opérations pour créer ces bords arrondis sur un fonds donne ainsi une liste d'opérations beaucoup moins pratique qu'auparavant bien qu'une séparation permette effectivement plus de lisibilité sur une liste. Résultat de tout ceci, les opérations sont moins identifiables qu'auparavant, plus de clics sont nécessaires pour travailler l'une d'elles et l'ensemble est vraiment très indigeste sur un 13' avec des champs noms et commentaire constamment coupés qui oblige de rentrer en mode édition pour bien les voir.

J'espère que nous verrons par la suite un retour a plus de simplicité ou d'efficacité et que vous pourrais tout de même répondre à mes questionnements sur les modèles de Facture malgré ces critiques que je n'ai pas put m'empêcher d'écrire.

Cordialement,

dinobib

Re: Template Facture

Publié : 23 décembre 2013, 22:22
par Angeman
dinobib a écrit :Je voudrais modifier le résultat {{ date | date_format: MM/dd/yyyy }}
afin que le format donne un résultat en toutes lettres : vendredi 23 mars 2013 par exemple.
Quel format devrais-je utiliser pour cela si c'est bien implémenté ?
Mettez EEEE dd MMMM yyyy.
La syntaxe du format est défini ici : http://www.unicode.org/reports/tr35/tr3 ... t_Patterns
dinobib a écrit :Autre point qui me gêne, c'est le fonctionnement du champ {{ address }}.
Dans un premier temps, l'import dans icompta d'un client du carnet d'adresse ne fonctionne pas (la fenêtre de choix qui s'affiche est entièrement vide) et après avoir créé les clients, le champ adresse ne comporte qu'une ligne. Je n'arrive pas ainsi à faire ressortir la rue et le code postal et la ville sur des lignes séparés. Il y aurait-il une astuce, avec une notation de type Regex \n pour indiquer au système de sauter une ligne ?
Il faut mettre des retours à la ligne dans l'adresse en appuyant sur ctrl + retour.
Pour le carnet d'adresse pouvez-vous me faire une capture d'écran ?
dinobib a écrit :J'en profite pour indiquer que le confort d'édition du modèle est très loin d'être optimum.
Pour ce qui est du remplacement automatique des guillemets par exemple, j'ai lu dans un autre post du forum que vous indiquiez de désactiver ce remplacement au niveau du système et cela vas à l'encontre des bonne pratiques. C'est plutôt au niveau de ce champ de texte que vous devriez indiquez que ce remplacement ne doit pas s'opérer. Beaucoup de logiciels proposent d'ailleurs d'activer ou non les substitutions dans leur programme afin d'éviter d'avoir a activer ou désactiver au niveau système. De même ce champ de modification de modèle aurait tout intérêt à être un champ de texte brut alors qu'ici il se comporte comme un champ de texte RTF, ce qui n'est ni souhaitable, ni pratique.
C'est sûr l'éditeur actuel n'a pas vocation à remplacer un éditeur de texte avec la coloration syntaxique par exemple pour qui veut éditer son modèle confortablement. J'ai fait au plus simple parce que ça aurait pris trop de temps.