Discussion comptabilité d'entreprise

Bonjour à tous,

Mon nom est Jean-Michel Pouré. Développeur indépendant, membre de l’April, ancien responsable associatif, diplômé de l’Essec et fan de logiciels de comptabilité libre, je propose la création d’un groupe de réflexion autour de la comptabilité dans Dolibarr.

Il s’agit d’une initiative personnelle, non-officielle, sans liaison avec l’association Dolibarr, menée dans l’esprit du libre.

Pourquoi ?

Le développeur du module « Comptabilité avancée » a confirmé que Dolibarr ne serait jamais un logiciel de comptabilité et qu’il ne souhaitait pas éditer une liasse fiscale. Le module de comptabilité existant est destiné à faciliter l’exportation d’écritures comptables. La structure comptable de Dolibarr est héritée d’une structure de base de données de gestion commerciale et elle est devenue difficile, voire impossible, à développer. C’est un développement intéressant, qui a ouvert Dolibarr sur la comptabilité, mais qui ne sera plus jamais activement développé. Avec l’arrivée de lois très restrictives, le module de comptabilité est devenu un boulet pour Dolibarr.

Lire : Loi de finance 2016 & certification caisse

ou encore :

La proposition :

Je propose de réécrire un nouveau module comptable, en faisant table rase de l’ancien. J’ai conscience qu’il s’agit du troisième projet comptable dans Dolibarr. Le titre du message indique « fork », mais il s’agit plutôt d’une réécriture complète.

La démarche proposée :
* Réunir les bonnes volontés intéressés par le développement d’un module de comptabilité.
* Répondre à tous les besoins comptables, depuis l’ouverture des journaux jusqu’à la clôture et l’édition de la liasse fiscale.
* Concevoir un système comptable complet et indépendant, sans impact sur Dolibarr. Chaque module aura le choix d’utiliser ou non le nouveau système comptable.
* En trois phases : analyse de l’existant (Dolibarr, comparaison Tryton+Odoo), développement, migration de l’ancien système.

Il y aura éventuellement une levée de fonds (sans rapport avec d’autres levées de fond effectuées pour l’ancien module).

L’objectif est de bâtir un système comptable indépendant, qui puisse être archivé et utilisé plus tard comme preuve ou permettre très simplement des imports/exports ou encore éditer une liasse fiscale. Tout ceci nécessite une base comptable forte. L’analyse du code existant a confirmé que Dolibarr ne pouvait pas être utilisé comme seul logiciel de comptabilité.

Le nouveau module est un système comptable complet, où chaque pièce comptable génère des écritures équilibrées. Il sera conçu dès le départ avec un système de transactions Crédit/Débit permettant de rejouer les logs. Accoudé à un système de backlog, il devra permettre une certification par des tiers ou des hébergeurs.

Si vous êtes intéressés par ce projet, merci de m’indiquer vos attentes. Je préciserai les miennes prochainement. Je lance donc la première phase du projet, visant à analyser l’existant dans Dolibarr et définir des specs … Ensuite, je passerai au développement.

Cordialement,
Jean-Michel Pouré

Je liste ici les fonctionnalités standard que nous allons développer.
Comme vous pouvez le constater, ces fonctionnalités sont nouvelles et aucune n’est présente dans Dolibarr :

* Ecritures comptables : une écriture en débit ou en crédit, inscrite dans un journal.
* Devise : chaque journal peut avoir une devise.
* Pièces comptables : plusieurs écritures comptables équilibrées, dans une même devise. Une pièce comptable peut-être attachée à une facture Dilibarr.
* Modèles d’écritures comptables : une série d’écritures comptables. Exemple : enregistrer une facture, un impôt, etc …
* Achat, vente. Avoir d’achat, de vente.
* Contre-écritures (pour éviter la suppression ou la modification de factures).
* Journaux : une liste d’écriture comptable. Les principaux : ouverture, clôture, banque, caisse, achat, ventes, opérations diverses.
* Paiement client/fournisseur.
* Gestion des écarts de règlement.
* Rapprochement comptable et lettrage. Solder un jeu d’écritures présentes dans deux journaux différents.
* Plan comptable. Dupliqué en début d’année et archivé en fin d’année.
* Méta langage permettant de réaliser des opérations comptables.
* API simple et claire.
* Log anonymisé des opérations comptables.
* Signature électronique des transactions.
* Export FEC

