sur une compta a plan il faut sommer le plan :
c la fameuse loi - Sigma/Somme/Sommation des credit = Sigma/Somme/Sommation des Debit
sinon le plan ne sert a rien et cela reste une compta de compte autonome en partie simple.
Au fait, gnucash n'est pas en partie double, ne gere aucune integrité des ecritures, et n'a de plan qu'une hierarchie d'avoir.
si un logiciel de comptabilité n'est pas utilisable par un comptable, cela me semble assez ennuyeux.
Pour ce qui est de la representation, les sous totaux d'avoir ne permette qu'une "compta en partie simple" ou dite "comptabilité de caisse".
la "compta analytique" est un domaine tres particulier de la "compta générale", puisqu'elle necessite l'etablissement d'une bijection entre la "compta au bilan" ( ou patrimoniale ) et la compta analytique avec des comptes intermediaires.
Les aspects analytiques sont longuement discuté d'un point de vu structurelle, le principe etant une comptabilité des flux.
elle repose essentiellement sur la compta en partie double.
la compta en partie double ( je le repete dans un francais que j'espere plus correct ), ne peut se resumer à une hiérarchie de balance des comptes.
la partie double est en opposition Débit/Crédit. la balance etant debit-credit ou credit-debit ( selon où se trouve le signe positif ce qui determine où solder pour la cloture ).
par exemple, si les comptes 5112 et 6541 representent respectivement les cheques en attente de compensation, et les cheques non recouvrables.
la balance du 5112 est tjr nulle sauf si il y a des cheques en attente de compensation.
la balance du 6541 est au mieux nulle, si il n'y a aucun impayé.
par contre, le montant des debits du 5112 indique le montant total des cheques ayant été ou en cours de compensation. le montant des credits quant a lui, represente le montant total des cheques compensés ou rejetés.
ce qui fait que si la balance du 6541 n'est pas nulle, le montant des credits du 5112 est à minorer de la balance du 6541 et de la TVA y affairant ( compte que je n'ai pas nommé pour eviter les embrouilles ) pour connaitre le montant des cheques réellement encaissés.
cette informations qui est purement calculatoire dans une compta en partie double correctement ventilée, comment peut elle etre obtenu dans un modele en partie simple ( cad avec uniquement la balance comme information connue ) ? je ne vois que la possibilité d'un stockage en base ce qui fait qu'il y a nécéssairement la multiplication à terme du stockage d'informations quasi inutiles dans 99% des cas.
le point que j'indique est propre à la totalité des logiciels de compta que j'ai un temps soit peu regardé. C'est d'ailleurs un des points que j'avais soulevé sur la ML de l'APRIL par rapport à la nécessité de l'inter-opérabilité comptable au niveau du libre et de certaines contraintes y affairant.
[^] # Re: Question intéressée
Posté par Mouns . En réponse à la dépêche Sortie officielle de Tiny ERP 2.0. Évalué à 4.
c la fameuse loi - Sigma/Somme/Sommation des credit = Sigma/Somme/Sommation des Debit
sinon le plan ne sert a rien et cela reste une compta de compte autonome en partie simple.
Au fait, gnucash n'est pas en partie double, ne gere aucune integrité des ecritures, et n'a de plan qu'une hierarchie d'avoir.
si un logiciel de comptabilité n'est pas utilisable par un comptable, cela me semble assez ennuyeux.
Pour ce qui est de la representation, les sous totaux d'avoir ne permette qu'une "compta en partie simple" ou dite "comptabilité de caisse".
la "compta analytique" est un domaine tres particulier de la "compta générale", puisqu'elle necessite l'etablissement d'une bijection entre la "compta au bilan" ( ou patrimoniale ) et la compta analytique avec des comptes intermediaires.
Les aspects analytiques sont longuement discuté d'un point de vu structurelle, le principe etant une comptabilité des flux.
elle repose essentiellement sur la compta en partie double.
la compta en partie double ( je le repete dans un francais que j'espere plus correct ), ne peut se resumer à une hiérarchie de balance des comptes.
la partie double est en opposition Débit/Crédit. la balance etant debit-credit ou credit-debit ( selon où se trouve le signe positif ce qui determine où solder pour la cloture ).
par exemple, si les comptes 5112 et 6541 representent respectivement les cheques en attente de compensation, et les cheques non recouvrables.
la balance du 5112 est tjr nulle sauf si il y a des cheques en attente de compensation.
la balance du 6541 est au mieux nulle, si il n'y a aucun impayé.
par contre, le montant des debits du 5112 indique le montant total des cheques ayant été ou en cours de compensation. le montant des credits quant a lui, represente le montant total des cheques compensés ou rejetés.
ce qui fait que si la balance du 6541 n'est pas nulle, le montant des credits du 5112 est à minorer de la balance du 6541 et de la TVA y affairant ( compte que je n'ai pas nommé pour eviter les embrouilles ) pour connaitre le montant des cheques réellement encaissés.
cette informations qui est purement calculatoire dans une compta en partie double correctement ventilée, comment peut elle etre obtenu dans un modele en partie simple ( cad avec uniquement la balance comme information connue ) ? je ne vois que la possibilité d'un stockage en base ce qui fait qu'il y a nécéssairement la multiplication à terme du stockage d'informations quasi inutiles dans 99% des cas.
le point que j'indique est propre à la totalité des logiciels de compta que j'ai un temps soit peu regardé. C'est d'ailleurs un des points que j'avais soulevé sur la ML de l'APRIL par rapport à la nécessité de l'inter-opérabilité comptable au niveau du libre et de certaines contraintes y affairant.