Module Ventilation Comptable

Comme le sujet « module Compta » comporte pas mal de pages, j’ouvre donc un nouveau topic pour le module « Ventilation Comptable » c’est donc la suite de :
www.dolibarr.fr/forum/t/module-compta-pour-dolibarr/6727/1

J’ai eu pas mal de demandes et donc ce sujet servira pour parler des ajouts de fonctionnalité.

On pourra aussi discuter des différents logiciels de compta vers lesquelles on souhaite exporter les données et aussi trouver un moyen de mutualiser les journées de codage.

Le prix du module a été fixé a 120 € HT : l’achat correspond a une participation à l’écriture du module ainsi qu’a son amélioration. Il permet également d’être destinataire des mises a jour. (si intéressé un mail a [email protected])

le manuel : http://www.jeffinfo.com/ventilation-comptable-dans-dolibarr/

le prochain journal sera le journal de banque, ce dev étant payé par ma société (surement courant mars, je laisse christophe un peu respiré ^^)

Logiciel comptable pour l’instant ou j’ai eu des demandes : on est en train de réfléchir a mettre une partie configuration afin de garder un seul bouton export et de pouvoir choisir le logiciel comptable correspondant à l’export

pour l’instant on a :
* date : jj/mm/aaaa
* libellé mouvement (actuellement le n° de facture)
* compte
* debit
* credit
ce qui suffit a mon expert comptable (logiciel Cador de Suite Expert)

si on veut rajouter

Sage : (j’ai déjà importé mes données dolibarr dans Sage, mais c’est long surtout qu’a l’époque je retravaillais tout sous excel)
* rajouter variable journal (3 lettres)
* changer le format de date en jjmmaa
* rajouter variable « OD »
* Compte
- forcer l’écriture des comptes a 13 caractères ou aligner a gauche
- ne pas utiliser les comptes tiers mais des 401 ou 411
* Compte tiers
- rajouter variable X devant chaque compte tier
* Référence : on pourra utiliser le n° de la facture
* libellé : on pourra utiliser la description des comptes comptables ou le nom du client/fournisseur
* Type de paiement : Ajouter Variable « S »
* Echéance : possibilité de reprendre date d’échéance ou laisser date de facture
* Sens : Si débit D / Si crédit C
* Montant : il faudra regrouper débit et credit dans la même colonne
* fin de mouvement : a chaque fin de mouvement sur la dernière ligne il faudra rajouter une variable « N »

Si d’autres logiciels, je pense par exemple a EBP, Cegid peut être Koala
il faudra regarder en détail la procédure d’import pour chaque logiciel comptable.

On remarquera que plus le logiciel comptable est cher plus l’import est facile :wink:

1 « J'aime »

Bonjour,

Je reviens sur les exports à réalisé sur les différents logiciels :

Pourquoi ne pas tout simplement faire un export modulable en fonction du souhait de l’utilisateur et une possibilité de sauvegarder sa configuration pour une autre fois en spécifiant une date de début et de fin de période et le journal souhaité pour l’export d’écritures et ensuite sélectionner les champs dans l’ordre qu’on souhaite comme le propose l’assistant d’export de Dolibarr ? Comme ça, on évite de réalisé une dizaine de type d’export qui vont être désué au fil des versions des logiciels comptable sur le marché.

Aussi, il faut prévoir dans les exports, une balance général avec pour chaque compte utilisé, la somme des débits et crédits sur le compte et son solde (débiteur ou créditeur), comme ceci :

N° Compte
Libellé compte
Somme Débit
Somme Crédit
Solde Débiteur (Si Somme Débit > Somme Crédit)
Solde Créditeur (Si Somme Débit < Somme Crédit)

De plus, il faut aussi prévoir la possibilité d’interroger les comptes pour avoir une historique des mouvements sur chaque compte de cette façon :