Fonctionnalités additionnelles non-supportées au départ (car basées sur une compta standard):
* Immobilisations
* Paie

Vous pouvez me faire vos suggestions en réponse et je mettrai à jour cette page.

Bonsoir,

Ça tombe bien je suis moi aussi « fan de comptabilité », étant chef de mission en cabinet d’Expertise, c’est normal :laugh:

A part le « métalangage », que fera votre module en plus ? Je précise que la saisie kilomètre, le FEC et les modèles d’écritures sont en cours. Cela arrivera dans la v6 ou la v7.

Je vous remercie au passage de nous dire que notre travail n’est pas adapté. Si vous avez les connaissances comptable nécessaires, tout est faisable avec Dolibarr en v5. Il manque juste la liasse et je vous souhaite bon courage sur ce point. Isolé dans son coin pour faire un suivi rapide des différentes liasses annuelles en EDI dont les spécifications sortes fin d’année pour envoyer aux impôts au mois d’avril. En plus, gérer les demandes des autres pays pour adapter la comptabilité latine à leur besoin tout en restant simple… un seul mot : espoir !

Sinon y’a l’arlesienne module de paie aussi.

Sincèrement, pourquoi ne pas nous rejoindre , discuter sur le projet compta globalement et trouver une voie d’entente. Sur Dolibarr, il faut mieux ne pas bosser dans son coin, conseil d’amis.

2 « J'aime »

J’ai lu le code source de la comptabilité Dolibarr et je pense que ce n’est pas une réelle comptabilité, mais simplement un ensemble de requêtes SQL sur des tables Facture client / fournisseur, qui rendra très difficile le développement d’une réelle comptabilité.

D’ailleurs, c’est bien l’avis de darkjeff, dont j’ai cité certains passages : il n’y aura jamais de réel développement comptable dans Dolibarr, qui se cantonnera pour toujours à l’export de données vers un logiciel tiers, certifié. Pourquoi le nier ?

aspangaro, as-tu lu les sources du module comptabilité de Dolibarr? On ne pourra jamais certifier une telle comptabilité, car elle ne constitue pas une comptabilité complète, standard, basée sur des journaux.

Maintenant, je comprends que ma démarche puisse étonner, vu qu’une levée de fonds vient juste de se terminer …

Si vous souhaitez rejoindre le projet, vous êtes les bienvenus et vos financements aussi.

je mets mon grain de sel car je suis je crois à l’origine du tout premier module de compta pour dolibarr et ai participé un tout petit peu au projet de Jeff.
Le problème principale de la compta, outre les diverses certifications nécessaires pour être utilisables autrement qu’en tant que joujou, reste que les règles légales changent sans arrêt et qu’il faut sans cesse retourner coder ce qu’on avait écrit l’année d’avant; j’en sais vraiment quelque chose, l’ayant fait pendant 25 ans chez Franza Informatique, Prisme, Lefebvre puis Talentia (logiciels FICOMPTA 38, Belledonne, Alix).
Je vous souhaite donc bon courage si vous croyez en l’utilité de votre projet, car c’est bien de ça dont il s’agit, l’utilité !

1 « J'aime »

C’est vrai que j’ai été un peu dur concernant la comptabilité actuelle. N’y voyez pas une attaque ou une critique. Mais quand un logiciel est mal conçu, si on continue sur la même voix, c’est le crash assuré et surtout une montagne de travail.

Vous avez lu le code source de Dolibarr. Il y a des parties super-bien écrites, mais tout ce qui se nomme « comptabilité » est plutôt un module d’export et rien d’autre.

@aspangaro

En tant que chef de mission en cabinet d’Expertise, quelles sont les fonctionnalités de Dolibarr qui te permettraient d’utiliser Dolibarr comme SEUL LOGICIEL de comptabilité ? Pour sûr, on peut collaborer et je l’attends avec impatience, mais pas sur la structure comptable actuelle, qu’on peut jeter à la poubelle.

@altatof

L’argument d’utilité est intéressant. J’ai téléphoné à un développeur reconnu de la communauté Dolibarr, qui m’a tenu le même discours.

Concernant les règles comptables, il me semble qu’on peut paramétrer le logiciel d’une année à l’autre. Non ? Avec Odoo ou Tryton, on peut faire n’importe quel bilan et sortir les états comptables. Mais pas avec Dilibarr.

La structure comptable de Tryton est hyper-simple. Une fois traduire dans Dolibarr, on aura une base solide. Non ?

altatof, je ne vise pas les immobilisation ou la paie, seulement une structure comptable forte et bien conçue.

Vous pourrez m’aider tous les deux pour les specs? Au départ, je ferai une analyse fonctionnelle et la structure de base de données dans PostgreSQL. Vous pourrez faire des suggestions compte-tenu de votre compétence ?

Avec un petit meta-langage, on pourra se passer d’une interface pour tester les premières fonctionnalités. Une méthode Agile …

Edit : oula, vous répondez tous trop vite…

Bonjour,

N’étant pas codeur je vais juste donner mon point de vue d’utilisateur et de lecteur assidu de ce forum depuis un peu moins d’un an seulement.

Il y a quelques mois, après une introduction un peu hasardeuse puisque la personne était venue poster juste pour expliquer à quel point le code de dolibarr était sale et inadapté, quelqu’un qui s’annonçait comme un pro du codage nous promettait monts et merveilles et s’est vu réserver un bon accueil de la communauté dolibarr.
Depuis, rien.
C’est même à se demander si ce n’est pas quelqu’un qui prenait juste un malin plaisir à faire perdre leur temps aux gens qui tentaient de lui répondre de manière constructive.

Le débat et les sujets soulevés dans le post qui a initié celui que vous venez d’ouvrir sont très intéressants, il y a énormément à dire sur la question. Donc j’espère que nous avons bien affaire à une « vraie » personne qui a réellement envie de s’impliquer dans l’évolution du code de dolibarr. Je vais donc partir de ce postulat que vous êtes bien qui vous dites être.

Je commencerai donc par un bienvenu chaleureux et sincère.

Passionné de logiciel libre depuis près de vingt ans je pense moi aussi savoir un peu de quoi je parle, même si je n’ai probablement pas vos connaissances en code et en compta.
Forker un projet, ce n’est pas une chose qui se fait sur un coup de tête, bien au contraire. Excusez-moi par avance, je ne suis pas dans le jugement du tout, l’arrivée d’un vrai codeur dans une si petite communauté est forcément vue d’un très bon œil de mon côté, mais ne trouvez vous pas un peu précipité (en tous cas radical) suite à une simple discussion de vouloir forker un projet en vous basant juste sur quelques réponses d’une personne ? Quand bien même cette personne serait une personne importante dans l’évolution du code qui vous intéresse. Si vous connaissez bien le logiciel libre vous devez savoir que les choses ne sont jamais figées et qu’il est toujours possible de faire bouger les lignes, le fork a toujours été l’ultime recours en cas de vrais désaccords insolubles (ou quand Oracle rachète Sun par exemple).
Le travail mené sur le module compta, même s’il est forcément perfectible, a été considérable, donc pour le moment, en tant qu’utilisateur je préfère de loin me fixer à la bonne vieille devise « un tiens vaut mieux que deux tu l’auras ».

Je pourrai développer longuement les points sur lesquels vous avez probablement raison, mais je pourrai développer tout autant sur les points où je pense que vous vous fourvoyez à mon avis en voulant faire un fork. Je terminerai sur une autre devise, qui revient à la conclusion d’Aspangaro sur le précédent post, l’union fait la force.
Si vous vous y connaissez en compta et en code, vous pourriez probablement être d’une très grande utilité pour continuer de faire avancer le module compta avancée actuel. En effet de mon point de vue il reste encore beaucoup de travail à faire mais on voit nettement les évolutions et je suis convaincu qu’il y a moyen d’amener le module où vous le souhaitez (entre autres) plus facilement ainsi qu’en repartant from scratch. Après je n’en sais rien, vous êtes peut-être un génie hyperactif qui va coder nuit et jour (ce qui implique de n’avoir pas de travail) pendant quelques semaines auquel cas je me prosternerai avec joie.

Ne trouveriez vous pas plus pertinent de vous laisser temps de discuter, d’analyser plus le code, de faire des propositions, etc, avant de nous proposer de vous soutenir dans une réécriture de module alors que nous ne vous connaissons pas.

Pour conclure, Darkjeff, je pense qu’il ne faut jamais dire « jamais », ne serait-ce que pour ménager les susceptibilités ^^ Mais surtout parce qu’on ne sait jamais de quoi demain sera fait. Mais surtout il me semble important de pouvoir entendre que certains aient envie de pouvoir tenir une vraie compta dans dolibarr. Si on prend mon exemple, même si j’avais un dolibarr méga opérationnel et faisant carrément jusqu’à l’analytique les immos, etc, il va de soi pour moi (et pour presque tout le monde à mon avis) que je continuerais de faire appel à un expert comptable, par contre ça m’arrangerait sacrément dans mes relations avec l’EC qui ne sont pas simples pour le moment. Bref, ça nécessiterait plus de temps juste à réfléchir et poser les problématiques et points de vue de chacun mais moi du moment que je vois que les choses avancent, que les personnes sont de bonne volonté, je suis déjà super content, et c’est le cas.

Sur ce je nous souhaite à tous une bonne soirée !

2 « J'aime »

Bon je me permets d’intervenir.
Ch’ti développeur et intégrateur erp et compta depuis maintenant​ 25 ans (putain on rajeunit pas !) je ne comprend pas votre position. Faire un fork comme ça tout seul est un doux rêve. Les logiciels de comptabilité comme de grh nécessitent beaucoup de maintenance suite à évolution sans cesse de la réglementation. Si on y ajoute une notion internationale, là ça devient du délire ! N’oubliez pas que Dolibarr est international. La simple gestion de la TVA est déjà une aventure.
Pourquoi ne pas dans un premier temps améliorer les fonctions de base de Dolibarr pour ensuite dire OK maintenant on s’attaque à une vraie compta ? Pas le tout de faire une annonce si de toute façon le cas n’est pas traité.
Enfin, le module risque de coûter cher pour un résultat attendu qui sera moyen. Avez vous juste listé les différents régimes et les différentes options de TVA en France ? Commencez par là. Libéral, AE, Bic,BNC chacun a un état de bilan différent. Maintenant on y ajoute juste la couche TVA… Exonéré, réel (2 options voir plus)… J’oublie sûrement des trucs mais le but n’est pas d’être précis.

Si vous avez des compétences amenez les ! Aidez nous à faire avancer le chmilblick.

@ vous lire

Ces posts sont intéressants, je vais essayer d’y répondre :

@Fif00 : Oui, l’union fait la force. Mais si tu lis le fil concernant la nouvelle réglementation, tu verras que les développeurs, après avoir fait une levée de fonds, ont abandonné l’idée d’un véritable logiciel de comptabilité. Les fonctionnalités de compta avancée sont en fait une surcouche liée à un logiciel de gestion commerciale. Il n’existe pas de table réellement indépendante, seulement des jointures.

Exemple, le journal d’achats :

Cette requête SQL construit le journal :

$sql = "SELECT f.rowid, f.ref, f.type, f.datef as df, f.libelle,f.ref_supplier,";
$sql .= " fd.rowid as fdid, fd.description, fd.total_ttc, fd.tva_tx, fd.total_ht, fd.tva as total_tva, fd.product_type,";
$sql .= " s.rowid as socid, s.nom as name, s.fournisseur, s.code_client, s.code_fournisseur, s.code_compta, s.code_compta_fournisseur,";
$sql .= " p.accountancy_code_buy , ct.accountancy_code_buy as account_tva, aa.rowid as fk_compte, aa.account_number as compte, aa.label as label_compte";
$sql .= " FROM " . MAIN_DB_PREFIX . "facture_fourn_det as fd";
$sql .= " LEFT JOIN " . MAIN_DB_PREFIX . "c_tva as ct ON fd.tva_tx = ct.taux AND ct.fk_pays = '" . $idpays . "'";
$sql .= " LEFT JOIN " . MAIN_DB_PREFIX . "product as p ON p.rowid = fd.fk_product";
$sql .= " LEFT JOIN " . MAIN_DB_PREFIX . "accounting_account as aa ON aa.rowid = fd.fk_code_ventilation";
$sql .= " JOIN " . MAIN_DB_PREFIX . "facture_fourn as f ON f.rowid = fd.fk_facture_fourn";
$sql .= " JOIN " . MAIN_DB_PREFIX . "societe as s ON s.rowid = f.fk_soc";
$sql .= " WHERE f.fk_statut > 0 ";
$sql .= " AND fd.fk_code_ventilation > 0 ";
$sql .= " AND f.entity IN (" . getEntity('facture_fourn', 0) . ")";  // We don't share object for accountancy
if (! empty($conf->global->FACTURE_DEPOSITS_ARE_JUST_PAYMENTS))
	$sql .= " AND f.type IN (0,1,2)";
