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 ?
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.
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)
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
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
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
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.
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)
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’
@aspangaro
Tu peux indiquer l’URL de ta première réponse? Si tu utililes github, c’est ce qu’il y a de plus simple. C’est super qu’on puisse collaborer. Je sais que les ressources sont rares. Dans un précédent projet, le ratio était : 1 développeur, 500 testeurs, 100.000 utilisateurs. D’ailleurs, ce serait bien que vous puissiez inviter votre développeur sur le forum, car j’ai cru comprendre que vous ne développiez pas vous-même.
Concernant les SPECs émises sur Github, n’hésite pas à en émettre s’il s’agit d’une fonctionnalité du coeur comptable. Je propose que les SPECs ne soient jamais définitives. A tout moment, tu peux intervenir dans le fil pour dire « Okay je suis d’accord » ou « Pas d’accord pour telles raisons » ou tout message, par exemple « sans avis, je n’y vois aucun inconvénient ». Dans ce cas, on se met d’accord pour modifier la SPEC ou l’annuler tout simplement.
La SPEC doit rester simpe : un titre, le fonctionnement actuel, le fonctionnement prévu. On n’a pas besoin de rentrer dans le détail de la programmation. D’autant que c’est de la compta.
Dès que la SPEC est émise, personnellement je n’ai aucun état d’âme à la suivre pour faire des développements. Cela évite de pédaler dans le vide et de présenter un commit, auquel on répond : « pas besoin, on va faire autrement ».
Dès que tu auras répondu à la SPEC sur les périodes comptables, je pourrai me mettre au travail sur cette fonctionnalité précise de périodes comptables.
A tous ceux qui ont déjà collaboré à un logiciel comptable, lâchez-vous sur les SPECs, on gagnera du temps.
Et bien en ce qui me concerne j’attends avec impatience une compta digne de ce nom dans Dolibarr qui me permettrait de me libérer de mon Ciel Compta qui m’oblige à garder encore un poste sous windows.
Bravo et merci à tous les développeurs qui participent à ce projet, j’espère que vous saurez unir vos compétences pour faire de Dolibarr et outil toujours et encore plus performant
C’est simple : c’est sur le github (Je ne travaille qu’avec ça sur le projet Dolibarr ) C’est par ici
Pour suivre le projet, Olivier et moi suffiront, pas besoin d’inviter Jamal pour le moment. On soustraite quand on a besoin, en général de janvier à mai, c’est cuit pour moi.
Pour les SPEC, mes réponses viendront durant le week end normalement. Laurent (aka @eldy) est ok avec la première SPEC ci-dessus, il l’a d’ailleurs validé sur la v6 sans faire exprès alors que la base de données est clause pour la v6. Il vient d’annuler le PR mais le publiera dès que la branche v7 sera ouverte.
Juste faire attention sur un point, Dolibarr est un ERP. Une de ces forces est d’être adaptable et simple d’utilisation, il faut rester dans cette philosophie donc il faut parfois réfléchir pour intégrer une fonction différemment que comme on pourrait le voir sur les logiciels comptables destinés à des comptables. C’est pour ça qu’on fait l’impasse sur certain terme avec Olivier et c’est pour ça qu’on parle de pré-compta et pas de logiciel de comptabilité (Même si nous sommes de plus en plus complet) car le but reste toujours de transmettre les infos à un Expert Comptable. Je sais que c’est réducteur mais c’est l’utilisateur avant tout, pas le comptable…
Oui, oui, oui, cela avance.
Merci pour le numeric.
Concernant le comptable … et l’intérêt de la comptabilité …
Quand tout est bien développé, la comptabilité s’écrit automatiquement.
En tout cas, c’est mon objectif. C’est cela un ERP.
Quand on aura fini tous les développements, il n’y aura plus aucun ligne de compta à passer, cela se fera automatiquement.
sur ça j’ai un doute, surtout après être passé sur une bonne centaine de base de donnée dolibarr
si on a créé la ventilation semi automatique c’est pas pour rien
* les libellés libres : et que le premier qui n’a pas créé vite fait une facture en mettant juste du libellé libre me jette la première pierre
* les cas particulier : ventes UE, hors UE, etc etc ou l’achat qui change des habitudes, j’ai acheté l’année dernière des ordi portable, je me suis dit ah ils sont pas mal, je vais en prendre un pour moi, donc pas du 607 mais du 6063, mais voilà le prix dépasse les 500 donc amortissement donc compte de classe 2
* je vends un service de juin 2016 a juin 2017 mais mon année fiscale est de janvier 2016 a décembre 2016, et donc provision
etc etc etc
par contre je suis d’accord quand tout sera bien codé la compta sera faite a 80 %
Sinon ça avance sur la saisie au km et le compte de résultat paramétrable en fonction de la période fiscale (mais il reste encore du travail ^^)
Et on a jolie bug sur le journal de banque nouvelle version et je trouvvveeeee pas
Il faudrait pouvoir prendre en compte les provisions quand une facture client/fournisseur intègre des services avec des dates à cheval sur x exercices comptables. J’ai des trucs sur 1 an, 3 et 5 ans ! Je dois pas être le seul.
Pas vérifié sur une v6 si on peut saisir des dates sur des factures fournisseurs !
@+
)
