Sortie de Tryton 4.4

Conformément à son habitude le projet Tryton a sorti le 1^er mai, soit six mois après la version précédente, la version 4.4 de Tryton.

Rappelons que Tryton est un progiciel de gestion intégré (PGI ou ERP en anglais) écrit en Python en suivant une architecture trois tiers. L’abstraction de la couche d’accès aux bases de données lui permet de fonctionner sur PostgreSQL, SQLite voire MySQL. De multiples modules métiers permettent d’ajouter des fonctionnalités de gestion de la comptabilité, du stock, de la production, etc.

Cette version a principalement réusiné le code afin d’utiliser plus fréquemment les patrons répandus dans le projet. Un effort a aussi porté sur l’amélioration de la sécurité de Tryton.

L’autre changement majeur est le retrait de tous les modules utilisant WebDAV ; ceux‐ci étaient basés sur une bibliothèque qui n’est plus maintenue et qui empêchait d’être entièrement compatible avec Python 3. Et comme l’ensemble des modules n’interagissait que très peu avec le reste, il a été jugé plus pertinent d’utiliser d’autres solutions existantes comme CalendarServer, DAViCAL ou bien Radicale. De futurs développements devraient réintroduire des exportations au format iCalendar.

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

Sommaire

• Modifications dans le client GTK
• Modifications dans le serveur
  • Comptabilité
  • Ventes
  • Stock
• Les changements pour les développeurs
• Futur

Modifications dans le client GTK

Auparavant le modèle de sécurité était basé sur le principe TOFU (à la façon dont SSH vous demande d’autoriser une connexion à un hôte inconnu la première fois que l’on s’y connecte). Mais vu la généralisation de l’utilisation de certificats Let’s Encrypt, cette méthode est devenue moins pratique puisque ces derniers sont souvent renouvelés. À présent, le client utilisera les certificats du système.

Modifications dans le serveur

Comptabilité

Les périodes et les années fiscales peuvent maintenant être verrouillées de façon définitive. Cette fonctionnalité est essentielle pour la comptabilité française afin de respecter les contraintes imposées par la loi de finances.

Le système de numérotation des factures a été revu afin d’être plus simple de base, mais aussi plus extensible, permettant ainsi de suivre les règles que s’imposent les entreprises (ou que l’administration impose ☺).

Un nouvel assistant permet de facilement corriger un prix sur une facture tout en gardant la conformité de la comptabilité de stock et des statistiques.

La comptabilité analytique se dote d’un système de règles permettant d’assigner à des mouvements n’ayant pas encore de compte analytique celui correspondant aux règles définies.

Au rayon des nouveaux modules comptables, signalons le module account_payment_stripe qui, comme son nom l’indique, ajoute Stripe (un service de paiement en ligne) aux moyens de paiement.

Ventes

Deux nouveaux modules ont été publiés :

• sale_subscription est un module qui permet de vendre un système d’abonnement et de générer périodiquement des factures basées sur des consommations créées grâce à un ensemble de règles de récurrence ;
• sale_advance_payment, quant à lui, ajoute la fonctionnalité d’acompte sur vente. Cet acompte peut bloquer le processus d’approvisionnement de la vente ou le processus d’envoi des marchandises. Le paiement de l’acompte génère la facture finale et débloque les éventuels processus précédemment arrêtés.

Stock

Les différents documents de transfert de marchandises enregistrent maintenant des métadonnées lors de leur changement d’état, telles que l’employé qui a reçu la marchandise, etc. De nouveaux workflows de gestion des entrepôts tels que le Wave Picking sont pris en charge.

Les règles d’approvisionnement permettent de définir des emplacements de surplus. Ainsi, ces règles créent automatiquement les expéditions internes afin de déplacer les biens, après une production par exemple.

Les changements pour les développeurs

Le changement le plus important est sans aucun doute le remplacement des champs Property par une nouvelle API. Tryton étant utilisable dans un contexte multi‐société ; ces champs étaient utilisés afin de définir des valeurs qui variaient en fonction de la société courante de l’utilisateur. Le nouveau mécanisme implémentant la fonctionnalité repose sur un mécanisme plus robuste.

Un découplage plus grand entre les champs et l’infrastructure implémentant la connexion aux bases de données permet maintenant d’ajouter des champs et des back‐ends à Tryton en créant un module Python. L’écriture d’un module définissant des champs pouvant stocker des informations géographiques stockées dans PostGIS est en cours.

L’attribut col utilisé dans les définitions de vues devait auparavant contenir le nombre de colonnes utilisées ; maintenant le développeur peut utiliser un nombre négatif, ce qui est très utile quand on ne sait pas combien de champs seront ajoutés dans un groupe.

Il est maintenant possible de définir une partie du domaine (recherche par défaut) qui s’applique sur une vue comme étant dépendante du contexte de celle‐ci. Ceci permet de rendre les vues plus dynamiques. Par exemple, n’afficher que des enregistrements actifs pour une date encodée dans le contexte.

Les champs relations du type xxx2Many ont maintenant un attribut filter. Il est utilisé pour limiter les enregistrements contenus par ce champ à la lecture. C’est comme l’attribut domain mais sans être une contrainte. Il permet de remplacer des champs calculés et d’être ainsi plus performant.

De nouvelles protections contre les attaques par force brute ont été ajoutées afin de renforcer la sécurité du serveur.

Futur

Certains chantiers sont déjà en cours pour les futures versions.

Des infobulles sont ajoutées de manière systématique sur la majorité des champs afin de rendre l’application plus facile à découvrir. Les règles utilisées pour l’écriture sont reprises sur cette page.

Le client Web devrait recevoir des raccourcis clavier

Une application Web single page (Ceryx) conçue pour faire des opérations gestion d’entrepôt in situ. Les opérations de « Pack » et « Ship » sont déjà développées.

Le nouveau module Stripe va déjà recevoir une amélioration qui permettra de prendre en charge le flux de paiement en deux étapes.

Le modèle d’OpenDocument sera converti en « flat document », ce qui sera l’occasion d’utiliser un mécanisme d’extension similaire aux vues.

Il devrait être possible d’étendre un ensemble de classes sur la base de critères et non plus uniquement sur le nom explicite.

De nouveaux modules sont en cours de réalisation :

• notification par courriel déclenchée par des évènements sur les enregistrements ;
• dépôt‐vente ;
• tolérance sur les livraisons ;
• numéro de série sur les lots ;
• pré‐paiement sur les ventes, ce qui est utile pour implémenter un site de commerce en ligne ;
• gestion des devis pour les demandes d’achat avec sélection du meilleur fournisseur.

Aller plus loin

• L’annonce de la sortie (201 clics)
• Tryton (461 clics)
• Des exemples d’utilisation de Tryton (415 clics)
• Démo de Tryton (nom d’utilisateur : demo_fr, mot de passe : demo) (690 clics)