Discussion comptabilité d'entreprise

Utiliser mon Dolibarr Modules financiers
18

Allons-y pour la collaboration, c’est avec plaisir :

En fait, je me suis mal exprimé. Une véritable compta repose sur une architecture de base de données très propre. A l’aide de requêtes SQL, on pourra pratiquement tout faire. Dans la v5, ce n’était même pas la peine de commencer à faire de la compta. Par contre, en v6, on peut envisager de travailler.

Voici mes questions concernant la version GIT :

  1. https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/install/mysql/tables/llx_accounting_bookkeeping.sql
    Pourquoi faire une comptabilité en centimes ?
    Ou alors, il faudrait que tout Dolibarr gère les centimes et migrer toutes les bases existantes.

On ne pourra pas faire de jointure sur des numeric présents dans des modules, si ceux-ci utilisent numeric.

Dans tout Dolibarr, c’est plus simple d’utiliser la valeur numeric.
Il faudrait d’ailleurs le préciser dans la documentation développeur.

  1. https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/install/mysql/tables/llx_accounting_fiscalyear.sql
    Il faudrait également prévoir un fichier llx_accounting_fiscalperiod.sql
    Relation 1=>N

Dans exercice comptable, il y a plusieurs périodes.
Certaines entreprises sont au trimestriel, d’autres en mensuel.

Par ailleurs, on peut parfois négocier une modification exceptionnelle de la durée fiscale, comme c’est le cas durant le premier exercice. En cas de difficulté, on peut négocier une modification des périodes en cours d’exercice. Par exemple commencer au mensuer, puis passer au trimestriel.

Il faudra simplement prévoir un petit script de création des périodes.
Ensuite, l’utilisateur pourra les modifier en base de données.
Inutile de tout coder en PHP, c’est plus paramétrable en base de données.

  1. Plus important : plan comptable
    https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/install/mysql/tables/llx_accounting_account.sql

Si on veut pouvoir faire des requêtes SQL imbriquées pour calculer la somme de comptes par jointures, il faut distinguer les comptes virtuels (génériques) des comptes personnalisés. Par exemple 401 et 410 sont des comptes virtuels. Au sein de chaque compte virtuel, on force la création de comptes personnalisés, comme pour les cas clients et fournisseur. Ou alors coder en PHP que lorsqu’un compte a un enfant, il doit être nul et ne peut contenir de valeurs. Mais ce sera plus compliqué à coder.

C’est important car on pourra ainsi calculer facilement et sans risque d’erreur la somme d’un compte de classe 4.

  1. Clôture des comptes
    Dupliquer le plan comptable en clôture, pour stockage.
    Le plan comptable est donc le plan comptable de l’année en cours.

Mais le cas se pose parfois de travailler sur l’année précédente, alors qu’elle n’est pas encore clôturée et sur l’année en cours. On doit donc stocker la référence de l’année fiscale dans le plan comptable. A la fermeture, on duplique le plan comptable et on le rouvre avec une nouvelle anneé. C’est un mécanisme beaucoup plus puissant. On pourra créer un index unique sur l’année, pour ne pas avoir de doublon.

  1. Indexes
    Il manque pas mal d’indexes de performance dans les tables, mais j’imagine que c’est normal car les développements sont récents.

J’ai proposé ces quelques modifications, car Tryton et Odoo fonctionnent ainsi. C’est essentiel si on veut pouvoir paramétrer des états SQL sans risque de se tromper dans les calculs. Concernant Odoo, on est d’accord que c’est commercial. Par contre, leur compta est très bien foutue. Les éditeurs conservent les états SQL et ne les diffusent pas. Mais on peut tout faire, jusqu’au bilan et compte de résultat, et j’aimerais bien que Dolibarr ait une structure de données aussi bien étudiée.

Que pensez-vous de mes suggestions ?

19

N’étant pas compétent en la matière je ne saurai me prononcer. Par contre ça fait plaisir si tu es partant pour mettre ta compétence et un peu de ton temps pour aider à faire évoluer le module.
A mon sens le module prend la bonne direction et il reste pas mal de choses à finaliser, toute proposition est bonne à prendre et je pense qu’il est important de raisonner à moyen et long terme aussi. Mais ne serait-ce pas une bonne idée que tu prennes contact avec Darkjeff, Aspangaro, Eldy, etc, afin de leur demander sur quels dossiers ils ont besoin d’avancer d’urgence actuellement et si tu pourrais te rendre utile. Je me mêle un peu de ce qui ne me regarde pas, mais bon. Je pense qu’un bon lieu pour les échanges techniques est probablement le github, sortant de l’ESSEC (j’habite pas loin) l’anglais ne doit pas être un trop gros frein pour toi.
Bref, je te renouvelle mon chaleureux bienvenu et si tu peux aider à faire avancer dolibarr plus vite c’est top.