N° Compte - Libellé
Date
Journal (Ach, Vte, Bqe, …)
N° écriture
Libellé écriture
Débit
Crédit
Pointé (O/N) lorsqu’on fait le rapprochement bancaire (Uniquement pour les comptes tiers)
Lettré (O/N) Lorsqu’on fait le solde (lien entre un paiement et une facture)

Merci encore pour ce futur module.

Cdt

On est parti sur un export modulable, mais certains logiciels ont des particularités (cf l’explication sur Sage qui demande de retravailler les données, comme ajouté un X devant les comptes tiers, ou mixer les débit et les crédit dans une colonne, etc etc), donc un export brut des données de dolibarr ne fonctionnera pas.

Chaque logiciel comptable a sa stratégie d’import, mais il n’y a que trois ou quatre grands logiciels que tout le monde utilise

la famille sage : ciel / Sage / Koala (celui la aussi plus pour les commissaire au compte)
Cegid
EBP

A voir donc les demandes suivant les utilisateurs de Dolibarr (et je rappelle que cela sera du dev personnalisé donc il faudrait mieux mutualiser les coûts) Mon dev pour cador m’a couté un peu plus de 1500 € et le prix du module a 120 € n’inclus pas d’autres fonctions (juste les mises a jours)

Après si on travaille avec un commissaire au compte, ce sera Cador (qui est vraiment top mais très cher ^^) et le module dans sa version actuelle fonctionne avec ce logiciel (c’est pour ça que j’ai fait coder cette export, et comme je n’utilise pas d’autres logiciels comptables cela dépendra donc des souhaits et finances des autres utilisateurs pour les autres modèles d’exports)

Les balances ou l’interrogation de compte n’est pas prévu « pour l’instant », comme je l’ai dit ce n’est pas un module comptable, pareil pour le lettrage. Faire un module comptable de A a Z reviendrai très cher et ce n’est pas le but.

Le but est d’exporter les données vers un véritable logiciel comptable (cf liste) et d’avoir des tableaux de bords performants. Une partie analytique sera surement rajouté (mais pareil en fonction des financements dont les miens prévus cette année)

Bonjour,

Je suis en train d’implémenter et tester le module ventilation comptable pour diminuer mes frais (environ 5000€/an ou 400€/mois), en suivant les conseils de @darkjeff, je pense arriver à les réduire à 1500 ou 2000€/an avec un comptable bienveillant, apte aux nouvelles technologies et allergique à la saisie et RE-saisie (la plus grosse part du budget d’un comptable…) !

Au niveau retour d’expérience :
TRES PRATIQUE la fonction de « ventilation automatique » quand les codes comptes comptables (achat et vente) sont renseignés sur les fiches produit (Voir PJ, on ne peut plus ajouter de PJ au fait, le forum a souffert on dirait ???)
Comme je ne les avais pas renseignés, Jeff m’a aidé à l’aide d’une requête SQL simple sur les produits achetés/vendus régulièrement, merci !

Ensuite, au niveau des autres achats, il est assez aisé, grâce à un « Plan Comptable Général » à jour, de définir ces codes et d’y ventiler nos achats particuliers (fournitures, transport, frais de port, cadeaux clients, etc…)

Pour environ 1000 factures, cela ne m’a pas pris plus de 2 heures pour ventiler automatiquement, et ensuite pour les codes suivants, cela dépend des notions de comptabilité de chacun et de la variété des codes à définir dans la liste de libellés (normalement, pas plus de 30 codes à définir).

Cela permet d’obtenir des tableaux clairs des frais engendrés par l’exercice et de vraiment « budgéter » et « piloter » l’entreprise !

Petit bémol : pour la TVA collectée 4457 = OK
mais où stocke-t-on la valeur de la TVA déductible (4456) ?

Je me permets de poster ça ici plutôt que par mail, ça laisse les autres connaître l’avancement du projet et les réponses de notre ami Jeff :wink:

A suivre, retour d’expérience sur les améliorations (marges pour la compta analytique) !

