Comptabilité en texte brut

Bonjour,

J’ai surtout travaillé à mon compte mais ce n’est que depuis l’année dernière que je prends ça plus au sérieux, incluant les aspects comptables.

Est-ce qu’il y en a parmi nous (au Québec) qui utilisent le Plain Text Accounting (PTA) et qui voudrait m’accompagner dans ce long voyage? Alternativement, avez-vous un bon comptable à me suggérer?

J’aurais besoin d’un bon guide pour tout le tralala: taxes, impôts, comptabilités, conseils, etc.

1 « J'aime »

Oui, ça m’intéresse, et merci infiniment de me faire découvrir, en ayant posté ici!

Je suis trésorier d’une troupe de théâtre et j’essaie de trouver une méthode alternative à Calc/OnlyOffice/Excel pour faire ma comptabilité. Cependant j’ai des besoins particuliers :

  1. Je dois pouvoir lier des dépenses et des revenus à une production théâtrale en particulier;
  2. Je dois pouvoir créer des liens avec mes pièces justificatives qui sont téléversées en ligne.

Le premier point devrait ainsi me permettre de faire un bilan comptable de chacune de mes pièces de théâtre. Le second point facilitera l’audit.

Il est important d’avoir un système facile à prendre en main. Je constate après quelques minutes d’étude que le PTA a ce potentiel. Les outils sont peut-être encore à développer, cependant.

Pour le groupe LinuQ, j’utilise GnuCash. Il offre le minimum dont un petit organisme a besoin. J’en ai fait l’apprentissage en me servant du site:

Il y a plusieurs autres tutoriels sur Internet. Il y a sûrement moyen de créer un compte particulier pour un projet.

Il y a aussi la version libre («community») de Odoo. C’est une logiciel assez complet pour entreprise. Certains diront que c’est trop pour un petit organisme. Peut-être, mais je n’en suis pas sûr. Il est modulaire et on n’installe que ce qui est nécessaire à notre besoin.

CE SOIR (7 mai 2024-heure de Montréal) , il doit y avoir une présentation d’Odoo durant la réunion mensuelle du Linux-Meetup. Trouver le lien ici:

Après une semaine d’essais, mon choix est porté sur hledger.

Les plus :

  • La saisie n’a pas à se faire via un logiciel précis. N’importe quel éditeur texte peut faire. Comme mon organisation utilise Nextcloud, j’utilise des fichiers .txt pour stocker les transactions et je les édite en ligne, que ce soit par mon ordinateur que par mon téléphone. Je les ai appelés affectueusement 2023.txt et 2024.txt. :stuck_out_tongue: Inscrire une nouvelle transaction dans un fichier texte est archifacile; il ne s’agit que de respecter les normes (commencer la première ligne par la date, faire au moins une espace pour indenter les lignes, faire au moins deux espaces entre le nom du compte et le montant…). Il peut être donc fait directement sur mon fichier stocké en ligne. Je n’ai à le télécharger ensuite pour l’analyser avec hledger.
  • Le logiciel détecte le formatage des nombres: Peu importe que j’utilise une virgule ou un point comme symbole décimal, il fera avec. Il est aussi agnostique sur la devise utilisée (CAD, USD, Euros…). Je peux même ne pas l’indiquer, et c’est ce que je fais, d’ailleurs. La seule restriction est d’utiliser toujours la même syntaxe dans tout le fichier.
  • On peut mettre des tags et des commentaires. Ça, là… c’est ben pratique. Après, on peut faire des analyses sur seulement les transactions attachées à un tag. Il faut juste encore là s’assurer d’écrire tous ses tags pareils. On a intérêt à avoir de courts tags. Et les commentaires, pour moi, c’était surtout pour mettre le lien vers les photos de mes factures, alors c’est parfait.
  • Le versionnage de fichier avec Git ou autre (moi, c’est dans Nextcloud) est facile. Et on s’entend pour dire que la corruption d’un fichier texte est quasi impossible.
account Actifs    ; type:A
account Dépenses  ; type:X
alias EOP = Actifs:Caisse:Opérations

2024-01-05 Location de costumes - Frais  ;prod:combustibles
    EOP  -57,49  
    Dépenses:Costumes  ;https://url.ca/s/MSRYdYPFsTkRJyY

2024-01-16 Décors - Achats chez Patrick Morin  ;prod:combustibles
    EOP  -31  
    Dépenses:Décors  ;https://url.ca/s/zCo6K4dwtQtfdAr 

Les moins :

  • La seule documentation trouvée sur le sujet est en anglais. J’en suis autant surpris que déçu. Même chose pour le logiciel lui-même; je n’ai pas réussi à avoir les noms des mois en français dans mon rapport comparatif mensuel.
  • Il n’y a pas présentement d’analyseur web facilement installable sur un de mes serveurs web. Aucun projet dérivé de legder n’a été fait en PHP. Je suis programmeur PHP, mais je n’oserais pas m’aventurer à développer ça. Par contre, les analyseurs que j’utilise (hledger, hledger-ui et hledger-web) n’ont pas à être installés sur l’ordinateur qui les exécute, alors c’est un moindre mal.
  • Évidemment, il faut aimer taper des commandes dans le terminal et lire la doc (qui est en anglais, je le rappelle). Ça ne me rebute pas, mais je suis conscient que ce n’est pas à la portée de tout le monde.
  • Tenir son journal des opérations dans un fichier texte fait qu’il n’y a pas à la base de façon rapide et automatisée de vérifier la validité d’une nouvelle transaction entrée.

Malgré ses objections, je garde le cap. Je vois beaucoup d’avantages à rester avec cette méthode. Et je me documente petit à petit…

3 « J'aime »

@bpruneau Merci pour l’analyse - je vais me pencher sur le côté de la langue du logiciel (des rapports) et je reviens.

C’est pas demain que ça sera fait. Entre-temps, peut-être qu’une passe après la génération permettrait de traduire dans la plupart des cas.

J’aimerais connaître les inconvénients de la méthode Calc/OnlyOffice/Excel qui te donnent envie de changer.

Hé boy, par où commencer…

Un tableur n’est pas un système comptable de facto. Il faut le « programmer » pour qu’il le devienne.

Si l’opération semble facile à démarrer, elle se complexifie à mesure que des postes budgétaires se créent. Si l’on doit créer une colonne à chaque nouveau poste budgétaire à créer, soit on se perd dans les colonnes, soit on finit par faire une colonne « Autres » qui devient un poste fourre-tout. Après, il faut faire la balance des opérations quasiment à la main sur une autre feuille de calcul, ensuite un bilan financier pour chacun de nos projets sur une autre feuille de calcul (un par projet)…

Et ça, c’est sans compter le risque de perte de données en passant d’un logiciel à l’autre. Par un beau matin, j’ouvre mon journal général des opérations en format .ods pour m’apercevoir que ma colonne des dates de transactions était affichée avec des « ######### » parce que son format d’affichage avait muté fouille-moi-comment pour afficher l’heure (toujours minuit)… et plus tard, pire, avait été vidée! (Ça affichait aussi un message d’erreur « Dépassement de capacité », à l’ouverture.) Que s’était-il passé? Aucune idée, et heureusement que j’avais des sauvegardes, mais je ne veux plus jamais revivre cette épreuve.

C’est à ce moment que je me suis rendu compte que le format de fichier était important et que je devais pouvoir modifier le fichier sans avoir peur de le corrompre à cause d’un changement d’éditeur. Le format texte brut m’offre ça. Pour peu qu’on reste en UTF8…

2 « J'aime »

Merci pour la recherche! :+1:

En fait ça m’a bien surpris qu’il n’y ait aucun i18n/l10n là dedans. Et, ahum, mon haskell laisse à désirer :wink:

Je n’ai pas encore mis les mains dedans mais en temps et lieu, je vais voir pour un postprocesseur. J’ai aussi cherché plus largement et ça n’existe pas, ou je n’ai pas trouvé.