20

Oui, il y a discussion sur Github, mais c’est patch en main. Là, il s’agit plutôt de discuter des grandes orientations. C’est pour cela que je parlais de mettre en place un groupe de compta élargi, pour discuter de la structure du module et partir sur de bonnes bases.

Ainsi, je me demande si FEC est un standard international. SI ce n’est pas le cas, il faut coder les informations FEC dans un fichier joint 1<->1. Car sinon pourquoi ne pas ajouter les formats anglais, allemand, américain chinois, etc …

Cela fait des années qu’on parle de compta et personnellement, j’attends toujours une structure de données SQL robuste et universelle. Tous les avis sont les bienvenus.

21

Bonjour,

Etant comptable et pas développeur de base, pour les recommandations sql, je vous laisse faire s’il y’a des choses a améliorer, moi ça marche, c’est le principal.

Déjà fait : https://github.com/Dolibarr/dolibarr/blob/develop/htdocs/install/mysql/tables/llx_accounting_fiscalyear.sql

Et pour le « script », il suffit d’aller dans le dossier accountancy/admin/fiscal_year.php
Ca existe depuis plusieurs versions mais c’est caché car inutile pour l’instant, ce n’est relié à aucun état, mais vraiment aucun, on vient de recommencer à coder pas plus tard que cette semaine dessus. Le but est de le remonter dans la configuration générale de Dolibarr quand ce sera prêt.

Je ne suis pas d’accord, les comptes 401 / 411 / 421 peuvent ne pas être des comptes auxiliaires comme ils peuvent l’être, il faut donc prévoir un choix dans la création des comptes et pourvoir rattaché un compte auxiliaire à un compte principal en fonction de son statut. Cela dépend aussi de la comptabilité nécessaire.

J’en parle ici, ça arrive aussi : https://github.com/Dolibarr/dolibarr/pull/6968

Pour l’instant, pas encore bosser concrètement sur le sujet, on se concentre sur les fonctions de bases plus haut pour l’instant, ça viendra en dernier.

A partir de la v5, il est possible de construire son compte de résultat en jouant avec la catégorie rattachée à un compte, c’est juste long à mettre en place car il n’y a pas de modèle officiel mais au moins, c’est international car on peut envisager toutes les situations possibles.

Pour le format FEC, il faut bien commencer quelque part, vu que la France est à la base de la comptabilité dite latine, on couvre déjà pas mal de monde, on verra pour la suite car le modèle anglais étant sur de la comptabilité dite d’engagement, cela nécessite des changements profonds dans le core de Dolibarr.

De manière plus générale, la réflexion à long terme du groupe actuel est là mais le développement est long et il faut le faire par petite touche pour que ce soit intégré. Je bosse sur Dolibarr depuis 2010 et avant de se pencher sur la compta, il a fallut faire évoluer le reste car nous sommes sur un ERP et le but étant de proposer une automatisation au maximum, nous sommes parti de la fin à savoir ajouter la comptabilité autour d’un système existant.

Libre à toit de contribuer en code maintenant ou en réflexion, tout est bienvenue mais il faut garder en tête que la cible principal reste les entrepreneur / PME, ne jamais dire le mot « comptabilité », c’est un gros mot :laugh:

22

@phil : oui le prochain resto c’est moi qui paye :tongue:

@fperou : tu as reçu l’email « Module Dolibarr Compta 2017 (22) »?? l’organisation fonctionne comme ça je récupère les retours et chaque semaine je fais un point au groupe

23

Bonjour,

Je suis utilisateur de Dolibarr depuis la version 3 et je suit cette discussion avec un grand intérêt.
Mon scenario est le suivant : je souhaiterai pouvoir découper la comptabilité par année afin d’utiliser pleinement le journal des a-nouveaux. En effet, je ne me vois pas ressaisir la totalité des relevées bancaire depuis le début de mon activité (2014) juste pour revenir à un encours bancaire qui reflète la réalité.

Concrètement, je voudrais :
- Oublier des journaux actuels les factures émises et reçus ainsi que les mouvements du compte bancaire effectuées avant 2017.
- Revenir à une situation correct avec les A-Nouveaux
- Créer un/des journaux supplémentaire pour mon usage personnel (en fait, inscription des corrections de mon expert comptable)
- Clôture/ouverture par années

