Cédric Krier a écrit 111 commentaires

  • [^] # Re: TVA à l'encaissement

    Posté par  (site web personnel) . En réponse à la dépêche Odoo : support de la déclaration de TVA avec télétransmission. Évalué à 4.

    Sur Tryton on a décidé de lister les taxes, qui sont basées sur encaissement, sur l'année fiscale (et optionnellement sur la période fiscale). Ceci permet de planifier le changement de régime d'une année à l'autre. On liste aussi les taxes sur encaissement sur les fournisseurs. Le résultat des deux configurations devient une propriété de la ligne de taxe comptable sur la quelle on calculera la proportion du montant payé à chaque période.

  • [^] # Re: gestion du numéro de série

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 6.2. Évalué à 4.

    Pour ça il faut activer le module stock_lot.

  • [^] # Re: Fonctionnalité POS (Point Of Sale) ?

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 6.0. Évalué à 4.

    Il y a un effort en cours pour ajouter un module de point de vente: https://bugs.tryton.org/issue8737
    Je ne sais pas ce qu'on entend exactement par "multi établissement" mais Tryton peut gérer plusieurs sociétés dans la même base de données et aussi plusieurs entrepôts.

  • [^] # Re: lien image refusé

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 6.0. Évalué à 4.

    C'était un problème de configuration du CDN qui bloquait les requêtes ne venant pas de discuss.tryton.org.
    Ça devrait marché maintenant, sinon vous pouvez consulter la capture d'écran (et d'autres) depuis la page de l'annonce.

  • [^] # Re: Point de vente

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.8. Évalué à 5.

    Pas encore mais il y a un prototype en cour: https://bugs.tryton.org/issue8737
    Après Tryton peut facilement être couplé avec un système de point de vente classique avec par exemple un import des ventes chaque jour.

  • [^] # Re: Intégrateur

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.6. Évalué à 3.

    Pour l'instant la liste présentée est construite sur le mérite, il faut participer activement au projet pour être listé.
    Tryton n'étant pas chapeauté par une entité commerciale mais juste une fondation composée de bénévole. Il est difficile de mettre en place une certification. De plus comme les participants au projet sont également les intégrateurs qui devraient être certifié, il faudrait que ces "concurrents" se certifient l'un l'autre.
    Pour un client, il est probablement préférable de demander des cas d'affaires pour juger de la compétence d'un intégrateur.

  • [^] # Re: Intégrateur

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.6. Évalué à 5.

    On utilise le thème Bootstrap par défaut exprès pour permettre à l'intégrateur d'utiliser le thème qu'il souhaite. C'est d’ailleurs le cas:
    Kopen thème
    Kalenis LIMS thème

    Par contre, il ne faut pas confondre "eye-candy" avec ergonomie. Nous faisons un effort important à avoir et maintenir une bonne ergonomie dans Tryton. Par exemple: l'interface est manipulable entièrement via le clavier; le majorité des actions sont applicables sur un ensemble d'enregistrements d'un coup; l'auto-complétion est présente sur la plupart des champs; les messages d'erreurs essaient de toujours fournir une solution; etc. Évidement il y a encore beaucoup de choses qu'on pourrait (et qu'on va) améliorer mais pour pouvoir juger de l'ergonomie d'un logiciel, il faut l'utiliser un certain temps.

    En ce qui concerne les intégrateurs nous maintenons une liste non-exhaustive. Comme c'est du logiciel libre écrit en Python et suivant assez bien les standards, il n'est pas trop difficile de trouver des développeurs qui peuvent y travailler.

  • [^] # Re: Pluriels et internationalisation

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.6. Évalué à 7.

    Pour l'instant, on a 4 plans comptables: Belge, Français, Allemand et Espagnole (l’Espagnole reçoit ces derniers temps beaucoup d'améliorations). Il y a un plan en préparation pour l'Angleterre.
    On voit que beaucoup utilisent Tryton pour faire le suivit d'une comptabilité de gestion et envoie les résultats chaque période au comptable. Du coup cette utilisation ne requière généralement pas d'un plan comptable ni de fonctionnalité spécifique pour le pays.
    Mais cela n'empêche pas certain de faire toute leur comptabilité dans Tryton moyennant une bonne connaissance comptable.

  • [^] # Re: Question secondaire

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.4. Évalué à 4. Dernière modification le 12 novembre 2019 à 12:56.

    La fonction existait aussi dans plusieurs modules extérieurs (implémentée de différentes manières). Mais l'intérêt de l'avoir de base est la garantie de montée en version, la compatibilité avec tous les autres modules de base, la maintenant et évolution collective.

  • [^] # Re: Question secondaire

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.4. Évalué à 3.

    je l'utilise chez mes clients depuis des années, des clients dans l'industrie pharmaceutique, ils achètent souvent dans des unités très différentes de celles de la vente.

    Pour moi, la seul façon de faire avec Odoo c'est d'avoir des catégories d'unité de mesure différentes pour chaque produit. Car il y a bien une contrainte entre les deux unités de mesure: https://github.com/odoo/odoo/blob/72be63b592bfe5a7b21970b86955e84d5224b667/addons/product/models/product_template.py#L343-L347
    Ceci pouvait se faire aussi sur Tryton depuis la version 1.0.

    Ici les modules permettent d'utiliser des mesures de catégories différentes en définissant le facteur de conversion sur la fiche produit. Ainsi on ne démultiplie pas les unités de mesures.

    j'ai essayé de tester GnuHealth, implémentation de Tryton dans la gestion médicale, sans trop de succès.

    GNU Health cible les pays en voient de développement où la législation en la matière est moins contraignante. Le but de l'ONG est d'amélioré les soins de santé par une informatisation efficaces des établissements.

  • [^] # Re: Question secondaire

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.4. Évalué à 2. Dernière modification le 12 novembre 2019 à 09:42.

    sinon, pour la fonctionnalité, je confirme que ca existe dans OpenERP/Odoo depuis au moins la version 6.04 (si ce n'est la 5).

    L'a-tu testée ? Moi, en l'activant elle ne me permet pas de définir deux unités de mesure de catégories différentes.
    Tryton aussi a cette fonctionnalité depuis la version 1.0 (avec même 3 unités différentes pour l'achat, la vente et le stockage).

  • [^] # Re: Question secondaire

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.4. Évalué à 3.

    fonctionnalité qui existe depuis plusieurs années sur OpenERP/Odoo

    J'ai beau cherché, je ne la trouve pas dans la version publiée. Il y a bien une options de configuration mais quand elle ne permet pas d'utiliser une unité de mesure d'une catégorie différente que celle de l'unité de base.

    un commerçant achète du tissu en rouleaux et le vend à la découpe au mètre ou une entreprise qui achète des fûts et les vend au litre ou kg … dans ces exemples, il n'y a aucune relation de conversion naturelle entre ces unités de mesures et la entre en jeu la double unité de mesure.

    Je ne vois pas la différence avec mon exemple initial. Que le facteur de conversion soit une propriété physique connue ou pas, ça reste le même traitement.
    Par contre le cas du rouleaux est plus complexe car de 2 rouleaux on peut pas découper un tissu qui est la somme des deux.

    Un point qu'on peut préciser, c'est que les modules de Tryton garde le taux de conversions utilisés lors de la prise d'ordre, même si celui-ci est changé sur la fiche du produit par après. Et ce taux suit sur les documents créés comme la facture ou les bons de livraison.

  • [^] # Re: Question secondaire

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.4. Évalué à 7. Dernière modification le 10 novembre 2019 à 10:24.

    Tryton de base faisait déjà de la conversion d'unité de mesure sans problème (ex: kg -> gramme) tant que le facteur de conversion est clairement définit (ex: SI).
    Ici les unités secondaires sont des conversions entre unité qui n'ont pas de facteur de conversion générale. Par exemple: une conversion de poids en volume. Le facteur dépendra à chaque fois du produit pour lequel la quantité est exprimée.
    Donc ces modules permettent d'acheter ou de vendre des produits dans une unité qui n'est pas convertible avec l'unité de stockage à condition qu'un facteur de conversion soit définit sur leur fiche. Exemple: une société achète du sable au volume (10 m³) et le vend au poids (2 kg).

  • [^] # Re: Odoo pour la comptabilité

    Posté par  (site web personnel) . En réponse à la dépêche Dolibarr ERP CRM v10 est disponible. Évalué à 5.

    Il y a aussi Tryton qui a un module pour la comptabilité française et aussi une interface vers Chorus Pro en plus des fonctionnalités comptables classiques.

  • # Tryton et ses modules timesheet & project

    Posté par  (site web personnel) . En réponse au journal Time tracker sur projets. Évalué à 3.

    Tu peux essayé juste les modules timesheet et project de Tryton (écrit en Python/Javascript/PostgreSQL et sous licence GPL-3).
    Avec son système de module et d'extension, il est possible du customiser les modules standards très fortement pour correspondre aux besoins particuliers.
    Il y a également un addons web Chronos qu'on peut installer dans son navigateur pour encoder rapidement ses "timesheets".

  • [^] # Re: float vs decimal

    Posté par  (site web personnel) . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 3.

    Et bien il manque un test avec un model qui a un champ Function et un champ related pour 'currency' comme l'indique le commentaire.

  • [^] # Re: float vs decimal

    Posté par  (site web personnel) . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 5.

    Ce lien concerne un module qui ne fait pas partie de Odoo, un module tiers de l'OCA. Je n'ai pas creusé plus que cela, mais probablement un bug dans leur code qui court-circuite l'ORM standard. L'ORM Odoo traite bien les décimal correctement.

    Je ne pense pas que ce soit un bug dans le code de l'OCA. En fait, il y a même un commentaire dans le code d'Odoo qui explique le bug: https://github.com/odoo/odoo/blob/12.0/odoo/fields.py#L1334 Dommage que le bug n'ait pas été corrigé depuis sa découvert il y a 3 ans (le 12/4/2016).

    Voici un test fait rapidement (sur une branch master-nochange-fp, mais le comportement est le même depuis les premières versions de Odoo): http://tinyurl.com/y263r7cx

    J'aurais préféré voir un test unitaire qui garantie la conformité dans le temps et pour tous les cas limite.
    De plus j'imagine que le test est fait avec un champ Float et un nombre de décimal hard codé.

    Faire cela amène les même désavantages que d'utiliser un float; si tu ne travailles pas avec la bonne précision, il faut alors quantize() manuellement à certains endroits dans le code. (e.g.lors de comparaisons, ou avant de storer, calcul de taxes, …)

    Pas nécessairement, par exemple le cas classique de:

    >>> 0.3 - (3 * 0.1)
    -5.551115123125783e-17

    n'existe pas avec decimal et sans arrondir:

    >>> Decimal('0.3') - (3 * Decimal('0.1'))
    Decimal('0.0')

    Mais pour moi, c'est une bonne chose que le développeur arrondisse explicitement quand il le veut et doit et que le framework lui dise quand il a oublié.

    Le débat revient juste à choisir quel côté du trade-off on préfaire:
    - float: performance, flexibilité / facilité de code
    - decimal: permettre de gérer des nombres avec plus de 16 chiffres

    Pas vraiment. Déjà Decimal n'est pas tellement plus lent (environ 2x) que float en Python3 puisque c'est écrit en C. Pour la flexibilité, Decimal l'est plus puisqu'on peut configurer le context comme on veut alors qu'avec float ça dépend du hardware. Pour la facilité de code, je pense qu'il est justement plus simple que le framework lève des exceptions quand on fait quelque chose de pas correcte qu'il n'essaie de corriger implicitement.
    Mais bon, je ne pense pas que j'arriverai à te convaincre car nous ne mettons pas la priorité sur les même objectifs. Je préfère l'exactitude qui peut être quelque fois contraignante à la facilité qui cache des approximations.

    PS: je t'invite a chercher sur google "tryton issue quantize" pour prendre du recul --> les deux approches ont leurs inconvénients.

    Cette recherche ne donne (à part l'issue Odoo où justement les gens prennent Tryton en exemple pour demander qu'Odoo utilise les Decimal) que 2 issues.
    La première est invalide car c'est quelqu'un qui appel quantize sur un dict (on peut parler typage statique avec Python 😉)
    La seconde est justement le cas de quelqu'un qui veut utiliser des nombres avec plus de décimal que ce que le context par défaut de Python ne supporte. Donc dans ce cas, il suffit de changer le context pour que ça marche (évidement au détriment de performance).

  • [^] # Re: float vs decimal

    Posté par  (site web personnel) . En réponse à la dépêche « Scale‐Up! » : un jeu éducatif pour apprendre la gestion d’entreprise. Évalué à 4.

    • tout est bien stocké en decimal après chaque opération dans la DB (tronqué correctement en fonction de la devise / UoM / …). C'est pratique car un champ a bien un contexte défini (précision, rounding), alors que les variables intermédiaires dans le code n'en ont pas nécessairement.

    Ça n'a pas l'air d'être vraiment le cas: https://odoo-community.org/groups/contributors-15/contributors-136015

    • cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.

    Ce n'est pas limité à seulement la comparaison à 0 mais à n'importe quelle chiffre et opérateur (>, <, >=, <=).

    • cela ne pose strictement aucun problème d'arrondi pour des use cases business (les float Python sont des double C --> 11 bits exposant, 52 bits valeur), le seul risque est de ne pas faire une comparaison correcte à 0, lorque vous développez un module custo.

    En fait, le contexte de decimal ne doit pas être mis à jour pour chaque variable. Dans le pratique on définit une fois la précision des calcules intermédiaires (les valeurs par défaut prec=28, Emin=-999999, Emax=999999 sont bien dans la majorité des cas). Et on arrondit le résultat final à la précision attendue.

    Le risque de bug par un développeur de module est pour moi beaucoup plus grand si Odoo n'utilisait que des decimals

    Ça dépend ce qu'on appel un bug. Si ne pas avoir d'exception mais un résultat incorrect n'est pas un bug alors oui. Mais à mon avis, il est préférable de détecter les bug en levant une exception mais si le résultat pour le cas courant n'est pas faux.

    En fait utiliser des Decimal permet d'avoir un vrai test sur la précision du nombre stocker dans un champs et donc d'éviter la découverte trop tard de problème d’arrondi comme https://odoo-community.org/groups/contributors-15/contributors-136015

  • [^] # Re: Pourquoi pas l'ODT

    Posté par  (site web personnel) . En réponse à la dépêche Première version stable pour WeasyPrint. Évalué à 2.

    OK, je comprends. Ça dépend vraiment de qui va créer les "templates". Dans notre cas, on cherchait à avoir un outil plus ou moins WYSIWG.
    Par contre, il n'y a pas besoin d'avoir LibreOffice pour générer des ODT avec relatorio. C'est seulement si on veut convertir dans un autre format. Du point de vue "templating", relatorio est basé sur Genshi et donc il y a vraiment toutes les fonctionnalités des moteurs de templating.

  • # Pourquoi pas l'ODT

    Posté par  (site web personnel) . En réponse à la dépêche Première version stable pour WeasyPrint. Évalué à 4.

    Étant un des auteurs de relatorio qui est un générateur d'ODT, je me demande pourquoi l'option ODT n'a pas été retenue ? Je n'ai pas retrouvé les raisons dans la vidéo.

  • [^] # Re: Tests

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.0. Évalué à 7.

    Je devrais aussi préciser que notre CI lance les tests sur toutes les versions de Python supportées et avec les backend SQLite et PostgreSQL: https://drone.tryton.org/
    Les tests avec SQLite, c'est surtout pratique quand on développe.

  • [^] # Re: Export du fichier des écritures comptables - Fichier FEC

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.0. Évalué à 10.

  • [^] # Re: Tests

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.0. Évalué à 7.

    Pour la plus part du temps, on a un contournement quand une fonctionnalité n'existe pas sur un "backend".
    Et si un test requière une fonctionnalité spécifique qui n'est pas disponible pour le "backend" testé alors on le passe.

  • [^] # Re: Docker en prod ?

    Posté par  (site web personnel) . En réponse à la dépêche Sortie de Tryton 5.0. Évalué à 5.

    L'image docker peut être utilisée en production, elle utilise le serveur uwsgi. Mais il est conseillé de la mettre derrière un proxy inverse comme nginx ou lighttpd. Si la taille de l'entreprise est assez grande, il faudra probablement un peu de paramétrage comme augmenté le nombre de processus ou bien faire de la répartition de charge. Il est aussi conseillé par les développeurs de PostgreSQL de ne pas containériser la base de données.

  • [^] # Re: Passer sur Odoo pour une petite compta libérale

    Posté par  (site web personnel) . En réponse à la dépêche Odoo génère la première facture Factur-X déposée sur Chorus Pro. Évalué à 1.

    Sauf qu’inversement c'est dans l'intérêt d'Odoo de ne pas communiquer dessus (si c'est vrai).