Sortie de GnuCash 5.9

 (gnucash.org)
2 points par GN⁺ 2024-10-02 | 1 commentaires | Partager sur WhatsApp
  • GnuCash 5.9 est la dixième version de la série stable 5.x ; elle inclut des corrections de bugs découverts depuis la 5.8 ainsi que des améliorations du parsing des dates CSV et des cotations en ligne
  • Cette version corrige 12 bugs, notamment dans la fenêtre de rapprochement, les messages d’erreur du backend MySQL, le copier/coller de transactions, un crash lors de la suppression de comptes et une erreur de locale pour le séparateur décimal du pavé numérique sous Windows
  • Pour les cotations en ligne, le paramétrage de clé API YH Finance(FINANCEAPI) et la source financeapi ont été ajoutés ; l’import CSV gère mieux les dates basées sur la locale et les noms de mois en anglais
  • Des paquets sont fournis pour Windows 10 et versions ultérieures, macOS 10.13 High Sierra et versions ultérieures, ainsi qu’en flatpak sur Flathub ; pour compiler soi-même, des dépendances minimales précises comme Gtk+, Guile et Boost sont requises
  • Les utilisateurs allemands d’AQBanking utiliseront AQBanking 6.5.4 inclus dans les bundles ; la bêta de la nouvelle implémentation PIN/TAN n’est disponible que dans les nightly builds de GnuCash

Nature de la version GnuCash 5.9

  • GnuCash 5.9 est la dixième version de la série stable 5.x
  • GnuCash est un logiciel de comptabilité gratuit et open source distribué sous GNU General Public License (GPL), compatible avec GNU/Linux, *BSD, Solaris, macOS et Microsoft Windows
  • Son développement a commencé en 1997 et sa première version stable est sortie en 1998

Principaux problèmes corrigés depuis la 5.8

  • Le problème où une nouvelle transaction ajoutée pendant un rapprochement (reconcile) n’apparaissait pas dans la fenêtre de rapprochement a été résolu
  • Le backend MySQL signale désormais l’erreur "access denied" pour des identifiants incorrects, au lieu de "bad or corrupt data"
  • Les comportements de copier/coller et couper/coller de transactions ont été corrigés
    • Cela inclut un problème où couper/coller une transaction ne la déplaçait pas vers le compte cible
  • Le problème où les scripts Python d’exemple affichaient une erreur lors de la création d’un nouveau fichier avec le backend sqlite a été corrigé
  • Dans la vue Transaction Journal, le problème de position du curseur décalée après la validation d’une modification de transaction a été corrigé
  • Des échecs de parsing de la date de rapprochement, un crash lors de la suppression d’un compte et une erreur de calcul trimestriel dans les décalages de dates relatives ont été résolus
  • Sous Windows, le problème où la saisie du séparateur décimal au pavé numérique ne correspondait pas à la locale a été corrigé
  • La liste déroulante des comptes dans l’écran de publication des factures, trop petite, ainsi que des problèmes intermittents de prix des cotations ont été corrigés

Améliorations des cotations en ligne et de l’import CSV

  • Le paramétrage de clé API YH Finance(FINANCEAPI) a été ajouté à l’infrastructure des cotations en ligne
    • Les réglages correspondants peuvent être gérés depuis la page Online Quotes
    • financeapi a été ajouté aux sources de cotations connues
  • Le parseur de dates CSV a été amélioré pour utiliser ICU et Boost
    • Il parse les dates de la locale actuelle avec le format de date Locale basé sur ICU
    • Il peut traiter des entrées comme "3 May 2023" ou "2024年9月13日" avec LC_TIME=zh_TW.utf8
    • Les formats d-m-y, m-d-y et y-m-d sont renforcés par les parseurs UK/US/ISO de Boost
    • Les dates avec noms de mois en anglais comme "30 Sep 2023", "May 4, 1978" ou "2023-Dec-25" peuvent aussi être traitées lors de l’import CSV
    • Le parseur Boost ne reconnaît pas les années sur deux chiffres ; "30 Sep 24" n’est donc pas valide
  • La page d’introduction de l’assistant d’import CSV a été améliorée