Or, si je ne trompe pas, il n’est pas possible de faire cela.
Jusqu’à maintenant, je suis indécis quand à utiliser la comptabilité actuelle de la v5.0.
Pour ma part (et ceci n’engage que moi), il y a une petite marche à monter avant d’avoir une bonne comptabilité en double partie.

Mais c’est avec un grand plaisir que j’utilise Dolibarr au quotidien, bravo à tous les contributeurs !

[Edit]
Je remet une petite pièce…
Les règlements clients sont générés depuis les fiches factures (c’est super).
Par contre, lors de la saisie au kilomètre des écritures bancaires, il serai super de relier une écriture à un règlement d’une facture. Cela serait au top.

24

Sur les histoires des clotûres, une astuce c’est de fermer le compte bancaire et d’en réouvrir un autre…

Mon avis sur le sujet mais je ne vais pas m’y étendre :
- Il y a actuellement des choses bien plus importante à développer sur dolibarr qu’une compta, que personne n’attend ou n’a besoin. Maintenant si certains on envie de se faire plaisir et de partager ensuite ce développement avec la communauté why-not.
- Je n’apprécie pas vraiment l’attitude de venir expliquer que les développeurs de dolibarr sont des nuls, limite traiter darkjefff d’escrocs quand on sait son implication dans le projet, sans avoir claqué la moindre contribution. Le principe de l’open-source ce n’est pas d’être jugé sur ses diplômes ou son CV mais la qualité de ses contributions, ce que l’on apporte à la communauté. C’est comme cela et UNIQUEMENT ainsi que l’on obtient le respect de ses pairs.
- Ce n’est malheureusement pas la première fois que ce genre de situation arrive ici, généralement cela dure 1 ou 2 mois et puis … rien.

A titre d’info, je suis en train de m’organiser pour être disponible durant les grandes vacances pour participer au développement de la couche de sécurisation car il me semble que c’est un VRAI point stratégique pour l’avenir de dolibarr

1 « J'aime »
25

@Defrance

Je n’ai jamais écrit que Darkjeff était un escroc.

Malheureusement, j’ai mal interprété les paroles de Darkjeff, indiquant que Dolibarr ne serait jamais un logiciel de comptabilité et comme il est le leader du développement du module comptabilité, cela a provoqué certaines réactions. Il l’a même écrit en gras, pour bien signifier que c’était définitif.

Mais la controverse est close. La v6 permet de faire de la comptabilité et c’est une bonne base de développement.

Comme toi, je suis disponible pour de nouveaux développement et j’ai prévu de bosser sur la comptabilité durant toutes les vacances. J’ai trop souffert de logiciels de compta mal conçus. Rien qu’à l’époque OpenERP, j’ai passé des semaines entières à expliquer comment passer les écritures de TVA intracommunautaire ou encore comment solder les comptes de TVA en fin d’année, sans résultat. Si on m’explique à nouveau que Dolibarr n’est pas un logiciel de compta, je forke immédiatement et sans réfléchir. Par contre, si on me dit que c’est bien un logiciel de compta, j’y apporte mon temps et ma compétence, en collaboration avec tous.

On s’est parlé au téléphone aujourd’hui. Tu dis qu’il n’y a pas de marché. Moi je pense qu’il y a une compta par entreprise, donc que cela mérite qu’on sorte un logiciel complet et certifié.

Je cherche avant tout une base SQL bien conçue, qui permette de faire de la compta presque sans passer par PHP.

26

@aspangaro

Bonjour.

On s’est mal compris. L’année fiscale est bien gérée par Dolibarr et vous travaillez dessus. Pour ma part, je suggère de subdiviser l’année fiscale en périodes fiscales.

Dans un exercice, on peut avoir 12 périodes de 1 mois ou 4 périodes trimestrielles. Avec l’accord de l’administration fiscale, on peut également passer d’une déclaration trimestrielle à une déclaration mensuelle et vise versa. Certains exercices sont décalés et on peut être amené à les recadrer.

Chaque période fiscale correspond à une déclaration de TVA. L’avantage d’une telle structure est qu’on peut y ajouter par la suite un formulaire ou un module de déclaration de la TVA (dont je pourrais me charger).

Tu dis que tout est dans le fichier :

