Compte tiers dans lima
Bonjour, Dans lima, il y a une notion de "compte tiers" en plus des comptes généraux. Cependant, je ne comprend pas bien la raison de l'existence des comptes tiers. Qu'est ce qui différencie un compte tiers d'un compte général ? Est-ce qu'un compte tiers est utilisé différemment d'un compte général par la suite ? Merci. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
C'est une erreur que j'avais déjà remonté. Il ne faut pas parler de compte tier, mais de compte auxiliaire. Il faudrait modifier ce problème de terminologie dans l'appli. Un compte auxiliaire, permet de crée un sous-compte par exemple un compte client ou un compte fournisseur en définissant sa propre numérotation à partir du plan comptable. Exemple 512 - banque, un compte par exemple chez LCL, on définira un compte auxiliaire 512LCL. Autre exemple 411 - client, regroupement des factures en provenance de l'Ifremer, on définira un sous-compte 411IFREMER. :) La différence est qu'un compte général la numérotation ne doit pas être "exotique" et suivre le plan de comptabilité général, et un compte auxiliaire doit commencé par la numérotation du plan comptable parent et se termine par une notation personnalisé. Le 23 février 2012 11:26, Eric Chatellier <chatellier@codelutin.com> a écrit :
Bonjour,
Dans lima, il y a une notion de "compte tiers" en plus des comptes généraux. Cependant, je ne comprend pas bien la raison de l'existence des comptes tiers.
Qu'est ce qui différencie un compte tiers d'un compte général ?
Est-ce qu'un compte tiers est utilisé différemment d'un compte général par la suite ?
Merci.
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
_______________________________________________ Lima-devel mailing list Lima-devel@list.chorem.org http://list.chorem.org/cgi-bin/mailman/listinfo/lima-devel
Le 23/02/2012 11:49, jpepin a écrit :
C'est une erreur que j'avais déjà remonté. Il ne faut pas parler de compte tier, mais de compte auxiliaire.
Il faudrait modifier ce problème de terminologie dans l'appli.
Un compte auxiliaire, permet de crée un sous-compte par exemple un compte client ou un compte fournisseur en définissant sa propre numérotation à partir du plan comptable.
Exemple 512 - banque, un compte par exemple chez LCL, on définira un compte auxiliaire 512LCL. Autre exemple 411 - client, regroupement des factures en provenance de l'Ifremer, on définira un sous-compte 411IFREMER. :)
La différence est qu'un compte général la numérotation ne doit pas être "exotique" et suivre le plan de comptabilité général, et un compte auxiliaire doit commencé par la numérotation du plan comptable parent et se termine par une notation personnalisé. Merci pour ce retour.
Les comptes auxilliaires vont donc être supprimé. Il ne restera que des "comptes" dans lima Au comptable ensuite de savoir comment il numérote. Le stockage en arbre va être supprimé. Seul le rendu se fera toujours en arbre. Ce qui permettra d'ajouter facilement des comptes intermediaires après les imports EBP où il manque des comptes par exemple. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Cette simplification est au sens comptable une très mauvaise idée. Si vous supprimer la vérification de la numérotation on sort d'un prérequis du logiciel comptable et ne suivra plus la norme. Le 23 février 2012 15:18, Eric Chatellier <chatellier@codelutin.com> a écrit :
C'est une erreur que j'avais déjà remonté. Il ne faut pas parler de compte tier, mais de compte auxiliaire.
Il faudrait modifier ce problème de terminologie dans l'appli.
Un compte auxiliaire, permet de crée un sous-compte par exemple un compte client ou un compte fournisseur en définissant sa propre numérotation à
du plan comptable.
Exemple 512 - banque, un compte par exemple chez LCL, on définira un compte auxiliaire 512LCL. Autre exemple 411 - client, regroupement des factures en provenance de l'Ifremer, on définira un sous-compte 411IFREMER. :)
La différence est qu'un compte général la numérotation ne doit pas être "exotique" et suivre le plan de comptabilité général, et un compte auxiliaire doit commencé par la numérotation du plan comptable parent et se termine
Le 23/02/2012 11:49, jpepin a écrit : partir par
une notation personnalisé. Merci pour ce retour.
Les comptes auxilliaires vont donc être supprimé. Il ne restera que des "comptes" dans lima
Au comptable ensuite de savoir comment il numérote.
Le stockage en arbre va être supprimé. Seul le rendu se fera toujours en arbre. Ce qui permettra d'ajouter facilement des comptes intermediaires après les imports EBP où il manque des comptes par exemple.
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
_______________________________________________ Lima-devel mailing list Lima-devel@list.chorem.org http://list.chorem.org/cgi-bin/mailman/listinfo/lima-devel
Le 23/02/2012 16:23, jpepin a écrit :
Cette simplification est au sens comptable une très mauvaise idée. Si vous supprimer la vérification de la numérotation on sort d'un prérequis du logiciel comptable et ne suivra plus la norme. On y a pensé.
Ce que tu evoque est une norme française qui potentiellement n'a pas lieu d'être dans les autre pays. Si le besoin s'exprime plus tard, nous rajouterons plutôt une règle qui dit que les comptes (tiers?) doivent forcement commencer par 401 ou 411 en france (par exemple). En attendant, c'est plutôt aux experts comptable de garantir une bonne saisie d'une comptabilité. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
Oui c'est une spécificité de la norme comptable française. Et les règles de localisation qui avaient été mis en place sont là pour cela. La garantie du respect du plan comptable est une règle de base à respecter dans un logiciel de compta compatible avec la norme française, c'est ce que j'avais vu avec Catalo. Libre a vous dans votre choix de direction pour Lima. Le 23 février 2012 16:39, Eric Chatellier <chatellier@codelutin.com> a écrit :
Cette simplification est au sens comptable une très mauvaise idée. Si vous supprimer la vérification de la numérotation on sort d'un
Le 23/02/2012 16:23, jpepin a écrit : prérequis du
logiciel comptable et ne suivra plus la norme. On y a pensé.
Ce que tu evoque est une norme française qui potentiellement n'a pas lieu d'être dans les autre pays.
Si le besoin s'exprime plus tard, nous rajouterons plutôt une règle qui dit que les comptes (tiers?) doivent forcement commencer par 401 ou 411 en france (par exemple).
En attendant, c'est plutôt aux experts comptable de garantir une bonne saisie d'une comptabilité.
-- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
_______________________________________________ Lima-devel mailing list Lima-devel@list.chorem.org http://list.chorem.org/cgi-bin/mailman/listinfo/lima-devel
Le 23/02/2012 17:23, jpepin a écrit :
Oui c'est une spécificité de la norme comptable française. Et les règles de localisation qui avaient été mis en place sont là pour cela. La garantie du respect du plan comptable est une règle de base à respecter dans un logiciel de compta compatible avec la norme française, c'est ce que j'avais vu avec Catalo.
Libre a vous dans votre choix de direction pour Lima. En fait, l'exemple était peut être mauvais. Vérifier que les numéros de compte qui comporte des lettres (ex compte tiers) commence par des lettres n'ai pas compliqué a vérifier.
Cependant, certains autre points spécifique à la compta française dont nous avons pu discuter entre temps ne s'implémentaient pas aussi facilement, et nous avons décider de les mettre de coté dans un premier temps. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
En fait, l'exemple était peut être mauvais. Vérifier que les numéros de compte qui comporte des lettres (ex compte tiers) commence par des lettres n'ai pas compliqué a vérifier. Vérifier que les numéros de compte qui comporte des lettres (ex compte tiers) commence par un numéro définit (401) n'ai
Le 23/02/2012 17:30, Eric Chatellier a écrit : pas compliqué à vérifier. -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 23/02/2012 17:23, jpepin a écrit :
Oui c'est une spécificité de la norme comptable française. Et les règles de localisation qui avaient été mis en place sont là pour cela. La garantie du respect du plan comptable est une règle de base à respecter dans un logiciel de compta compatible avec la norme française, c'est ce que j'avais vu avec Catalo.
En fait, la réflexion part des problèmes que l'on rencontre avec l'import EBP. Par exemple, EBP n'a pas forcément les comptes 40 et 401, donc à l'import, notre plan comptable est "cassé". Je ne penses pas que les modifications évoquées "cassent" la vérification de la numérotation. Je m'explique : Tu as un compte 401COUTE par exemple et un compte 4. En absence d'autres comptes, le compte 401COUTE se trouvera "visuellement" sous le compte 4. Si maintenant je rajoute le compte 40, il ira se situer entre les comptes 4 et 401COUTE. Comme ça la règle de numérotation est respectée. Certes, le stockage ne garanti pas l'intégrité de l'arborescence (un compte ne connait pas son compte parent), mais le code de l'application (dans une règle de localisation par exemple) oui. On pourrait aussi potentiellement lister les comptes généraux dans la règle de compta française. Est-ce que ce mode de fonctionnement te semble cohérent ? Jean - -- Jean Couteau - Code Lutin Tel : 02.40.50.29.28 Port : 06.68.07.29.29 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPRmzQAAoJEFOQdnjKiPj3LD0H/3BoZUGB6VIe4i7QGYzJApEw g4tO8+4P6HFY/hkw1r4ZaZPSspsvvJ37GQY3teooDD5/S/MZ5kWRYAKaazrntmVd Y4SzTLQra+y0tgpH6B2/CCE0EjBjOvvy2ziJxB+DmGcDdaOMCeujdPzHRwXNvJCk PZXQQfbubBxAaqJXDe9OGH/fcvKoO1JNGLjeWnjOh2Zav367Mwr/K66Szq2X1bAy v0/vtagCJqi7qnIyRopGgaAHdfht6ahJx8YAkAqNCahdCMqAuRjULq0RZWoChqWC b6/YL/crgk0/lvWf17DV0OiquZtH+uJidv1LPCBnuFEUepK4z9SbOlGw2h8NX/k= =KQ2y -----END PGP SIGNATURE-----
OK. Je crois comprendre le but premier de la modification : modifier le modèle afin de ne plus avoir de contraintes qui pourrait être lié à la compta française. Tu as un compte 401COUTE par exemple et un compte 4. En absence
d'autres comptes, le compte 401COUTE se trouvera "visuellement" sous le compte 4. Si maintenant je rajoute le compte 40, il ira se situer entre les comptes 4 et 401COUTE. Comme ça la règle de numérotation est respectée.
Dans la norme le 401coute n'as pas d'existence si le 401 n'existe pas, corollairement le 40 et le 4. Juste pour le fun :) , dans l'import je verrais plutôt un algo du genre : pourchaque (c : compteAImporter){ si (existeDeja(c)){ mettreAjourNomDuCompte(c); } sinon{ ajoutRecurr(c); } } fonction ajoutRecurr(c){ si (existeParent(c)){ inserer(c) } //creation de parent d'un compte auxiliaire sinon si (c.ContientChar()){ inserer(c) ajoutRecurr(c.sanslesChar()) } // si compte minimal, 1, 2, 3, 4… on fait rien sinon si (c.nbChar() ==1) { //creation compte parent inserer(c) ajoutRecurr(c.sousChaine(c.longueur-1)) } }
Le 23/02/2012 19:38, jpepin a écrit :
OK. Je crois comprendre le but premier de la modification : modifier le modèle afin de ne plus avoir de contraintes qui pourrait être lié à la compta française.
Tu as un compte 401COUTE par exemple et un compte 4. En absence
d'autres comptes, le compte 401COUTE se trouvera "visuellement" sous le compte 4. Si maintenant je rajoute le compte 40, il ira se situer entre les comptes 4 et 401COUTE. Comme ça la règle de numérotation est respectée.
Dans la norme le 401coute n'as pas d'existence si le 401 n'existe pas, corollairement le 40 et le 4.
Donc EBP ne respecte pas la norme ? Parce que justement notre questionnement provenait du fait que certains comptes intermédiaires n'existaient pas dans EBP.
Juste pour le fun :) , dans l'import je verrais plutôt un algo du genre :
pourchaque (c : compteAImporter){
si (existeDeja(c)){ mettreAjourNomDuCompte(c); } sinon{ ajoutRecurr(c); } }
fonction ajoutRecurr(c){
si (existeParent(c)){ inserer(c) } //creation de parent d'un compte auxiliaire sinon si (c.ContientChar()){ inserer(c) ajoutRecurr(c.sanslesChar()) } // si compte minimal, 1, 2, 3, 4… on fait rien sinon si (c.nbChar() ==1) { //creation compte parent inserer(c) ajoutRecurr(c.sousChaine(c.longueur-1)) } }
Sauf que parfois tu as des comptes genre : 401300000 Dans ce cas tu crées aussi les comptes : 40130000, 4013000, 401300, 40130, 4013, 401, 40, 4 si ils n'existent pas ? Y-a-t-il un une longueur de chaîne à partir de laquelle on ne crée plus de sous-compte (genre tu crées 4, 40 et 401 et après tu ne crées plus de sous compte) ? Jean
Le 24 février 2012 10:05, Jean Couteau <couteau@codelutin.com> a écrit :
Donc EBP ne respecte pas la norme ? Parce que justement notre questionnement provenait du fait que certains comptes intermédiaires n'existaient pas dans EBP.
Même interrogation.
40130000, 4013000, 401300, 40130, 4013, 401, 40, 4 si ils n'existent pas ?
Y-a-t-il un une longueur de chaîne à partir de laquelle on ne crée plus de sous-compte (genre tu crées 4, 40 et 401 et après tu ne crées plus de sous compte) ?
Quand tu crée une compta dans un logiciel, il demande la longueur de la numérotation, généralement les comptables choisissent entre 7 ou 8 caractères. Si tu as une très très grosse compta tu peux monter à plus pour avoir plein de compte auxiliaires ou tiers. Ensuite, tu as tout à fait raison y a que les comptes intermédiaires existants dans le plan comptable qui doivent-être créés. http://fr.wikipedia.org/wiki/Plan_comptable_g%C3%A9n%C3%A9ral_%28France%29 Donc il faut faire en plus une vérification assez simple, si le compte parent a créer existe dans le plan comptable : le créer, sinon on remonte au compte grand-parent et ainsi de suite. En reprenant ton exemple 40130000, on crée 401, 40 et 4. Autre exemple *4011*0020, on crée 4011, 401, 40 et 4, car le 4011 existe dans le plan comptable, à la différence de l'exemple précédent ou le 4013 n'existe pas. Pour effectuer cette vérification, il suffit de charger le fichier de plan comptable que j'avais fait pour avoir un squelette standard à suivre.
Le 24/02/2012 14:10, jpepin a écrit :
Donc il faut faire en plus une vérification assez simple, si le compte parent a créer existe dans le plan comptable : le créer, sinon on remonte au compte grand-parent et ainsi de suite.
En reprenant ton exemple 40130000, on crée 401, 40 et 4. Autre exemple *4011*0020, on crée 4011, 401, 40 et 4, car le 4011 existe dans le plan comptable, à la différence de l'exemple précédent ou le 4013 n'existe pas.
Pour effectuer cette vérification, il suffit de charger le fichier de plan comptable que j'avais fait pour avoir un squelette standard à suivre.
Merci bien pour l'explication. Ca éclairci grandement. Jean -- Jean Couteau - Code Lutin Tel : 02.40.50.29.28 Port : 06.68.07.29.29
Le 24/02/2012 14:10, jpepin a écrit :
En reprenant ton exemple 40130000, on crée 401, 40 et 4. Autre exemple /4011/0020, on crée 4011, 401, 40 et 4, car le 4011 existe dans le plan comptable, à la différence de l'exemple précédent ou le 4013 n'existe pas.
Est-ce vraiment une obligation d'avoir les comptes 40 et 401 même si on ne les utilise pas directement dans la compta ? -- Éric Chatellier <chatellier@codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com
participants (3)
-
Eric Chatellier -
Jean Couteau -
jpepin