re bonjour,

C'est bien pratique d'avoir des libellés de taxes explicites quand on crée le devis et la facture.
Mais dans les documents émis, c'est superflu et ça encombre. Il suffit que le client voit le montant de la tva.
Je définis donc un champ supplémentaire tax_shortname par exemple "19,6%" et c'est ce champ qui est imprimé dans le devis.
Je me demande si cette modification ne devrait pas plutôt être intégrée dans le plan comptable standard : un nom de taxe jusqu'à 64 caractères et un shortname de 16 caractères.
Qu'en pensez vous ?

Entièrement d'accord.
D'autant que s'il y a une différenciation entre la TVA d'achat à 19,6 et celle de vente à 19,6, il faut préciser ça dans le nom pour pouvoir la choisir, mais du coup ça l'imprime sur les documents...

Il faut remarquer que le nom de la taxe est indiqué dans la facture. Si sur chaque ligne, le "short_name" remplace avantageusement le nom complet, je trouve intéressant de conserver ce nom complet dans le récapitulatif des taxes.
Mais dans ce cas, ce nom complet doit être traduit dans la langue du document et ceci implique une définition multilingue.
Plutôt que de gérer ces contraintes sur mes projets, ne faudrait il pas adapter les autres modules pour que ce champ soit traduit, quelque soit le plan comptable ?

