URL: https://linuxfr.org/news/sortie-de-tryton-4-6 Title: Sortie de Tryton 4.6 Authors: Cédric Krier Davy Defaud, Oliver, sisalp, Nicolas Évrard et palm123 Date: 2017年10月31日T10:42:17+01:00 License: CC By-SA Tags: tryton, python, erp et postgresql Score: 24 Déjà six mois depuis la dernière version de Tryton et donc voici la nouvelle mouture pour passer l’hiver. Pour rappel, Tryton est un [progiciel de gestion intégré](https://fr.wikipedia.org/wiki/Progiciel_de_gestion_intégré) (_aka_ PGI ou ERP) écrit majoritairement en Python (et un peu de JavaScript). Il suit une architecture [[architecture trois tiers]] et tourne par défaut sur PostgreSQL et SQLite. Il possède trois clients : _desktop_, _web_ et _script_, et vient avec une suite de plus de cent modules qui couvrent un large éventail des besoins de l’entreprise (achats, ventes, comptabilité, stock, etc.). ![Logo de Tryton](http://downloads.tryton.org/images/banner.svg) Cette nouvelle version reçoit pas moins de neuf nouveaux modules, les plans comptables espagnoles et des améliorations de l’interface utilisateur en corrigeant plein de petits détails. Comme d’habitude, la [migration](https://discuss.tryton.org/t/migration-from-4-4-to-4-6/383) depuis les versions précédentes de Tryton est prise en charge. Le [conférence annuelle de Tryton](https://tul2017.tryton.org/) aura lieu du 7 au 10 décembre à [[Liège]], et on y fêtera les dix ans du projet. 😉 ---- [Version en anglais de cette annonce (complète)](http://www.tryton.org/posts/new-tryton-release-46.html) [Présentation de Trython en français sur le site Web officiel](http://www.tryton.org/fr/) [Demo (utilisateur : demo_fr, mot de passe : demo)](http://demo4.6.tryton.org/) [Conférence annuelle Tryton (décembre 2017) ](https://tul2017.tryton.org/) ---- Le projet ====== Gouvernance --- Le projet est mené par un ensemble de sociétés et de particuliers qui s’appuient sur la méritocratie. Les évolutions sont systématiquement proposées à la discussion et à la revue de la communauté pour rechercher un consensus. L’infrastructure et la marque sont gérées par une [Fondation privée](http://foundation.tryton.org) de droit belge, ce qui garantit une indépendance et impartialité sur la gestion du commun. Audience --- * les [PME](https://fr.wikipedia.org/wiki/Petite_et_moyenne_entreprise) qui veulent un outil de gestion qui intègre l’ensemble de leurs opérations ; * les PME qui veulent une application qu’elles pourront adapter et faire évoluer en fonction de leurs besoins ; * les [[SS2I]] qui cherchent un outil pour développer des applications métier rapidement et en se basant sur une base commune générique. Architecture --- L’[[architecture trois tiers]] est utilisée. Pour base de données, PostgreSQL, SQLite (et MySQL) sont prises en charge. Des prototypes ont déjà été développés pour gérer d’autres bases de données comme Oracle. Le serveur applicatif est écrit en Python, utilise JSON-RPC (ou XML-RPC) comme protocole de communication et XML pour décrire les vues. La logique métier est définie dans les modules du serveur. Un module peut aussi modifier le comportement d’un autre module grâce à une technique de surcharge. Le client _desktop_ est programmé aussi en Python et utilise GTK+. Le client Web est écrit en JavaScript et utilise JQuery et Bootstrap. La librairie cliente est simplement programmée en Python. Changements pour les utilisateurs =========== Une des améliorations de l’interface concerne l’affichage du profil de connexion dans la barre de titre. C’est pratique quand on a plusieurs clients ouverts. L’ordonnancement de la barre d’outil a été revu afin de regrouper les actions similaires : ![Bandeau de la barre d’outils](http://www.tryton.org/images/tryton_toolbar_order.png) L’alignement des titres de colonnes suit l’alignement du contenu et les listes éditables ont un style de grille afin de les distinguer des listes non éditables : ![Fenêtre de liste non éditable](http://www.tryton.org/images/sao_list_non_editable.png) ![Fenêtre de liste éditable](http://www.tryton.org/images/sao_list_editable.png) Les champs *binaires* ont reçu le même traitement que les champs *relation* lors de la version précédente : seuls les boutons disponibles sont visibles et le bouton de sélection n’est disponible qu’une fois que le contenu précédent a été effacé. Le client Web a maintenant les mêmes raccourcis clavier que le client bureau. La liste des raccourcis est affichée avec `Ctrl`+`H`. Le client _desktop_, sous GTK+ 3, peut bénéficier d’un [thème fourni par un fichier](http://doc.tryton.org/4.6/tryton/doc/usage.html#css) au format [[CSS]]. Comptabilité ----------- La création d’une [année fiscale](http://doc.tryton.org/4.6/modules/account/doc/index.html#fiscal-year) est une opération qui peut être complexe et qui doit être faite chaque année. Afin de la simplifier, un nouvel assistant a été ajouté pour la renouveler. Il prend l’année précédente et en fait une copie en ajoutant un an aux dates. ![Assistant de renouvellement d’une année fiscale](http://www.tryton.org/images/sao_renew_fiscalyear.png) Une option permet de faire redémarrer ou pas les numérotations des documents. Une mention légale peut être configurée sur les taxes. Quand celle‐ci est utilisée sur une facture, la mention légale est ajoutée automatiquement. Dans certains pays comme l’Espagne, il existe des taxes ([équivalence surcharge](https://www.agenciatributaria.gob.es/AEAT.sede/en_gb/procedimientos/G403.shtml)) qui s’ajoutent en fonction du tiers et de la taxe déjà appliquée. Le [système de règles](http://doc.tryton.org/4.6/modules/account/doc/index.html#tax-rule) ne permettait pas de les configurer facilement, il fallait créer une nouvelle taxe pour toutes les combinaisons possibles. Une nouvelle option a été ajoutée afin que la règle ne remplace plus la taxe par une autre mais l’ajoute simplement. Les comptes client et fournisseur ne sont plus obligatoires lors de la création d’un tiers. Un message d’erreur est levé si une opération les requiert. Ce changement fait partie d’une tendance générale du développement de Tryton qui est de limiter au maximum les contraintes. Le [[grand livre]] et le [[compte de résultat]] sont aussi disponibles sur une plage de dates en plus des périodes comptables. Il est aussi possible maintenant de faire des recherches sur les montants du grand livre pour, par exemple, n’avoir que les comptes avec une balance non nulle. Pour les Belges, Tryton génère le relevé à la TVA des opérations intracommunautaires et la liste annuelle des clients assujettis à la TVA. L’importation des extraits de comptes au format [CODA](https://www.febelfin.be/sites/default/files/files/standard-coda-2.5-en.pdf) est pris en charge (d’autres formats vont suivre dans les prochaines versions). Le paiement avec [Stripe](https://stripe.com) a reçu beaucoup d’attention : * il est possible de créer des paiements manuellement ; * la source du client peut être sélectionnée, avant c’était Stripe qui en choisissait une par défaut ; * le [paiement en deux étapes](https://stripe.com/blog/auth-capture) a été intégré, il permet de réserver le montant sur la carte de crédit dans un premier temps et de le capturer par la suite. L’annulation d’un relevé dé-réconcilie automatiquement les mouvements liés. Ça simplifie grandement la tâche pour l’utilisateur. Les relances peuvent maintenant envoyer un courriel automatiquement au tiers concerné. Le format du courriel peut‐être personnalisé par niveau de relance. Un historique de cet envoi est gardé dans la base de données. Stock ----- On peut maintenant limiter un emplacement de stockage pour n’avoir qu’un seul niveau de sous‐emplacement. Ceci permet à l’algorithme de calcul des quantités de stock d’être optimisé et ainsi permettre de s’exécuter sur un très grand nombre d’emplacements tout en restant performant. C’est une condition nécessaire si l’on veut utiliser la stratégie de stockage chaotique. En plus de pouvoir diviser les mouvements de stock, il est maintenant possible de diviser aussi les expéditions. Certains expéditeurs limitent la taille ou le poids de celles‐ci. L’erreur qui est levée quand on exécute un mouvement sans origine ne l’est plus qu’une seule fois pour l’ensemble de mouvements au lieu d’un par mouvement. La comptabilité de stock perpétuelle gère aussi les retours directs de livraison. Afin de pouvoir entrer des mouvements passés (ex : reprise d’historique), la date effective d’un mouvement peut être modifiée par l’utilisateur (par défaut, c’est la date du jour). Il est maintenant interdit de désactiver un emplacement qui contient toujours une quantité de produit. Tryton gère la [consignation](https://fr.wikipedia.org/wiki/Consignation) (ou [[dépôt‐vente](https://fr.wikipedia.org/wiki/D%C3%A9p%C3%B4t-vente)) de fournisseurs dans l’entrepôt de la société, mais aussi de la société dans l’entrepôt de ces clients. Quand des produits sont utilisés, la facture correspondante est automatiquement créée. Afin de gérer certains emplacements de stockage comme les [palettes](https://fr.wikipedia.org/wiki/Palette_de_manutention), les livraisons internes peuvent déplacer les emplacements marqués comme mobiles. Achat ----- Les ruptures de stock des fournisseurs ne sont plus planifiées. Avant elles l’étaient pour la même date que l’ordre initial, mais c’est une supposition trop optimiste : si le fournisseur a déjà manqué un réapprovisionnement, on ne peut pas supposer qu’il sera dans les temps pour la prochaine fois. Les ordres d’achats confirmés sont automatiquement traités grâce à une tâche planifiée. Vente ----- Les ruptures de stock des livraisons sont planifiées pour le jour même. Avant elles étaient planifiées pour la même date que l’ordre initial, mais cette date est très probablement dans le passé et donc le calcul de réapprovisionnement risque de les manquer. Le parti pris est d’essayer de tenter de l’exécuter au plus tôt. Les ventes confirmées sont automatiquement traitées grâce à une tâche planifiée. Auparavant, en cas de mélange de services et de biens, le coût de la livraison pouvait être facturé en même temps que les services. Maintenant, le coût de livraison est facturé seulement si une livraison a été effectuée. La vérification des quantités de stock des produits vendus ignore les produits qui sont considérés comme consommables. Il est maintenant possible d’enregistrer des paiements sur la vente avant la création de la facture. Dans ce cas, la vente est automatiquement validée quand on reçoit l’autorisation des paiements pour le montant total de la vente. Cette fonctionnalité est principalement utilisée pour gérer le flux de paiement de site d’e‐commerce. Des tolérances de sur‐expédition ou de sous‐expédition pour les ventes peuvent être configurées. Si la quantité expédiée d’une ligne de vente est dans la tranche de tolérance, celle‐ci sera considérée comme complètement expédiée et aucun autre ordre de livraison ne sera créé. En revanche, si la quantité expédiée dépasse la tolérance, un avertissement (_warning_) est levé. Notification ------------ Cette nouvelle fonctionnalité permet d’envoyer des courriels aux tiers (ou utilisateurs) liés à un enregistrement en fonction du [déclenchement de conditions](http://doc.tryton.org/4.6/trytond/doc/topics/triggers.html) prédéfinies. Le courriel peut inclure n’importe quel rapport de l’enregistrement en question. Cette fonctionnalité permet, par exemple, d’envoyer automatiquement les factures aux clients dès qu’elles sont enregistrées en comptabilité. Changements pour les développeurs =========== Le serveur gère les colonnes de type [`JSON`](https://www.postgresql.org/docs/current/static/datatype-json.html) au lieu de `TEXT` pour les champs dictionnaire. Cela permet de tirer profit des fonctions spécifiques de la base de données pour ces champs. Le _back‐end_ [[SQLite]] prend en charge les fonctions `alter_type()` et `alter_size()`. L’implémentation recrée la table avec les nouveaux types et réinsère l’ancien _n_‐uplet (_tuple_). Grâce à la prise en charge de la dernière version de [Relatorio](https://relatorio.tryton.org/), Tryton gère les [Flat OpenDocuments](https://en.wikipedia.org/wiki/OpenDocument_technical_specification#File_types) comme modèle de documents pour une meilleure intégration dans les gestionnaires de code source, car les fichiers sont des fichiers plats [[XML]] au lieu de [ZIP](https://fr.wikipedia.org/wiki/ZIP_(format_de_fichier)). Les modèles de documents peuvent être configurés pour s’appliquer sur un seul enregistrement. Dans le cas d’une requête sur plusieurs enregistrements concernant un rapport, le serveur génère un fichier ZIP contenant un fichier par enregistrement. Cette fonctionnalité est utilisée pour les factures qui doivent être archivées de manière unique. Une nouvelle méthode `get_email()` a été ajoutée au module `report`. Elle retourne une instance de courriel basée sur le modèle de rapport. Le courriel peut être en plusieurs langues et, si le modèle est en HTML, une version en texte brut est ajoutée automatiquement. La sécurité des sessions est augmentée en passant à 32 octets aléatoires (256 bits). Une protection contre le déni de taille de requête a été ajoutée, et celle‐ci est activée par défaut. Les requêtes non authentifiées sont limitées à 2 Mio et celles authentifiées à 2 Gio. Les tailles sont, bien entendu, configurables. Afin de simplifier l’utilisation comme application [WSGI](https://fr.wikipedia.org/wiki/Web_Server_Gateway_Interface "Web Server Gateway Interface"), les variables d’environnement `TRYTOND_LOGGING_CONFIG` et `TRYTOND_DATABASE_NAMES` ont été ajoutées. Tryton est prêt pour la nouvelle [version 10 de PostgreSQL](https://www.postgresql.org/about/news/1786/). Cette version a changé l’interface interne de gestion des séquences, ce qui a poussé à déplacer cette gestion dans le _back‐end_ et ainsi prendre en charge plusieurs versions de manière transparente. Certaines méthodes ne peuvent pas être appelées sur une liste d’enregistrements qui contient des doublons. Mais, souvent, les développeurs ne pensent pas à vérifier cette contrainte. Afin de se protéger de ce type de bogue, tous les appels [RPC](https://fr.wikipedia.org/wiki/Remote_procedure_call "Remote Procedure Call") sont vérifiés sur l’unicité des identifiants. Les méthodes de bouton et de transition de [_workflow_](https://fr.wikipedia.org/wiki/Workflow) contiennent une précondition *([`assert`](https://docs.python.org/3.6/reference/simple_stmts.html#the-assert-statement))* pour détecter les problèmes lors du développement sans avoir d’impact sur les performances en production. Les modules externes qui implémentent de nouveaux _back‐end_ peuvent enregistrer de nouveaux tests via un point d’entrée spécifique aux jeux de tests standards. La commande `trytond-admin` a une nouvelle option `--install-dependencies` qui permet d’installer automatiquement les dépendances manquantes quand on met à jour la base de données. Les modules qui n’existent plus sont aussi supprimés. L’utilisateur `root` peut se comporter comme n’importe quel employé de n’importe quelle société. Comme Python 3.3 a atteint sa fin de vie, sa prise en charge a été supprimée. En revanche, la prise en charge de Python 3.6 a été ajoutée.

AltStyle によって変換されたページ (->オリジナル) /