$sql = « SELECT f.rowid, f.label, f.date_start, f.date_end, f.statut, f.entity »;
$sql .= " FROM " . MAIN_DB_PREFIX . « accounting_fiscalyear as f »;
$sql .= " WHERE f.entity = " . $conf->entity;
$sql.=$db->order($sortfield,$sortorder);

Affiche uniquement une liste d’années fiscales.

Je propose de séparer l’année fiscale en autant de périodes que de déclarations de TVA.
On doit pouvoir choisir mensuel ou trimestriel ou faire un panaché des deux (en cas d’accord avec l’administration fiscale).

Ma démarche est mal comprise. Je veux simplement aider à mettre en place les fondements d’une comptabilité solide. Par exemple, avec la séparation d’un exercice comptable en périodes, on aura de bonnes bases pour gérer les déclarations de TVA.

Est-ce qu’on peut partir là dessus pour un premier développement ? Si vous êtes d’accord, cela pourrait être ma première contribution.

On est d’accord qu’il faut laisser le choix. Ce choix se reflète en base de données par la notion de compte virtuel. C’est la notion retenue par Odoo. Elle est assez contraignante, car quand 401 est un compte virtuel, on ne peut passer aucun transaction sur 401. Il faut impérativement créer un premier compte, par exemple 4010000001. Ensuite, on utilise soit ce seul compte 4010000001 ou l’on créé autant de comptes 40100000x que nécessaire. Dans une autre configuration, on bascule 401 en compte auxiliaire complet et dans ce cas, on passer tout sur 401.

Qu’est-ce que tu penses de l’approche d’Odoo ? J’avoue que mon avis est partagé, car on ne peut pas passer à la fois des transactions sur 401 et sur 40100000x. Quel est ton avis de professionnel ?

27

Oui, j’ai lu ton courriel avec attention. Je crois que tu passes beaucoup de temps à intégrer la compta v6 dans la v5. Est-ce qu’on ne devrait pas partir directement sur une v6 ?

28

Comme suggéré, j’ai déplacé les discussions vers Github pour définir les SPECs.
https://github.com/Dolibarr/dolibarr/issues/7015
https://github.com/Dolibarr/dolibarr/issues/7016

29

OUI, code et on en reparle après

30

On se met d’accord sur les SPECs et alors je code :

1 « J'aime »
31

Bonjour
J’adore ce topic :laugh:

32

Cher Darkjeff,

Est-ce que tu pourrais préciser la relation de ton module ventilation_compta avec la compta core de Dolibarr, nommée accountancy. J’ai regardé les tables et elles diffèrent de la version 6.0 de Dolibarr. Est-ce qu’on ne ferait pas mieux de se répartir le travail et de passer une série de petits patchs, en commençant par la structure comptable SQL, pour préparer une base solide à la comptabilité future.

Je me voyais travailler sur une 6.0 trunk et ensuite porter vers 5.0.

C’est d’ailleurs ce que j’ai proposé dans ma démarche :
(1) on repère tout ce qui ne va pas et on fait des specs.
(2) on développe pour 6.0 trunk en collaboration avec l’association.
(3) on porte vers 5.0x et on migre en douceur.

C’est peut-être parce que je suis nouveau, mais je ne pige pas du tout la logique du développement.
Surtout, j’aimerais que tous ceux qui ont une petite expérience sur des logiciels de compta tiers donnent des avis concernant les SPECS.
Sinon on risque de se retrouver avec un tas de choses non-conformes aux habitutes, comme stocker les exports dans la table principale des opérations comptables.

33

Dear fperou

le dépot « ventilation compta » c’est l’origine de la compta dans dolibarr,