Oui Hubert c’est d’ailleurs la seul chose que j’ai du modifier sur mon export csv : la TVA à décaisser.

Le problème principal vient du fait qu’on a un seul champs ‹ compte comptable › dans le dictionnaire des taux TVA.

Le but étant de ne pas toucher au core de dolibarr pour être le plus indépendant possible lors des mises a jours. C’est d’ailleurs pour ça que j’ai créé le module ventilation, le jour ou lors d’une mise a jour les fonctions de ventilation avait disparues.

La compta sous Dolibarr on en entends parler depuis 2006 et cela reviens de temps en temps mais on a jamais rien de concret (ce n’est pas un reproche, je trouve le travail fait par la core team formidable) D’ailleurs si il y a des codeurs de module qui ont envie de m’aider a nettoyer/améliorer ce module, il suffit de m’envoyer un mail et je partage avec plaisir ce module (sinon pas grave je progresse en code un peu tous les jours et environ tous les deux mois je peux me payer une demi journée de christophe pour résoudre les problèmes ou je galère)

Pour revenir a la TVA

on ne va pas gérer la TVA sur les immo, du fait qu’on ne gère pas les immo (il faut bien laisser du travail au comptable), pareil pour la TVA sur les services pas encore encaissées car tout ceci va compliquer le problème.

Pareil pour les écritures entre regime simplifié ou normal ainsi que les écritures pour la CA12, comme le 445510 pour la TVA a décaisser ou le 445810 pour les acomptes de TVA (c’est le taff du comptable, mais on pourrai envisager de gérer les écritures de TVA plus tard, si on part sur une version plus évolué, c’est pas très compliqué et on a toutes les valeurs dans Dolibarr)

Pour la TVA que l’on récupère, pour moi même si plusieurs taux de TVA on peux tout mettre dans le même compte : 4456

Par contre pour la TVA sur la facturation client il faut ventiler par taux de TVA (si on a plusieurs taux de TVA, ce n’est pas mon cas, mais peut être a prévoir) : 4457

Pour le journal d’achat, il faut que je trouve un endroit pour la stocker.

Si un main dev de Dolibarr veut bien nous exprimer son opinion sur le sujet, je suis preneur.

Pour finir je suis entrain de rajouter la notion de grand livre afin de stocker les informations des journaux et aussi pour sortir des grand livre client, car actuellement quand je file un aperçu comptable a un de mes clients qui s’y connait en compta, il me demande direct un grand livre qui vient de mon comptable…

Donc pour la TVA collectée et déductible, quelle solution se profile ?
Car j’ai pu vérifier sur les dicos concernant la TVA, il n’y a bien qu’un seul compte…
Est-ce que le module ventilation permettra d’enregistrer
la TVA collectée et la TVA déductible à l’avenir
SOIT : par exemple en dessous de « Ventes de MArchandises »
une ligne qui s’appelerait « TVA 19.6 Collectée » et/ou « TVA 5,5 collectée »
Idem de l’autre côté, ventilation « achats »

SOIT : Un compte TVA « commun » qui fasse la différence entre collectée et déductible et qui nous affiche un « solde » positif (si TVAventes > TVAachats) ou négatif…

C’est vrai que l’avis d’un développeur Dolibarr style Eldy ou Régis (même s’il est regrettablement parti, ne serait pas de refus, pour éclaircir la question)

A bons entendeurs :wink:

De toute façon pour la TVA, il faut deux comptes comptables (ça c’est sur), pas très compliqué a rajouter, mais forcément si on le fait on touche au core de dolibarr et donc a chaque mise a jour il faudra refaire la manip…

Pareil pour les tables llx_facturedet et llx_facture_fourn_det, j’utilise fk_code_ventilation afin de stocker le compte comptable

Dans llx_facturedet on a aussi fk_export_compta, ce qui pourrait être utile pour gérer la table qui va stocker les écritures (pour les grands livres)

Enfin plein de questions et peu de réponse.

