Sortie de Tryton 4.8

Après six mois de développement, la version 4.8 de Tryton vient de sortir.

Tryton est un progiciel de gestion intégré (aka PGI ou ERP) écrit majoritairement en Python (et un peu de JavaScript). Il suit une 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 couvre un large éventail des besoins de l’entreprise (achats, ventes, comptabilité, stock, etc.).

Sommaire

• Changements pour les utilisateurs
  • Client Natif
  • Client Web
    • Comptabilité
    • Stock
    • Projet
    • Ventes
    • Achats
    • Notification
• Changements pour les développeurs
• Futur

Voici donc la dernière version de Tryton qui prendra en charge Python 2, les prochaines ne seront compatibles qu’avec Python 3. Il est donc grand temps de s’assurer que vos modules sont prêts en utilisant dès à présent Tryton sous Python 3.
Cette version réduit encore plus l’écart de fonctionnalités entre le client natif et le client Web. Ce dernier a reçu une attention particulière afin de corriger plein de petits détails.
Nous introduisons également une nouvelle manière de concevoir des rapports dynamiques. Pour l’instant, seul le module sale en bénéficie mais les prochaines versions devraient voir la généralisation de cette méthode.
Le persan fait son apparition comme langue officielle.

Comme d’habitude, la migration depuis les versions précédentes de Tryton est prise en charge.

Changements pour les utilisateurs

Nous avons ajouté un bouton à côté de l’entrée de recherche qui permet de filtrer sur les enregistrements « désactivés » (Tryton possède une suppression logique sur certains enregistrements). Le bouton n’est visible que si la suppression logique existe sur le type de document recherché.

Jusqu’à maintenant quand l’édition d’un « pop‐up » était annulée, le client rechargeait les données depuis le serveur afin d’avoir une sorte d’annulation, mais ce comportement n’était pas parfait du point de vue de l’utilisateur s’il avait déjà fait des modifications non sauvegardées. Maintenant, le client restaure les données comme elles étaient avant l’ouverture du « pop‐up ».

Pour des raisons de performance, si l’utilisateur essaie d’étendre un enregistrement qui se trouve dans une vue arborescente qui contient trop d’enregistrements (la limite par défaut est de 1 000), le client passe en vue formulaire. Cette vue doit normalement afficher également les enfants de premier niveau mais en utilisant un chargement progressif, ce qui consomme bien moins de ressources.

Pour aider les sociétés a respecter le droit à l’oubli que le RGPD impose, nous avons ajouté un nouvel assistant. Il efface les données personnelles liées à un tiers, telles que le noms, les adresses, les mécanismes de contacts, etc. Il supprime également les données des tables d’historique. Mais, évidemment, chaque module ajoute des vérifications afin de déterminer si le tiers peut être effacé. Par exemple, il ne pourra pas l’être s’il a toujours des factures à payer.

Les mécanismes de contacts ont maintenant la possibilité, comme les adresses, d’être marqués pour certaines utilisations. Par exemple, le module de facturation ajoute une option qui permet de définir l’adresse de courriel à utiliser pour l’envoi de factures.

La liste des modules, ayant été revue pour l’ajout d’info‐bulles, s’allonge : account_credit_limit, account_dunning, carrier, carrier_weight, currency et product_attribute.

Client Natif

Comme souvent, les utilisateurs installent le client manuellement sans passer par un gestionnaire de paquets (setup sous Windows ou bundle sous macOS). Ils ont tendance à ne pas mettre à jour celui‐ci quand des corrections de bogues sont publiées. Cette nouvelle version inclut une option (activée par défaut) qui vérifie périodiquement si l’on utilise bien la dernière version. Et si ce n’est pas le cas, un lien pour télécharger celle‐ci est affiché.

Le client avait déjà des raccourcis clavier, maintenant ce sont tous les champs qui sont automatiquement accessibles grâce à la combinaison Alt + _.

Les champs relations de type Many2One sur les listes éditables reçoivent les icônes d’édition et d’effacement. Cela unifie le comportement avec les vues formulaire (et le client Web).

Client Web

Les valeurs numériques sont maintenant formatées en utilisant la langue de l’utilisateur, mais un élément input de type number est utilisé pour l’édition (qui peut sous certains navigateurs ne pas formater correctement). Le but est d’avoir un clavier virtuel numérique sur les mobiles.

La position de l’enregistrement courant est enfin affichée.

Les champs avec correction d’orthographe ont maintenant la correction du navigateur activée.

Les boutons des « widgets » n’entrent plus dans la navigation au clavier. Leurs actions sont toutes disponibles par raccourcis clavier.

Le mode d’édition des listes a été complètement retravaillé. Maintenant, toute la ligne sélectionnée devient éditable. Le focus reste toujours sur celle‐ci tant qu’elle n’est pas valide. L’édition se termine également dès que l’utilisateur clique en dehors de la vue.

La fonctionnalité de somme de liste est également implémentée :

Les mêmes raccourcis clavier que pour le client natif sont disponibles sur les widgets « date » et « date et heure ».

Les champs relation Many2One sont affichés sur les vues liste ou arbre par un lien cliquable qui ouvre la cible dans un nouvel onglet.

L’affichage a reçu plein de petites améliorations qui corrigent de légers sauts dans le rendu.

Comptabilité

Les lignes du compte de résultat s’ouvrent sur les comptes du Grand Livre correspondant. Ceci permet de voir le détail du calcul.

Il arrive que les utilisateurs veuillent modifier les paramètres de certains comptes venant d’un modèle. Jusqu’à présent, ces modifications étaient perdues lors des mises à jour du plan. Maintenant, les comptes venant d’un modèle sont en lecture seule par défaut. Il faut cocher une case pour pouvoir les éditer et ainsi les sortir du processus de mise à jour.

Si un utilisateur essaie de créer un second plan comptable pour une seule société, un avertissement est levé car il y a de fortes chances que ce soit une erreur.

Il n’est plus possible de clôturer une période comptable s’il y a encore des lignes de dépréciation d’actifs à poster pour cette période.

Le système de rapport de taxe a été complètement revu. En effet, il était limité à un seul code par taxe, ce qui était très restrictif pour certaines taxes (ex : auto‐liquidation). Des astuces devaient être trouvées en créant des taxes supplémentaires qui s’annulaient. Maintenant, les codes ne sont plus définis sur les taxes mais les codes contiennent la liste des taxes qu’ils doivent prendre en compte.

Un nouveau module account_tax_cash permet de rapporter les taxes en se basant sur les paiements. Les groupes de taxes qui doivent être rapportées de cette manière sont définis sur l’année fiscale ou sur la période, mais elles peuvent également être définies par facture et fournisseur.

Il n’est plus possible de modifier les lignes de taxes pour les périodes clôturées.
Il n’est plus possible d’enregistrer sur une facture des paiements supérieurs à celle‐ci.

La description de ligne de facture est maintenant optionnelle. Le nom du produit est toujours affiché sur l’édition de la facture.

La case à cocher qui indiquait qu’une facture est payée (réconciliée) a été remplacée par une date qui fournit plus d’information.

Les mouvements de compensation des paiements sont maintenant postés automatiquement après un délai à configurer sur le journal.

Les paiements Stripe qui sont contestés ont leurs statuts mis à jour. Et quand la dispute est finalisée, le paiement est aussi mis à jour en fonction de la résolution.

Le module de paiement Stripe gère maintenant tous les événements. En particulier, l’événement de remboursement qui peut mettre à jour le montant du paiement.

Il est maintenant possible de lancer la réconciliation des lignes d’un extrait de compte juste après l’avoir validé.

Le format OFX est maintenant pris en charge pour l’importation d’extraits de compte.

Stock

Il est à présent possible d’avoir la quantité de stock par modèle de produits car les variantes d’un même modèle partagent la même unité de mesure.

Quand il y a un grand nombre d’emplacements, l’arbre des quantités de ceux‐ci est difficile à utiliser, particulièrement si l’on cherche l’emplacement qui contient un produit. En conséquence, nous avons ajouté l’option d’ouverture de la vue en mode liste afin de pouvoir effectuer des recherches.

Nous avons remarqué qu’il y avait deux camps sur le comportement attendu des inventaires si aucune quantité n’était rentrée pour un produit. Les premiers s’attendent à ce que la quantité du produit soit zéro et les seconds à ce que la quantité du produit ne change pas. Ceci nous a mené à ajouter une option sur l’inventaire qui permet de choisir le comportement.

L’assignation des retours fournisseur ne cherchait pas le produit dans les sous‐emplacements. Mais ceci ne marchait pas si l’emplacement en question est une vue (qui ne peut pas avoir de produit). Dans ce cas, l’assignation recherche dans les sous‐emplacements.

Les livraisons fournisseur peuvent être reçues directement dans l’emplacement de stockage et ainsi ignorer l’étape de mise en inventaire.

Projet

La facturation des projets se limitait à créer une facture pour les sous‐projets liés au même tiers. Maintenant, une facture différente est créée par tiers pour tous les sous‐projets.

Ventes

Comme pour la facture, la description des lignes de vente est désormais optionnelle. Cela permet d’éviter de recopier par défaut le nom du produit dans la description, car celui‐ci est affiché lors de l’édition de la vente.

Quand la vente crée la facture en fonction des livraisons, si le produit livré est différent du produit vendu (remplacement), c’est maintenant le produit livré qui apparaîtra sur la facture.

Il est maintenant possible de modifier l’en‐tête d’une vente quand des lignes sont déjà entrées, grâce à un nouvel assistant. Ce n’était pas possible auparavant car les valeurs calculées des lignes dépendent de l’en‐tête, ex : l’adresse de livraison pour les taxes, la devise pour le prix unitaire, etc.
Le nouvel assistant se charge de recalculer les lignes en accord avec le nouvel en‐tête.

De nouveaux rapports agrégeant les données de ventes ont été ajoutés. Le moteur de rapport permet de consulter le revenu et nombre de ventes par :

• client ;
• produit ;
• catégorie ;
• pays > subdivision.

Les données sont agrégées sur une période, une société et un entrepôt. Les rapports montrent aussi une sparkline sur la tendance du revenu, qui peut être consultée pour plus de détails.

Les ventes avec la méthode de livraison « au paiement », qui doivent créer des demandes d’achats ou des livraisons directes, ne les créent à présent que quand la ligne de vente est complètement payée.

Tryton ne calcule plus automatiquement de frais de livraison pour les retours de produits.

Un nouveau module sale_promotion_coupon permet de gérer des coupons qui donnent accès à des promotions. Les coupons peuvent être configurés pour n’être utilisables qu’un certain nombre de fois (typiquement une seule fois) globalement ou par client.

Achats

Le produit du fournisseur peut maintenant être utilisé sur les lignes d’achat. Ceci permet d’afficher les références précises du fournisseur.

Un avertissement est levé si un utilisateur valide un achat pour une livraison dans un entrepôt différent de celui des demandes d’achat.

Comme pour la vente :

• il est maintenant possible d’éditer l’en‐tête quand des lignes sont déjà entrées ;
• la description des lignes est également optionnelle ;
• le produit reçu est facturé.

Un nouveau module purchase_request_quotation fait son apparition. Il permet de gérer des demandes de devis à plusieurs fournisseurs avant de passer la commande au fournisseur choisi.

Notification

Les notifications pour lesquelles aucun courriel n’a été trouvé, peuvent être envoyées à une adresse par défaut. Le cas d’utilisation classique est l’envoi automatique de facture avec une adresse par défaut qui est liée à une imprimante pour l’envoi par la poste.

Changements pour les développeurs

Le client natif ne prend plus en charge que GTK+ 3 afin de préparer la transition à Python 3.

Pour les bases de données qui gèrent la fonctionnalité unaccent (fonction pour PostgreSQL), les recherches ilike sont effectuées sans accent pour tous les champs Char. Il est possible de désactiver l’option en positionnant l’attribut Char.search_unaccent à faux.

Nous avons ajouté la prise en charge des contraintes EXCLUDE. C’est une sorte d’extension aux contraintes UNIQUE qui peuvent s’appliquer sur un sous‐ensemble de lignes et en utilisant une expression (au lieu de seulement des colonnes). Pour plus d’information, voir la documentation d’EXCLUDE de PostgreSQL.

Il est dorénavant possible d’enregistrer une classe dans le Pool seulement si d’autres modules sont activés. Ceci remplace le comportement précédent qui était d’ignorer silencieusement quand l’enregistrement n’était pas possible.

Il est à présent possible de définir dans un fichier XML une valeur pour un champ qui n’existe que quand certains modules sont actifs.

L’administrateur peut maintenant réinitialiser le mot de passe d’un utilisateur par un simple clic. Le serveur génère un mot de passe temporaire qui est valable par défaut pour un jour et l’envoie par courriel à l’utilisateur. Le mot de passe temporaire est désactivé dès que l’utilisateur enregistre un nouveau mot de passe.
Il est également possible d’utiliser cette fonctionnalité pour l’utilisateur admin via la commande trytond-admin.

En plus des protections existantes contre les attaques par force brute, le serveur limite également le nombre de tentatives par réseau IP. La taille des réseaux est configurable.

Il est possible d’étendre toutes les classes du Pool qui sont une sous‐classe d’une classe avec un Mixin. Un exemple est d’étendre la méthode Report.convert pour tous les rapports afin d’ajouter le prise en charge d’un autre moteur de rendu.

Le code de prise en charge de MySQL a été sorti de la base. Il n’était pas testé par le serveur d’intégration et il n’y avait pas d’intérêt dans la communauté pour le maintenir. Le code est maintenant dans un dépôt, mais il ne fera pas partie des publications tant qu’aucun mainteneur ne sera trouvé.

LibreOffice est utilisé directement par le moteur d’édition pour la conversion de format au lieu d’unoconv. Il y avait des problèmes de stabilité avec ce dernier.
À noter que nous publions une variante des images Docker avec le suffixe -office qui a LibreOffice installé.

Futur

La communauté a réussi le financement de deux développements majeurs :

• une queue de tâche transactionnelle qui permettra d’avoir plus de réactivité lors d’un traitement consommateur ;
• une notification asynchrone dans les clients natif et Web.

La fondation a lancé le projet de refonte du site Web qui devrait être prêt pour la publication de la prochaine version.

Le processus de publication va changer avec la version 5.0. Il sera basé sur une version majeure qui sera supportée pendant cinq ans (au lieu de 2½) suivie par quatre versions mineures tous les six mois supportées chacune un an.

Aller plus loin

• Annonce complète (358 clics)
• Démo (utilisateur : demo_fr, mot de passe : demo) (705 clics)
• LinuxFr.org : Sortie de Tryton 4.6 (135 clics)