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 ?
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…
)
