Sortie de tryton 3.6

Après 6 mois de développement, la version 3.6 de Tryton, la plate‐forme de développement d’applications pour entreprise (progiciel de gestion intégré ou PGI dit aussi ERP) sous licence GPLv3+, est sortie.

Cette version apporte, en plus des habituelles corrections de bogues, le support officiel de PyPy une implémentation alternative de Python concentrée sur la vitesse et l'efficacité.

La migration depuis les versions précédentes est supportée.

Sommaire

• Détails des nouveautés
  • Pour l'utilisateur
  • Pour le développeur
  • Modules
    • Produits
    • Ventes
    • Stock
    • Commission
    • Comptabilité
• La suite
  • Client web
  • Python3
  • GTK-3

Détails des nouveautés

Pour l'utilisateur

Un nouveau schéma de génération de couleur pour les graphes est introduit. Il remplace le précédent basé uniquement sur la luminosité en ajoutant un décalage supplémentaire de teinte d'un angle d'or afin de se prémunir de toute collision.

Le widget des champs dictionnaire (clés-valeur) voit maintenant l'auto-complétion activée sur la recherche de clés comme les autres widgets.

Les widgets des champs date, date-heure et heure ont été complétement réécrits, afin d'être plus flexibles sur le format d'entrée et de permettre une utilisation plus aisée avec une souris.

Les colonnes d'une vue liste qui sont garanties d'avoir toujours la même valeur (via un domaine) sont cachées automatiquement.

Pour le développeur

Il est maintenant possible d'afficher plusieurs fois le même champs comme colonne d'une vue liste.

Un nouveau type de champ TimeDelta fait son apparition. Il permet de représenter une durée. Il remplace le widget float_time hérité d'OpenERP (Odoo) qui comportait plusieurs problèmes dont entre autres un problème d’arrondi.

La syntaxe des méthodes on_change a été changée en faveur d'une version considérée plus consistante avec l'Active record (patron de conception). Au lieu de retourner un dictionnaire contenant les valeurs des champs à changer, l'instance est directement modifiée.

La méthode save est maintenant duale, c'est-à-dire qu'elle peut être appelée depuis une instance ou bien depuis la classe avec une liste d'instances comme paramètre. Ceci afin de tirer avantage de l'écriture et de la validation groupée de l'ORM de Tryton.

La clause de tri de la méthode de recherche permet maintenant d'utiliser une annotation avec des points. Celle-ci générera automatiquement les jointures nécessaires.

L'API des rapports a été retravaillée afin de simplifier l’intégration d'autres moteurs. Les méthodes de formatages sont maintenant plus strictes afin d'éviter les erreurs silencieuses.

La méthode safe_eval (dont on n'était pas sûr qu'elle soit si safe que ça) a été enlevée. Partout où du code Python devait être évalué de manière sûre, un autre format sûr a été utilisé comme du JSON.

Un nouveau type de bouton fait son entrée. C'est un bouton qui travaille sur une instance non-sauvée et qui la modifie de la même manière qu'un on_change côté client.

Modules

Produits

Les listes de prix peuvent être définies aussi avec taxes comprises. Le prix hors-taxe sera calculé lors de la vente en se basant sur les taxes applicables.

Le nombre de décimales pour les calculs de prix en interne est maintenant un paramètre de configuration ce qui permet d'assurer la cohérence dans toute l'application.

Ventes

Les opportunités de ventes ont été fortement retravaillées. Il est maintenant possible de les faire aboutir à plusieurs ventes et leurs montants sont mis à jour en fonction de la réalisation des ventes.

Le calcul du coût de livraison se fait maintenant seulement au passage en devis (au lieu d'être calculé en direct) afin de réduire la charge sur le serveur.

Un nouveau module sale_extra permet d'ajouter une ligne de vente en extra en fonction de critères spécifiques. Cet extra peut-être gratuit ou bien un coût de service supplémentaire.

Stock

La création des requêtes d'achats avertit s'il y a des productions en retard afin de ne pas acheter inutilement des produits manquants.

Un nouveau module stock_lot_sled ajoute le support des dates d'expirations sur les lots. Quand un lot est expiré, il n'est plus pris en compte dans le calcul prévisionnel des quantités en stock.

Un nouvel état a été ajouté aux mouvements de stock staging. Il permet de créer des mouvements à l'avance sans impacter le prévisionnel.

L'assignation (réservation) des mouvements a été améliorée afin de ne plus tenir compte des mouvements déjà assignés entrants mais toujours de ceux sortants. La version précédente était légèrement trop optimiste sur la réalisation future des mouvements et ça pouvait poser quelques problèmes de gestion.

Commission

Ce nouveau sujet commence à être couvert par un ensemble de nouveaux modules. Un agent de commission peut être défini sur la vente ou la facture, celui-ci sera rétribué en fonction d'un plan de commissionnement. Il est aussi possible de définir sur un produit, un principal de qui recevoir la commission.

Comptabilité

Le wizard d'annulation de mouvement prend maintenant une description.

Les taxes peuvent être configurées pour modifier le montant de base pour les taxes suivantes à appliquer.

Il est possible de définir des modèles de mouvement comptable basés sur quelques paramètres déterminés. Ensuite exécuter un modèle va demander à l'utilisateur une valeur pour chacun de ces paramètres et générer le mouvement correspondant. C'est très pratique quand on a souvent les mêmes mouvements à encoder.

Le plan comptable français a été revu et amélioré, et le plan comptable belge traduit en néerlandais.

Un wizard permet maintenant de tester le résultat du calcul des conditions de paiement. Comme cet objet a fortement évolué ces derniers temps, il devenait impératif pour l'utilisateur de pouvoir tester la configuration qu'il venait d'encoder au lieu de devoir attendre la première facture.

La couverture SEPA s'étend encore un peu plus avec l'inclusion des messages pain.001.003.03 et pain.008.003.02 qui sont utilisés en Allemagne et de la version CFONB pour la France. Il est également possible de régénérer un message s'il était mal configuré la première fois.

Les lignes de relevé créent des mouvements comptables groupés par numéro, date et tiers. Cela permet de comprendre plus facilement l'historique comptable.

Un nouveau type de compte depôt est ajouté par le module account_deposit. Il permet de gérer des dépôts clients et de rappeler ces dépôts plus tard sur la facture suivante.

La suite

Client web

Une campagne de financement a été réalisée au début de l'année afin de fournir une version complète du client web (sao).

Donc le développement a repris à un certain rythme se basant maintenant sur jQuery et Bootstrap. La demo de la version en cours de développement est disponible sur http://demo.tryton.org/ (demo / demo pour se connecter).

Python3

Le travail de fond pour le support de Python3 est maintenant bien avancé (https://bugs.tryton.org/issue3211). Il est fort probable qu'il sera présent dans la prochaine version dans 6 mois.

GTK-3

Le passage a GTK-3 prend par contre lui plus de temps par manque de moyens.

Aller plus loin

• Tryton (672 clics)
• Annonce (39 clics)
• Démo du client web en cours de développement (293 clics)