la version 4 : correspond a un dolibarr 4 avec la compta d’un dolibarr 5 amélioré (
la version 5 : correspond a un dolibarr 5 avec la compta d’un dolibarr 6 amélioré

On travaille avec le groupe de compta avancée sur les améliorations dont le groupe a besoin et les correction des bugs que les
membres rencontrent

Alex fixe le cap sur comment on va faire comptablement parlant et code beaucoup et gère les commits de notre dépot sur le core

Moi je discute avec les users, je code (un peu), je test le code que l’on sous traite et je debug (c’est 60% du taff et des fois il y a des bugs vraiment pas évident a trouver, mais avec le nombre de base de donnée on a des trucs sympas)

eldy fixe le cap sur spécificité technique et si on intègre ou on corrige nos commits (c’est yoda et même si je suis un sith je m’incline devant yoda) :sunglasses:

Pourquoi une version en dessous : parce que la plupart des entreprises qui utilisent dolibarr sont passés cette année en doli 4 en production. Il y a une règle de base quand une version stable sort , on ne fonce pas mettre a jour, on attends mais on l’installe sur sa session test

Pourquoi prendre les nouveautés de la compta pour intégrer dans une version antérieur : parce que je me vois mal expliquer au groupe, on code les gars vous verrez le résultat dans 6 mois, ah et pour les corrections de bug et bien on verra après :whistle:

Si tu veux un truc pour commencer : les années fiscales (j’en ai principalement l’utilité pour modifier trois tableaux, mais c’est noté dans un des emails au groupe compta, donc tu as du le lire)
\accountancy\admin\fiscalyear.php
et la table
llx_accounting_fiscalyear

34

Bonsoir à tous,

Je pense que même si l’entrée en matière de fperou était un peu raide (voire fracassante ^^), il ne faut pas de notre côté nous montrer nous aussi raides avec lui. Je crois que chacun a pu constater qu’il y avait malentendu et j’espère que les discussions pourront continuer d’être constructives. En effet le temps qu’il a passé à publier des specs sur github montre clairement qu’on a pas affaire à un troll juste venu rigoler sur le forum. Merci bcp à toi de te proposer de coder dès que possible.

Fperou, tu parles à des personnes qui ont déjà craché des milliers de lignes de code pour dolibarr qui nous rendent à tous un très grand service, je peux comprendre qu’ils en aient déjà vu passer plein des gens qui leur expliquaient ce qu’ils devraient faire (dans mon domaine je m’en tape aussi, c’est vrai que c’est relou) et qu’ils préfèrent juger sur pièces. Néanmoins je pense qu’il est important pour qu’un projet puisse se développer de se montrer ouverts.

L’humilité est une grande qualité, mais nous savons tous que cette qualité est rare, ainsi il faut toujours essayer de tirer le meilleur de chacun, quelle que soit sa personnalité. fperou a l’air de s’y connaître (bcp plus que moi en tous cas !) et d’être de très bonne volonté, donc je je ne sais pas comment ça s’organise entre vous tous (et ça ne me regarde probablement pas) mais je pense que le travail de fperou mérite d’être étudié. Ou à défaut, de lui proposer des tâches à effectuer.

Si je prends mon cas personnel, je ne peux pas aider sur le code, mais je devrais probablement pouvoir aider dans d’autres domaines si ça se trouve (développement de la notoriété de dolibarr, réflexion générale sur le projet, etc), en effet en tant qu’utilisateur convaincu je pense pouvoir convaincre, et en parallèle je ne connais que trop bien les limites du moment que vous repoussez chaque jour. Dolibarr pourrait me rendre de plus grands services encore. Seulement j’ai lâchement préféré lâcher un gros billet pour le financement participatif plutôt que de m’impliquer.

Si je dis ça c’est pour rappeler que sur un forum, pour 100 lecteurs je ne sais même pas s’il y a 1 posteur, ensuite sur 100 posts… combien sont écrits par un codeur ? Dont acte. Le codeur est denrée rare dans une communauté, donc tant qu’on a pas affaire à un psychopathe (ce dont fperou semble très loin jusqu’à nouvel ordre ^^) j’aurai tendance à dire que quand quelqu’un a envie d’aider le projet (code ou autre) li est de notre devoir à tous de bien l’accueillir :happy:

Qu’on s’entende, je ne critique les posts de personne et les comprend tous, c’est justement ça que je souhaite mettre en avant.

Bonne soirée ou journée à tous :happy:

35

tout a fait d’accord avec toi

je l’ai même appelé cet après midi entre deux interventions et nous avons discuté

je n’ai pas répondu sur les SPEC, car je laisse alex et eldy se positionner sur ces sujets

et comme tu peux le voir dans mon post un peu plus haut j’ai laissé une porte ouverte sur les années fiscales ou je ne crache pas sur de l’aide ^^ (je suis en debug sur le lettrage actuellement et il y a encore pas mal a faire sur le journal de banque)

36

Vous faites un boulot formidable pour nous tous, encore merci :happy:

1 « J'aime »
37

@fperou

J’ai répondu à la première SPEC, je ne suis pas un génie en MYSQL mais ça me semble correct, j’ai proposé le premier patch pour la v7 concernant les type real, il faudra un 2ème patch pour les type double qui sont encore plus nombreux.

Je vais essayer de répondre sur le reste ce week end mais pas mal de taf’ :side: