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.
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.
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
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 »
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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
@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
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.
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
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.
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 ?
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 ?
?