else
	$sql .= " AND f.type IN (0,1,2,3)";
if ($date_start && $date_end)
	$sql .= " AND f.datef >= '" . $db->idate($date_start) . "' AND f.datef <= '" . $db->idate($date_end) . "'";
$sql .= " ORDER BY f.datef";

Le journal remplit la table llx_accounting_bookkeeping :

La table est mieux conçue que dans la version 5.0, mais on voit clairement que c’est un simple export … Pas un logiciel de comptabilité en partie double.

@philazerty

La gestion de la TVA s’effectue par mouvements de comptes. Pareil pour la TVA intra-communautaire. Même pour solder la compta en fin d’exercice, on se base sur des comptes. Tout cela peut se paramétrer dans un micro-language ou même en utilisant des requêtes SQL. Mais encore faut-il que la base de données soit bien conçue …

Ceci dit, mon analyse repose sur la v5 et l’indication des développeurs que Dolibarr ne serait jamais un logiciel de compta. Je vois les champs lettrage et journaux. On doit pouvoir faire quelque chose, je reviens vers vous.

En tout cas, si les développeurs principaux ne veulent faire de Dolibarr un logiciel de comptabilité, on sera obligé de forker. Quelle autre solution voyez-vous si c’est bloqué ?

je m’étais dit que j’allais pas répondre :woohoo:
mais comme disait Prévert « Je suis comme je suis, je plais a qui je plais »

Je ne me suis pas réveillé un matin en allant poster sur le forum de dolibarr, pour dire, j’ai une super idée on va coder un module compta

En tant que chef d’entreprise, un jour je me suis dit c’est dommage de ressaisir les données des factures et donc je vais me faire coder un module (je ne savais pas coder à l’époque). Et donc j’ai travaillé avec pleins de prestataires dolibarr (une grosse pensée a vous tous, car ce sont des gens formidables)

Quand le module m’a permis d’exporter mon journal de vente, puis mon journal d’achat, j’ai décidé d’offrir ce module (que ma société avait financée) à la communauté et c’est comme ça que j’ai rencontré Alexandre (Mon binôme en code et maintenant mon EC)

On a continué a le faire évoluer un peu chaque année et lorsque celui ci a été intégré au core de dolibarr on a lancé deux financements participatifs afin de réunir des utilisateurs du module, partager nos besoins, nous entraider et financer l’évolution du module

Cette année c’est une immense réussite, une centaine d’entreprise et une cagnotte pour le développement de pratiquement 10 000 € HT. (jeffinfo va augmenter sa participation pour atteindre ce montant ^^)

De nombreux codeurs participent a ce projet et nous font un tarif « amis » concernant leur prestation, voir le font gratuitement

Alexandre et moi consacrons un temps non négligeable sur ce projet et ceci bénévolement et sur notre temps libre (alexandre travaille dans un grand cabinet comptable, et moi en plus de ma société j’ai des activités immo et financières a gérer)

Comme dit plus haut, nous ne refusons aucune aide ou partie de code, mais quand on me dit il faut tout réécrire, tout refaire… et bien c’est plus que du courage que je souhaite. Et surtout préparez vous a répondre aux centaines d’emails pour le support

En outre pour motiver les utilisateurs de Dolibarr, il faut être impliqué dans la communauté un peu plus longtemps qu’une semaine ou deux (ça fait un peu plus de 10 ans pour moi). Car comme disait un célèbre navigateur « la confiance est un élément majeur sans elle aucun projet n’aboutit » :wink:

1 « J'aime »

(Re)salut darkjeff.

On est d’accord que la comptabilité avancée est un immense succès, mais la problématique, c’est d’abord de faire le point sur tes affirmations et la manière dont tu gères le projet compta. As-tu encore envie de développer la compta, d’y ajouter les fonctionnalités complètes d’un logiciel de compta.

Est-ce que tu confirmes que Dolibarr n’offrira jamais une comptabilité complète, ni le support des journaux, ni le lettrage - qui sont les fondements de la comptabilité ? Pour moi, tu pourrais avoir parlé trop rapidement.

Parce que c’est bien le fond de la question.

En fait, tout dépend de ta réponse. De mon côté, je regarde à nouveau la version développement de Dolibarr. La version 6 transforme considérablement la version 5.

Journaux, grand livre, saisie d’écritures au km, lettrage, mutli journaux tout ça est prévu ou déjà fait

la seule chose ou je ne veux pas m’aventurer c’est la sortie des liasses fiscales et les fiches de payes car je n’en vois pas l’utilité et ce sont des domaines beaucoup trop complexes et réglementés

ps : tu n’étais pas encore dans la liste email ce lundi, je t’ai transféré le dernier email au groupe compta avancée

OK.

Désolé, je m’étais basé sur ton affirmation :

Avoue que c’est quand même un peu « space » quand on vient toucher 10.000€.
J’ai utilisé durant 5 ans Odoo, et j’avoue que cela m’a fait sauter au plafond de lire tes affirmations.

Je pense que tu te trompes ou bien tu as parlé un peu trop rapidement.
Dolibarr peut être utilisé comme seul logiciel de comptabilité.
La comptabilité est le coeur du système informatique, tout se greffe autour …
Mais il y a du travail …

Par exemple, les liasses fiscales, quand la base de données est bien conçue, c’'est simplement un ensemble de requêtes SQL. Si l’édideur de PDF permet de lancer des requêtes SQL, on peut en remplir une grande partie. Il faut écrire « Document de travail » pour des questions légales, avec une page de garde.

Idem, pour la TVA française et la TVA intracommunautaire. Il faut utiliser une plan comptable bien configuré, et c’est un ensemble de requêtes SQL.

Je suis en train d’analyser la v6. C’est beaucoup mieux et il n’y a probablement aucune raison de forker.

Mais comment darkjeff peut-il répondre à une telle question ? Dolibarr est un logiciel libre construit par une communauté. La réponse que peut faire darkjeff ne peut que le concerner lui et le périmètre sur lequel il entend contribuer pour le module compta avancé. L’avenir de Dolibarr sera ce que ses utilisateurs en feront, pas darkjeff (avec tout le respect que je lui doit pour le travail effectué !).

Si tu décides de développer ET de maintenir une « vrai » comptabilité pour Dolibarr en réunissant un groupe d’utilisateur et de contributeur, fonces. C’est toi qui a la réponse à la question. Si tu penses qu’il vaut mieux refaire, vas-y aussi même si je trouve cela toujours dommage de faire et refaire.

Ton projet pose à mon sens d’abord un problème de modèle économique pour le faire vivre dans la durée. Maintenir des logiciels à forte contrainte réglementaire (compta, paie et d’autres…) demande des revenus récurrents qu’il n’est pas aisé à rassembler.

1 « J'aime »

Ayant donné depuis deux ans au financement participatif, je n’ai jamais compris qu’il était question de faire une vrai compta…
Heu Oddo dans tout ça :slight_smile: ?

1 « J'aime »

J’essaye de gérer le projet compta comme je gère d’autres projets en tant que DSI (j’ai ma façon de gérer et je ne pense pas que ça déplaise aux membres du groupe, enfin en tous cas d’après les nombreux retours que j’ai, mais si je me trompe, ne pas hésiter a me le dire, je suis ouvert aux critiques)

Je ne parlerai même pas d’odoo, que je connais plus que bien pour avoir suivi leur formation avancée en belgique pour un de mes clients. Ce n’est pas de l’open source mais du commercial source. Et la compta (comme le reste) dans odoo c’est une vaste blague

Je n’ai jamais eu la prétention de fabriquer le futur sage ou cegid. Pourtant crois moi je connais extrêmement bien le sujet.

Tout ce que je veux pour la communauté dolibarr c’est quelque chose qui nous permettent d’avoir de véritable tableaux de bord afin de piloter son activité et un export des écritures que tout expert comptable de France ou de Navarre puissent importer.

Quand au 10 000 € ce n’est pas de l’argent qui part dans ma poche, cela me sert a rémunérer tous ceux qui interviennent sur le projet, mais je suis assez transparent sur les coûts, il y a bien sûr une part de cet argent dans la gestion du projet mais comme les codeurs qui interviennent je fais un prix « amis » très loin de mes tarifs habituels

@jeff
Et en plus c’est moi qui ai payé le resto la fois dernière.
:tongue:
Si j’avais su !!!

1 « J'aime »

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 ?

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.

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.