Bonjour à tous,
Tout d'abord un grand Merci à Simon pour cet énorme travail.
Je teste actuellement ce nouveau plan comptable.
Il me semble ( c'est toujours un peu génant de dire cela) qu'il y a quelques erreurs de saisies.

- Pour les comptes 11. / 31. / 37. ne doit-on pas mettre Type de compte à "Vue" et Report à nouveau à "Aucun"?

- Pour les comptes dont le report à nouveau est " Non réconcilié" ne doit-on pas cocher la case "Réconciliation" ?

Définition des taxes par défaut :
- compte 409./ 60221. / 6071. / 624. / 6248. taxe indiquée " tva collectée" au lieu de "tva acquittée"


En ce qui concerne le nom des Taxes un nom court est préférable pour l'impression des documents ( Devis / Commandes / Factures) et le fait de modifier le fichier taxes ne fait pas courir un grand risque dans la sélection à partir du moment ou l'on utilise un fichier Articles dans lequel on a Indiqué le code TVA applicable.

Je continue à tester. Amicalement.
Jean-Pierre

Concernant les paramètres par défaut, effectivement, cela va dépendre de l'activité de l'entreprise.
Il faudrait peut-être se baser sur un cadre scolaire pour les paramètres par défaut.
Dans ce cas je pense que Christian à raison 607 et 707 semble un bon compromis.



Je te rejoins entièrement sur ce point.



Non non, c'est justement maintenant qu'il faut en parler. Car une fois que le plan est utilisé en production, les modifications sont toujours plus délicates.



11 type vue : OK
31 et 37, justement je me suis posé la question.
comme je n'ai pas compris ce qu'était les "groupe A", "goupe B" et "A B C"
j'ai pensé que c'était une décomposition arbitraire des comptes au cas où une entreprise voulait faire des catégories dans ses matières premières. Et qu'il était possible de ne pas les utiliser et de mettre tout dans 31 ou 37 directement.

Comme 11 31 et 37 sont des comptes d'actif, je pensais que leur solde devait être conservé d'un exercice à l'autre.... si l'on repart à 0 sur 11 31 et 37 (en mettant le report à aucun) il y aura forcément une opération à faire pour respecter le principe de la double entrée.
Enfin, c'est juste une déduction de ma part motivé par mes lectures...
Donc si il y a des comptables parmi vous, je lance un appel, c'est le moment de nous faire partager votre savoir !



Oula... effectivement je pense que vous avez raison... si la case Réconciliation n'est pas coché, la réconciliation automatique ne pourra pas se faire et on sera obligé à chaque fois de la faire à la main.



Effectivement !



Oui et non !
Par exemple imaginons un paiement comptant à un fournisseur. On peut très bien se passer du compte 4011 (fournisseur).
Dans le journal de banque on crédite le compte 512 (banque) et on débite le compte de TVA et le compte 60..
Si on fait ça, on a rien dans la rapport de TVA.
Pour mettre à jours le rapport de TVA il faut éditer les deux dernières opération et leur associer un code de taxe.
Lorqu'on utilise des noms court, on passe à chaque fois 10 min pour retrouver la bonne taxe.
Comme vous, je trouve que les rapports sont un peu trop "verbeux" du coups je suis plus de l'avis de Dominique à savoir : définir deux noms pour les taxes, un long pour l'interface et un court pour "les rapports"

Bonjour,

En ce qui concerne le nom des taxes j'ai, dans ma Sté de teste, utilisé des noms courts comme : V19,6% pour TVA vente 19,6%
A19,6% pour TVA achat 19,6% etc...

ce qui me permet de résoudre les deux points soulevés ( Retrouver facilement la taxe à appliquer selon son utilisation " Vente ou Achat" et L'impression sur les documents) sans avoir à modifier le logiciel.

Toutefois comme le dit Dominique il serai super intéressant d'avoir une zone de libellé court dans la définition des taxes ( cela augmenterait les possibilités d'adaptation).
Bon lundi à tous.
Jean-Pierre

Salut,

Voilà, j'ai installé ces modules, très bien très bien ! C'est ce qu'il nous fallait. Le bilan et compte de résultat marche très bien : c'est très agréable !
Du coup, j'ai repris ma compta depuis le début de l'année.

J'ai cependant une question.
Comment je fais pour une facture fournisseur correspondant à une livraison intracommunautaire ?

J'ai entré mes lignes de factures et pour la TVA de chaque ligne j'ai ces deux TVA :
- TVA due intracommunautaire 19.6% - TVA 19.6%
- TVA déductible intracommunautaire 19.6% - TVA 19.6%

(pq il faut bien payer la TVA et se la déduire, vive la France)

Mais :
- je sais pas si ce sont les bonnes taxes à mettre
- le calcul du total est alors faux, je devrais avoir seul le montant HT de la facture et du coup, j'ai deux fois la TVA à 19,6 en plus.

Qu'en dites vous ?

Bonjour,

il est peut-être encore un peu tôt pour reprendre toute sa comptabilité dès à présent !

Le mieux c'est d'essayer d'attendre un peu l'avis de tout le monde.
faire les dernières corrections et après on pourra l'utiliser pour "de vrai".

Ce sont les bonnes taxes.
Par contre là on s'attaque à de la vraie comptabilité. Faudrait demander à un expert.

D'après moi :

1 - Livraisons intracommunautaires :

Choisir la taxe : Livraisons intracommunautaires TVA 0%

2 - acquisitions intracommunautaires :

Pour l'enregistrement d'une facture (achat) intracommunautaire on devrait avoir :
un débit d'un compte 60x
un débit de la TVA déductible intra (445662)
un crédit de la TVA due intra (4452)
un crédit du compte : fournisseurs union européenne (40112)

Peut-être faudrait-il inverser les signes des taxes "TVA due intracommunautaire" par exemple passer la 19.6% à -0.196 au lieu de 0.196

Je pense qu'il faudrait faire des tests et vérifier si dans le plan comptable on a les bons montants dans les bons comptes.

Désolé, mais les limites de mes compétences comptables sont atteintes.
Je ne peux pas vous donner de réponse clair sur ce point.

juste mon grain de sel
Selon les règlements, on n'a pas le droit de passer des écritures sur les classes de comptes qui n'ont que 2 chiffres. J'en déduis que tout compte à 2 chiffres doit être en "vue" et doit comporter au moins un enfant.

Pour mes tests, j'ai effectué les corrections proposées et je pense qu'elles sont toutes bonnes.


En ce qui concerne le nom court, il faut être conscient que même si on ajoute le champ short_name à l'objet taxe dans le account.py, les formats de devis et factures modifiés ne pourront plus se passer du plan comptable français car ils utilisent alors le champ "short_name" qui n'existe pas par défaut. Sur des projets je n'ai pas de soucis, car je pense que tout le monde adapte les rapports devis et facture et ça rentre dans ma moulinette à spécifique. Soit le module l10n redéfinit les documents, soit il faut généraliser à tous les plans comptables OpenERP, enfin, je crois.

A+

Bon ben même sans expert comptable, avec les compétences de chacun, il y a moyen de corriger les dernières incohérences...

Plan comptable mis à jours en fonction des erreurs précédemment relevées.
Il ne reste plus que le "problème" des noms longs et courts !

D'un autre côté, quitte à faire du "had-hoc", autant ne modifier que le devis.
Au lieu d'afficher le nom complet, on affiche qu'une sous partie définie par l'expression régulière suivante :

print "TVA "+re.search('([0-9]+,?[0-9]*%)', t.name).group()

si t.name est égal à 'TVA immobilisation (achat) 19,6%' ça devrait donner comme résultat : 'TVA 19.6%'

PS:
ne pas oublier de rajouter :
import re
en début de rapport pour pouvoir utiliser les expressions régulières.

Je ne connais pas encore bcp python, mais ça devrait marcher.

J'essai d'installer le plan comptable en suivant la procédure de ChristianD (page 1 du thread) et le tinyerp me renvoit le message suivant :
ERROR: value too long for type character varying(16)

insert into "account_tax_code" (id,perm_id,"company_id","parent_id","code","name","sign",create_uid,create_date) values (8,NULL,'1','7','TVA coll

Quand je veux installer le module i10n_fr

Voila le détail de l'erreur :
Traceback (most recent call last):
File "netsvc.pyo", line 200, in _dispatch
File "service\web_services.pyo", line 422, in execute
File "service\web_services.pyo", line 402, in _execute
File "wizard\__init__.pyo", line 160, in execute
File "wizard\__init__.pyo", line 75, in execute_cr
File "C:\Program Files\TinyERP Server\addons\base\module\wizard\wizard_module_upgrade.py", line 80, in _upgrade_module
File "pooler.pyo", line 64, in restart_pool
File "pooler.pyo", line 53, in get_db_and_pool
File "addons\__init__.pyo", line 274, in load_modules
File "addons\__init__.pyo", line 221, in load_module_graph
File "tools\convert.pyo", line 665, in convert_xml_import
File "tools\convert.pyo", line 596, in parse
File "tools\convert.pyo", line 574, in _tag_record
File "C:\Program Files\TinyERP Server\addons\base\ir\ir_model.py", line 234, in _update
File "osv\orm.pyo", line 1189, in create
File "sql_db.pyo", line 73, in execute
ProgrammingError: ERROR: value too long for type character varying(16)

insert into "account_tax_code" (id,perm_id,"company_id","parent_id","code","name","sign",create_uid,create_date) values (8,NULL,'1','7','TVA coll

Que dois-je faire ???

Il aurait fallu arrêter le serveur.
Et ensuite le redémarrer.

Comment puis-je résoudre le problème ? JE viens de reprendre la procédure en arrétant/redémarrant le serveur et j'ai le même message.

Désolé de poser des questions peut-être basiques mais je débute avec OpenErp...