Nettoyage interne et changements destinés aux développeurs

  • La structure de traitement des éléments copiés a été clarifiée
    • copied_class et copied_leader_guid ont été déplacés de variables statiques vers des éléments de la structure copied_item
    • Le fait qu’un appel à clear_copied_item soit nécessaire avant l’utilisation de copied_item est devenu plus explicite
  • Les éditions non validées sont correctement prises en compte lors de l’ouverture d’un fichier depuis l’historique des fichiers
  • gnc_difftime est déprécié, car il caste time64 en double
  • Les éléments inutilisés gnc_pricedb_substitute_commodity et gnc_pricedb_lookup_at_time64 ont été supprimés

Changements de traduction et de documentation

  • Les traductions nouvellement ajoutées ou mises à jour concernent l’assamais, le chinois simplifié, le chinois traditionnel, le croate, le néerlandais, l’anglais du Royaume-Uni, l’hébreu, le hongrois, le macédonien, le norvégien bokmål, le portugais du Brésil, le russe, l’espagnol, le suédois et le turc
  • Côté documentation, le changement porte sur la mise à jour des versions des actions GitHub CI
  • Pour la documentation, la traduction allemande a été ajoutée ou mise à jour
  • Les contributions aux traductions sont guidées via le projet GnuCash sur Weblate

Informations liées à AQBanking

  • Une note séparée est incluse pour les utilisateurs allemands de AQBanking
  • L’auteur d’AQBanking poursuit le travail de finalisation du code PIN/TAN mis à jour
  • Les bundles Flatpak, macOS et Windows de cette version incluent la dernière version stable, AQBanking 6.5.4
  • Si la version stable d’AQBanking ne fonctionne pas, il est possible d’envisager les nightly builds de GnuCash, qui incluent la bêta de la nouvelle implémentation
  • La liste complète des bugs ouverts est consultable dans la liste des bugs de GnuCash

Paquets de distribution et conditions de build

  • GnuCash 5.9 est fourni sous forme de paquets tout-en-un précompilés pour Microsoft Windows 10 et versions ultérieures, ainsi que macOS 10.13 High Sierra et versions ultérieures
    • Sous Windows, il s’agit d’un installateur
    • Le paquet macOS est une image disque contenant un bundle d’application à glisser-déposer
  • Il est également disponible sous forme de flatpak sur Flathub.org
  • Les fichiers de téléchargement incluent un tarball, un installateur Windows, un dmg pour Apple Silicon, un dmg pour Mac Intel et un tarball de documentation
  • Le code source est disponible sur SourceForge et GitHub au format bzip2 ou gzip, et peut aussi être directement extrait depuis le dépôt Git
  • Pour compiler soi-même, les dépendances minimales suivantes sont nécessaires
  • Pour la liste exacte des dépendances et des versions, il faut consulter le fichier README.dependencies des sources

Documentation de GnuCash 5.9

  • La documentation de GnuCash 5.9 est disponible sur la page Documentation du site web de GnuCash
  • Sous GnuCash v5 (current stable release), elle est proposée en plusieurs langues, en lecture en ligne et en téléchargement
  • Les formats de téléchargement incluent pdf, epub et mobi
  • La documentation est aussi incluse dans les bundles d’applications macOS et Windows
  • Les sources de GnuCash Documentation 5.9 sont disponibles sur SourceForge ou GitHub, et peuvent aussi être directement extraites depuis le dépôt Git

À lire aussi

1 commentaires

 
GN⁺ 2024-10-02
Avis de Hacker News

  • J’utilise GnuCash pour la comptabilité de mon entreprise et il couvre suffisamment les fonctionnalités dont j’ai besoin
    Je n’utilise pas QuickBooks, que les VC recommandent sur leurs blogs : il a certes des fonctions pratiques, mais pas au point de justifier son prix, et je n’ai pas besoin de financement VC ni de CPA
    Je n’ai jamais essayé GnuCash avec SQLite, mais j’aimerais faire des tests quand j’aurai le temps, et je me demande quel est son niveau de fiabilité
    J’ai travaillé autrefois comme ingénieur technique/fonctionnel sur Oracle EBS, en manipulant des schémas complexes où même les livres auxiliaires étaient imbriqués les uns avec les autres, et j’ai toujours eu en tête l’idée d’ajouter à GnuCash une fonction de reconnaissance du chiffre d’affaires
    En regardant le schéma SQLite, je pourrais peut-être tenter quelque chose

    • Si quelqu’un qui migre depuis QuickBooks veut aider d’autres personnes, le convertisseur QuickBooks→GnuCash qb-escape a besoin d’aide : https://github.com/erikmack/qb-escape/
    • Dans GnuCash, SQLite est stable
      Je suis passé de XML à SQLite il y a quelques années et je n’ai eu aucun problème
    • C’est excellent pour un usage personnel ou une toute petite entreprise, mais si vous essayez de faire tourner une vraie startup avec GnuCash, vous risquez de gros ennuis
      D’après mon expérience directe, le culte de GnuCash est nuisible, et le monde des affaires déteste GnuCash et ne s’intéresse qu’à QuickBooks
      Depuis le début des années 2000, j’ai mené ce combat dans des organisations à but non lucratif et des startups, et à l’époque j’étais moi aussi de ceux qui disaient « nous devons absolument utiliser GnuCash »
      Dans un monde idéal, GnuCash, ou n’importe quel outil autre que QuickBooks, serait une option pour la comptabilité des petites entreprises, mais dans la réalité Intuit a rendu les alternatives à QuickBooks difficiles via ses API et ses formats de fichiers
      Si vous n’utilisez pas QuickBooks, les banques, les investisseurs, les systèmes de paie, les systèmes fiscaux et les comptables auront tous plus de difficultés, et dans certains cas cela peut même bloquer des subventions ou des audits
      Je vois souvent des défenseurs de l’open source, bien intentionnés, exiger l’utilisation de GnuCash ; il ne faut pas être cette personne
      Le monde a choisi QuickBooks, et même si ce choix s’est fait sous la pression et dans un jeu de courtage de pouvoir corrompu, il est déjà entériné
      Il peut exister des options SaaS correctes, mais seulement tant qu’Intuit les tolère, et toute concurrence à QuickBooks a de fortes chances d’être rachetée par Intuit puis de disparaître
      Dans plusieurs associations et entreprises, on a choisi GnuCash avant de devoir changer de plateforme dans l’urgence à cause de clôtures de financement, d’exigences bancaires, de demandes de prêt ou de dossiers de subvention ; au final, la personne chargée de la comptabilité a dû tout refaire avec des semaines de plus de 60 heures
      GnuCash est un superbe projet et ce serait bien que tout le monde puisse l’utiliser, mais pour une vraie entreprise, il est inutilisable pour des raisons arbitraires et artificielles
      Si un comptable venait vous imposer NetBeans, vous ne l’accepteriez pas ; il faut donc leur témoigner la même courtoisie dans le choix des outils
    • Cela ressemble à un autre cas de réussite du logiciel libre grâce à sa propriété d’être gratuit comme dans “bière gratuite”

  • J’ai essayé beaucoup de logiciels de comptabilité personnelle, mais, à part l’ancien Pocket Money pour PalmOS, tous rendaient la saisie des dépenses beaucoup trop pénible.
    Si l’on enregistre toute une visite en magasin comme une seule transaction, du type « courses chez Lidl », ça reste supportable, mais dès qu’on veut saisir chaque ligne du ticket comme un élément distinct d’une transaction ventilée, il faut tout retaper à chaque fois, sans bonnes suggestions basées sur l’historique.
    Par exemple, cela pourrait être assez fin pour proposer food:bread et un prix dès qu’on tape « br » si le tiers est Lidl, et clothing:bra avec un autre prix si le tiers est Victoria Secret, mais je n’ai rien essayé qui le prenne en charge.
    Le très vieux PalmOS 3.0 Pocket Money était vraiment pratique, et tout le reste, sur desktop comme sur mobile, est nettement moins bon sur ce point.
    Si l’on enregistre les transactions de façon très détaillée, je pense que des catégories imbriquées valent mieux que des « comptes » imbriqués.
    C’est presque une différence cosmétique, mais il est étrange que « espèces » et « food:meat:pork » soient des objets du même type.
    On ne transfère pas de l’argent vers « food:meat:pork » : on le dépense pour cela, et on envoie l’argent au magasin, pas au produit.
    À ma connaissance, même les systèmes comptables professionnels n’ont pas un compte d’actifs de l’entreprise séparé pour chaque écran, ordinateur portable, ordinateur ou souris.
    Je me demande si je n’ai simplement pas encore trouvé ce qu’il faut, ou s’il existe quelque chose à recommander.

    • Je me demande si suivre chaque article d’un ticket est réellement si utile.
      Cela peut servir pour certains types d’achats, mais il est très possible que ce soit un travail de détail inutile qui ne crée pas assez de valeur au regard de l’effort demandé.
    • J’ai essayé plusieurs outils par le passé et, vers 2009, agacé par les logiciels propriétaires OS X, notamment iBank, et n’aimant pas non plus GNUCash ni KDEMoney, j’ai fini par créer moi-même une petite application open source.
      C’est une application Cocoa native, avec récemment aussi un port Qt pour Linux, et je l’utilise tous les jours depuis.
      Avant, je découpais les catégories très finement, mais aujourd’hui je n’y vois plus beaucoup d’intérêt ; l’application prend en charge les transactions ventilées, mais j’utilise généralement seulement des catégories comme « courses », « boissons » et « produits essentiels ».
      En revanche, pour quelque chose comme « café », je le mets dans « Drinks:Coffee » afin de pouvoir voir combien je dépense sur ce poste précis.
      Au final, cela semble être une question d’équilibre entre l’effort nécessaire pour enregistrer les choses avec ce niveau de précision et la valeur réelle qu’on en tire ; c’est pareil pour des catégories comme « Car:Fuel » ou « Car:Service ».
    • Quand j’ai commencé à suivre mes finances, une simple feuille de calcul a vite atteint ses limites, et les options existantes ne répondaient pas à mes besoins.
      Pour la plupart des gens, ce niveau de suivi détaillé est peut-être excessif, mais pour moi cela ne prend pas beaucoup de temps.
      J’ai donc fini par créer ma propre application : https://github.com/VMelnalksnis/Gnomeshade
      J’avais un ressenti similaire au sujet des comptes, donc j’ai divisé les transactions en deux parties, virements et achats, ce qui permet de gérer plusieurs devises tout en traitant les catégories séparément des comptes.
      Je ne me suis pas penché sur les suggestions automatiques mentionnées ; je suis plutôt parti sur le parsing des tickets pour les articles que j’achète souvent.
    • Tu es probablement en train de trop granulariser.
      Moi, je me limite à des catégories comme « courses », « consommables » et « vêtements ».
      Je n’ai pas complètement compris ce dont tu as exactement besoin, mais je suis passé de GnuCash à KMyMoney il y a plus de dix ans.
      Si tu avais auparavant saisi les articles un par un chez Walmart, alors la fois suivante, quand tu vas chez Walmart et importes le relevé de carte de crédit, il prend comme point de départ une ancienne transaction Walmart au montant total similaire, ce qui aide un peu.
      Et KMyMoney utilise des catégories plutôt que des comptes, même si l’approche par comptes est plus conforme aux principes comptables.
    • Ce serait bien qu’il existe un format de QR code sur les tickets pour ce genre d’usage.
      Il pourrait contenir, grosso modo, le nom/l’emplacement du magasin, le total, des champs séparés pour les taxes, une catégorie générale pour les achats simples, comme « carburant » ou « nourriture » sur un ticket McDonald’s, ainsi que des groupes d’articles pour les endroits comme Costco où l’on peut acheter à la fois des produits alimentaires et des vêtements.
      Pour les grandes catégories, on pourrait s’inspirer de celles que plusieurs pays utilisent pour l’indice des prix à la consommation.
      https://www150.statcan.gc.ca/n1/pub/71-607-x/2018016/cpi-ipc...
      https://www.bls.gov/news.release/cpi.t01.htm
      https://www.stat.go.jp/english/data/cpi/158c.html
      https://www.ecb.europa.eu/stats/macroeconomic_and_sectoral/h...

  • Je n’aime pas vraiment le modèle de GNUCash.
    Il est un peu fastidieux à utiliser et il est assez difficile d’en tirer les statistiques que je veux ; à l’époque, j’avais essayé plusieurs autres packages avant de me fixer.
    Cela dit, quand j’ai obtenu mon premier emploi il y a des décennies, GNUCash existait déjà, et il existe encore aujourd’hui.
    Il me semble qu’il y a très peu d’autres packages qui aient montré une telle continuité.

    • Le fait qu’il ait un design d’utilitaire du milieu des années 90 a un certain charme.
      En même temps, c’est précisément cette interface façon années 90 qui le rend terriblement frustrant.
      Je n’ai jamais vu d’utilitaire dont la conception d’interface ait aussi peu évolué que celle de GNUCash.
      On dirait qu’ils ont fait un prototype, dit « parfait ! », puis ignoré les retours des utilisateurs pour passer au travail sur le backend.
    • Cette continuité a une valeur énorme.
      J’utilise gnucash depuis la fin des années 90, et j’ai tous mes fichiers de données qui remontent jusqu’à 2000.

  • Je l’ai essayé il y a quelques années, mais j’ai finalement adopté HLedger
    Comme avec GnuCash, je peux posséder et contrôler mes données, mais avec HLedger je peux les modifier directement dans Sublime Text pour corriger ou changer des choses en masse
    Bien sûr, mon cas d’usage est assez basique et ce n’est pas un système critique pour mon activité, donc cela peut varier selon les personnes

    • C’est une raison valable de ne pas utiliser GnuCash
      Je suis d’accord pour dire que le format XML n’est pas idéal, mais j’utilise le format SQLite, ce qui me permet d’écrire des scripts par-dessus
    • J’utilise Firefly III : https://firefly-iii.org
      C’est une application web auto-hébergée, donc c’est pratique pour moi qui l’utilise surtout depuis mon téléphone
      Elle dispose d’une API assez étendue et, même si l’édition en masse n’est pas aussi simple qu’avec des fichiers texte, cela devrait rester relativement simple
      Il y a aussi un système de règles qui peut servir à faire des modifications en masse
    • J’utilise GnuCash, et l’absence de modifications en masse ou de scripting facile est assez agaçante
      Par exemple, surtout quand on a fait une petite erreur lors d’un import CSV
    • J’utilise hledger et ledger, en particulier la fonction lots, depuis plusieurs années
      L’un des points forts de hledger est son système de règles CSV très flexible
      J’y ai ajouté un petit script Python pour insérer les informations supplémentaires nécessaires à l’enregistrement des plus-values
      Au final, les données d’entrée brutes sont des fichiers CSV contenant les écritures, et la sortie est constituée de rapports financiers à plusieurs niveaux de détail
    • Je fais effectivement tourner un petit script qui convertit le XML de gnucash en ledger, et je suis le résultat de la conversion ainsi que le XML original avec git
      En l’exécutant assez souvent pendant la saisie dans l’interface de gnucash, on peut voir les changements sous forme de logs git et de diffs lisibles
      En revanche, il manque la capacité de faire des « modifications en masse »
      Comme gnucash n’est que du XML, on pourrait aussi l’éditer directement, mais je n’ai pas encore osé le faire
      Basé sur [0] : https://gist.github.com/nonducor/ddc97e787810d52d067206a592a...

  • J’utilise GnuCash pour la comptabilité d’un hackerspace
    Le choix était soit de l’utiliser, soit d’utiliser un site appelé « wave », recommandé par le responsable de la comptabilité d’un makerspace voisin
    Je me suis inscrit sur wave et j’ai un peu testé, mais je n’étais pas convaincu ; quelques semaines plus tard, quand j’ai décidé d’utiliser wave, mon compte était verrouillé sans raison
    Je suis donc parti sur GnuCash
    C’est un bon logiciel et, au final, j’ai écrit du code qui se lie dynamiquement à la bibliothèque libgnucash pour générer automatiquement les factures mensuelles des cotisations des membres

    • Je me demande s’il n’existe pas une meilleure façon d’automatiser GnuCash, par exemple avec des scripts Bash ou Python
    • Intéressant, je me demande si le code pourrait être partagé

  • J’ai étudié GnuCash en détail avant de choisir Beancount ou, plus généralement, la comptabilité en texte brut comme logiciel de finances personnelles
    Le point bloquant décisif a été le format interne XML ou SQLite de GnuCash
    Il n’est pas particulièrement adapté au scripting pour la collecte de données brutes ou la génération de rapports, alors que les outils en texte brut comme Beancount ou HLedger visent précisément cela
    Comparé aux outils en texte brut, GnuCash donne trop l’impression d’un jardin clos
    Le format texte brut demande plus de travail au départ, mais il est excellent une fois qu’on s’y est habitué et qu’on a un bagage en scripting

    • Chacun ses préférences, mais mon expérience est exactement inverse
      Le texte brut semble simple à l’œil humain, mais c’est un cauchemar à parser de façon structurée, et scripter l’édition de texte brut est aussi assez sale
      À l’inverse, les bases de données sont faites pour ce genre d’usage
      Après avoir passé beaucoup de temps sur mes frustrations avec la comptabilité en texte brut et sur des tentatives d’amélioration, j’utilise maintenant SQLite, et c’est une énorme amélioration
    • Si le schéma XML/DB est documenté, c’est en réalité meilleur et plus robuste que le format texte brut de Beancount/Ledger
      J’utilise le backend XML de KMyMoney, et j’ai aussi un script qui convertit les données au format Ledger
      Comme ce n’est pas du texte en format libre, ce script a au contraire été plus facile à écrire
    • La combinaison Beancount + Fava a l’air plutôt bonne ; je me demande si tu peux partager ton expérience avec
    • Si SQLite ne suffit pas, GnuCash prend aussi en charge un backend SQL
      Je fonctionne comme ça depuis près de 10 ans

  • GnuCash occupe une place particulière dans mon cœur
    Pendant les premières années après l’université, je gérais un budget très serré avec un revenu limité, et à chaque fois que je faisais les courses, je rapportais le reçu à la maison pour le saisir consciencieusement dans les comptes
    Tout tombait toujours juste, mais c’était énormément de travail

  • En tant que consultant freelance en Suède, j’ai regardé GnuCash plusieurs fois au cours des plus de dix dernières années, mais il y a toujours eu le même problème
    Il n’est pas adapté à notre économie ni au système de l’administration fiscale
    En Suède, si le chiffre d’affaires est inférieur à 3 millions de SEK par an, on peut utiliser un « förenklat årsbokslut », en gros une « clôture annuelle simplifiée »
    En pratique, il suffit de créer soi-même un programme très basique pour gérer les dépenses et les recettes, de produire les chiffres nécessaires, puis de les saisir manuellement chaque année dans l’application en ligne de l’administration fiscale

    • Je suis aussi freelance solo et j’utilise la comptabilité simplifiée
      La comptabilité en partie double, une fois passée la courbe d’apprentissage initiale, ne m’a pas demandé plus d’efforts que la comptabilité en partie simple
      C’est parce qu’elle permet d’éviter automatiquement les erreurs courantes
      J’utilise GnuCash avec succès depuis 20 ans, et je n’ai aucune envie de revenir à une feuille de calcul fragile ou à une base Access bricolée

  • J’ai utilisé GnuCash pendant un moment, mais je finissais par passer beaucoup trop de temps à régler la synchronisation en ligne
    Pour les comptes qu’il fallait télécharger et importer manuellement, cette friction me faisait repousser l’import
    Aujourd’hui, je paie pour Quicken Classic, et c’est l’une des dépenses annuelles dont je suis le plus satisfait
    Les connexions aux comptes en ligne fonctionnent régulièrement comme prévu, et globalement, ça permet d’en finir avec beaucoup moins de prise de tête

    • Je dois gérer des comptes aux États-Unis, au Canada, dans deux pays de l’UE et au Mexique
      J’aimerais qu’il existe une option payante dont les connexions bancaires fonctionnent de manière aussi fiable que Quicken Classic, mais il ne semble même pas y avoir un seul produit qui couvre à la fois les États-Unis et ne serait-ce qu’une grande économie de l’UE, alors toutes les régions dont j’ai besoin, encore moins
      Quicken Classic est réservé aux États-Unis et au Canada
      Je me demande si vous connaissez ce genre d’option, ou plusieurs options que l’on pourrait raisonnablement utiliser ensemble pour atteindre cet objectif
      Vu que les sociétés d’accès aux données de transactions ne semblent pas franchir le pont États-Unis-UE d’une manière pratique pour les particuliers, il doit y avoir des raisons du type incompatibilité entre les bureaucraties des deux côtés
      Ou alors il n’y a tout simplement pas assez de gens qui ont une vie aussi internationale

  • J’ai géré une entreprise avec GnuCash, y compris la paie et la gestion de comptes 401k
    C’était stable, et le suivi des dépenses était suffisant pour une entreprise aux dépenses limitées, ou si l’on a une expérience de la comptabilité
    C’était vraiment appréciable de pouvoir générer un bilan et un compte de résultat à remettre au comptable