Au début j’ai mis un prix sur le module afin de financer du dev (car il faut être clair je n’arriverai pas a tout coder et jeffinfo peut investir 1000 a 1500 de code par an, mais pas plus)

Le code avait été mis a l’époque sur Github par Regis, mais Github j’y comprends rien (enfin pour l’instant). Je code avec notepad2 sur un wamp installé dans ma dropbox.

Donc si une bonne âme a envie de venir nous aider afin de faire évoluer Dolibarr pour avoir une compta simple, une base de compta analytique et de bons tableaux de bord, je ne refuse aucune aide.

Comme je suis entrain de tester la 3.3 sur mon environnement test :

code compta vente et code compta achat ont été rajouté dans le dictionnaire TVA

Le code du journal d’achat et du journal des ventes a lui aussi été modifiés (en profondeur mais en gardant les foreach)

le plan comptable a aussi été mis a jour (mais comme j’utilise qu’une vingtaine de compte, je vais continuer a utiliser ma table qui stocke les comptes)

Pourtant dans la roadmap 3.3 concernant la compta je n’avais trouvé que ça
New: Add link to third party into sells and purchase journal.

Sinon comme d’habitude la mise a jour se fait en un clic (merci au main codeur pour ça)

Le module ventilation fonctionne en 3.3, il faudra juste que je compare le code des journaux, a moins qu’on me dise que pour la 3.4 la compta sera opérationnel, même si je reste persuadé qu’il faut ventiler afin de garder un contrôle manuel, car oui je ne créé pas de produit pour chacun de mes achats et cela m’arrive de vendre avec un libellé libre.

Bonjour darkjeff,

On organise un devcamps Dolibarr an avril a Montpellier (voir ici : [url=www.dolibarr.fr/forum/t/dolibarr-devcamp-2013-montpellier-en-avril/16444/1 Dolibarr Avril 2013[/url]), il serait bien que tu soit la pour parler de ce sujet qui tiens a coeur de beaucoup d'utilisateurs et qui manque dans Dolibarr, même si sur la 3.3 il y a eu pas mal d’évolutions sur le sujets.

Cdt.

Bonjour Florian

pas évident pour moi, car le mois d’avril est chargé et je serai en Autriche chez un de mes clients durant la période du Devcamp.

Mais on pourrait organiser un hangout ou une confcall pour en discuter (plus facile pour moi)

Sinon j’ai réussit a me mettre a Github (enfin pas a forker Dolibarr, mais je pense que c’est à cause d’un précédent fork que Regis m’avais fait avec mon compte il y a un an, trop de commit et donc je suis bloqué)

Pour finir le module sera gratuit (je préfère avoir des retours utilisateurs)

donc voici l’adresse de la version en plein recodage pour le 3.3

git://github.com/Darkjeff/dolibarr_ventilation_compta.git

tout fonctionne sauf l’export csv (j’ai encore la version 3.2 ou l’export csv fonctionne)

Si tu as un besoin d’un coup de main sur l’export ce sera avec plaisir :happy: , semble que je connaisse un peu le sujet :whistle:
tu peux me contacter par là : charles.fr chezmoi benke.fr

au contraire je serai content d’avoir de l’aide (je suis un jeune padawan en code, mais je progresse ^^)

c’est pour ça que je me suis battu avec github ce week end afin de mettre le projet dessus, je pense que c’est plus simple pour collaborer sur le code.

1 « J'aime »

si besoin d’un environement de test sous 3.3, me faire signe :wink:

j’ai ca

Bonjour,

Je suis ne train de tester le module en 3.2.3.

Je renseigne le compte comptable.

Question : comment gérer la TVA sur achat (445660) et TVA sur vente (445710)?

On rentre ça dans le dictionnaire ?

D’avance merci.

Nusa

En 3.2, pas de code pour les comptes de TVA coll ET de TVA déd…
Migrez tout de suite à la 3.3, les codes y sotn apparus (malgré aucune mention dans le changelog…)
Jeff est en train de terminer la partie « charges » je pense, pour l’instant on a un tableau de bord sans la partie « charges » comme par ex les salaires, l’urssaf, etc…

SAUF si vous créez un fournisseur « URSSAF » , « EMPLOYE A » EMPLOYE B, "CAISSE RETRAITE, etc… là vous pourrez les gérer :wink:

Mais pour la TVA il y a un petit peu à refaire… Dans les posts depuis le début, on en parle, merci d’y ajouter vos commentaires si vous pensez à quelque chose en + ou quelque chose à corriger :wink:

OK merci pour la réponse. La migration reste liée à la compatibilité des modules…

Nusa

@nusa pour la tva collectée et déductible il suffit de la renseigner dans dictionnaires > taux de tva (en 3.3, pour la 3.2 il n’y a qu’un compte comptable, mais bientôt on ne parlera plus qu’en 3.3)

@hubert : je passe tous les dolibarr en prod en version 3.3 mercredi, j’ai terminé les tests hier soir et aucun problème détecté (qq bugs mineurs mais on en discutera)

Comme on a des tables accounting et qu’elles peuvent servir pour stocker les écritures afin d’exporter vers ciel/sage/ebp, je vais commencer a travailler dessus.

Faut que je regarde par contre car dans le plan comptable, les comptes sont sur 3 chiffres et 2 chiffres pour les racines comptables, je pense donc relier l’information a llx_compta_compte_generaux avec une colonne pointant vers accountingaccount du genre compte parent (un peu comme le compte racine sur deux chiffres)

Je garde quand même les informations date / compte / libellé / debit / credit (c’est le format qu’il me faut pour suite expert cador ^^)

Par contre on peux exporter les écritures vers llx_accountingdebcred et llx_accountingtransaction, même si je trouve la conception un peu compliqué

a la rigueur il faudrait un modèle pour les logiciels compta
rowid / journal / date / compte / libellé / sens / montant

enfin tout ça bien sur a discuter, car de mon coté ma compta est nickel :lol: comme ça, mais autant avancer sur les autres logiciels comptables :wink:

Pour les modèles, pourquoi pas…
Chacun est libre de demander ici ce qu’il veut comme modèle, séparé par des « ; »

Sinon pour les tables « racine » à 2 chiffres, et les autres à plus de chiffres, qu’est ce que c’est et pourquoi cette structure étrange ?

J’ai pas regardé llx_accountingdebcred et llx_accountingtransaction (bon si, je viens de regarder à l’instant)
SI un écran permettait d’exploiter, de remplir, ou d’afficher ces données ou un Modèle Conceptuel de Données pourrait nous éclairer sur la structure… ce serait wahou… car en l’état elles paraissent bien inutiles, surtout la table
llx_accountingaccount (FK_TRANSACTION ?) et le champ « account » c’est sensé être un code comptable par « client », « fournisseur », « type de charge » ?
Dans ce cas il va falloir prévoir une num° auto et incrémentielle de ces comptes non ?
llx_accountingtransaction (c’est le meilleur celui la…)
fk_source ? url ?
J’ai l’impression d’utiliser 4% de dolibarr quand je vois des champs comme ça…

Pour les charges, tu comptes baser le raisonnement comme depuis le début, mais avec possibilité d’émettre des règlements sur les charges (pour le solde du compte bancaire…), ou simplement de les ventiler et qu’elles apparaissent dans les récaps « balances », etc…

Merci !
Bon courage,

racine a 2 chiffres c’est pour regrouper les comptes (genre pour faire une balance)

la compta c’est simple alors on va essayer de ne pas compliquer la chose, c’est les comptables et les informaticiens qui compliquent la chose :evil:

Pour la compta :

le plan comptable, je vais rajouter une page pour le gérer, mais bon perso j’utilise pas, enfin il faut être clair dans une société on utilise 10% des comptes du plan comptable (un peu plus a la création de la société, mais bon)

si je reprends les tables reliés a la compta (llx_accounting) on peut utiliser llx_accountingaccount et llx_accounting_system, si on utilise llx_accountingdebcred et llx_accountingtransaction ça va être une usine a gaz

On a aussi des anciennes tables llx_compta et llx_compta_account mais c’est pas exploitable.

Donc a va faire plus simple je vais rajouter
dans la table llx_compta_compte_generaux :
* la notion de journal (champs libre car CIEL deux caractères, sage et ebp c’est trois) cela permettra aussi de filtrer les comptes par ventilation, afin d’éviter les erreurs
* un rowid qui pointe vers le plan comptable (au cas ou un jour on veut s’amuser a sortir une liasse, ou une balance)

une table llx_bookkeeping (on va essayer de tout repasser en anglais ^^)
* rowid
* Date
* llx.compta_compte_generaux.rowid
* libellé piece comptable : Facture n° ref
* debit
* credit
* fk_user_author

on peut aussi choisir le modèle amount + sens (D ou C) (je ne suis pas fan de ce modèle, mais c’est vrai que 90% des logiciels comptables sont sur modèle)

le but est de balancer dans la table llx_bookkeeping
le journal de vente
le journal d’achat

il y a un champ fk_export_compta dans llx_facturedet qui permettra de savoir si c’est exporté dans llx_bookkeeping ou pas. il faudrait le même dans llx_facturefourn_det

Après il faudra s’attaquer aux écritures bancaires

pour la partie analytique on a eu une réflexion assez intéressante avec franck, sur de l’analytique multi service, multi société (pas très compliqué a mettre en oeuvre non plus, mais il faut approfondir la reflexion)

mais on va d’abord terminer la partie compta classique.

C’est bien beau tout ça mais je repars sur le code, sinon c’est pas prés d’avancer :wink:

Je continu ma réflexion sur la compta, enfin plutôt mon monologue, mais comme disait Victor Hugo « le monologue est la fumée des feux intérieurs de l’esprit »

Donc si il y a un an les tables llx_accountingdebcred et llx_accountingtransaction sont apparues, c’est pour une bonne raison. Et hier soir j’ai trouvé l’intérêt de llx_accountingtransaction, cette table va servir a savoir si :
* une facture client/fournisseur
* un paiement client/fournisseur

a une écriture comptable correspondante

Bon ok sur le principe, le champs fk_ventilation dans les tables me convenait, mais pourquoi pas c’est peut être mieux en code

On obtient quand même un modèle complexe pour juste sortir des écritures comptables

En outre j’ai quand même besoin d’une table pour rajouter des comptes comptables,

si je prends en exemple
626 : frais de télécommunication et postaux

perso j’utilise
6260000 : telephone ovh
6261000 : mobile free
6262000 : telephone orange
6263000 : frais postaux
6264000 : internet

J’étais parti hier sur rajouter la notion de « journal » dans la table des comptes (afin d’éviter les erreurs dans le choix des comptes, on ne connait pas touts le plan comptable par coeur :tongue: ), mais cela pose un problème pour les comptes de classe 4 (les taxes) qui sont à la fois dans les ventes et les achats. Donc je vais plutôt rajouter deux cases a cocher afin de préciser si le compte appartient au achat ou au vente ou au deux.

Comme je suis contre les trigger qui balancent directement les écritures (pour moi il faut un contrôle humain), je résonne en ventilation et en plus avec la ventilation automatique on gagne quand même du temps.

* a ventiler
permet d’attribuer un compte comptable a chaque ligne d’achat ou de vente

* ventilé
permet de contrôler les écritures et d’exporter tout ça dans une table écriture comptable

Pour la compta ana, le but est d’exploser chaque ligne d’achat dans différents comptes afin d’avoir une analyse plus fine.

Si d’autres utilisateurs ont des réflexions a apporter, je suis preneur :happy: