dolibarr-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-dev] Re: utilisation de la tva (nouvelle table)


From: Christophe
Subject: Re: [Dolibarr-dev] Re: utilisation de la tva (nouvelle table)
Date: Fri, 19 Aug 2005 19:02:05 -0400

Le samedi 20 août 2005 à 00:34 +0200, Laurent Destailleur (Eldy) a
écrit :
> J'ai intégré les patch de Christophe pour la gestion de la tva qui 
> apporte les 2 évols suivantes :

Ah, bien. En fait, j'avais envoyé aussi un autre gros patch ou j'avais
modifié plein de choses pour tenir compte de cette vta avec le (*), mais
il a été bloqué car pièce jointe trop grosse.
Un bonne chose, car après plusieurs heures, je l'ai annulé. Je n'étais
pas satisfait de la méthode.
J'avais tenté de suivre ton conseil, mais c'était finalement beaucoup
trop lourd, trop complexe, et sujet à trop de bugs futurs.
En effet, j'avais introduit un champ total_ttc dans pas mal de table, et
c'était la comparaison entre le total ht et le total ttc qui me
permettait de savoir quelle tva avait été appliquée, si c'était une TVA
8.5% normale, ou une TVA 8.5% non perçue récupérable.

J'ai alors vu 2 autre solutions.
Une première qui serait de mettre un champ booléen "recuperableonly" à
toutes ces tables. L'avantage par rapport au total_ttc, c'est qu'une
modif du montant de l'article, la ligne de
facture/propal/contrat/commande n'a pas à être répercutée sur ce champ.
L'inconvénient, c'est que ça implique une modif de pas mal de tables, et
de pas mal de classes, avec toujours le risque d'oublier des choses.

L'autre solution, et que j'adopterai si j'ai votre bénédiction, c'est de
transporter cette information avec la tva elle même. Or, pour ne pas
changer encore tous les champs TVA de toutes les tables, ça ne peut pas
être un "8.5*" qui serait un string au lieu d'un double.
La solution que j'envisage, c'est de mettre cette tva en négatif
lorsqu'elle est en recuperableonly.
Du coup, les tables ne sont pas modifiées, tout continue à fonctionner
pour tout le monde sauf moi pendant mes modifs, même si j'oublie des
choses.
C'est juste une modif des classes, lors du calcul des montant ttc et du
montant TVA, qu'il faut prendre le taux de TVA en valeur absolue, et ne
pas l'appliquer au TTC si ce taux est < 0.

Je pense que c'est la meilleure méthode.
Mais évidemment, comme ça concerne tout dolibarr, et tout développement
futur, il faut que vous soyez d'accord, et que vous soyez prêt à
respecter ce concept lors de tout développement futur en rapport avec la
tva.
Je n'ai pas eu le temps de m'en occuper aujourd'hui (après la journée
d'hier entière passée sur mes total_ttc pour rien), mais si j'ai votre
accord, je m'y met très rapidement.

> - Les différents taux de tva sont stockées dans llx_c_tva, ce qui permet 
> de centraliser la configuration dans les tables llx_c_xxx et donc 
> d'administrer cela depuis la page de configuration des dictionnaires. Le 
> dictionnaire "Taux de tva" a été ajouté.
> - Possibilité de gérer des taux de tva uniquement récupérés mais non 
> facturés (cas de certains regions des DOM comme la martinique). Le 
> mécanisme n'est pas encore complet pour ces régions mais presque. Notons 
> que seul les taux à 0, 5.5 et 19.6 sont actifs par défaut pour la 
> France, et 0, 6 et 21 pour la Belgique. Les utilisateurs des DOM doivent 
> donc aller dans le dictionnaire pour activer les taux spéciaux.

Je vois que tu as rajouté une note, comme quoi, mon affaire de libellé
n'était pas si stupide ;-)

> J'ai fait quelques modifs au patch proposé par Christophe, en général 
> pour des raisons esthétiques. J'ai renommé le champ recuperable en 
> recuperableonly car tous les taux, meme les spéciaux sont récupérables. 
> Les spéciaux (le 8.5 de martinique), sont récupérable UNIQUEMENT et non 
> facturable. Aussi le terme recuperableonly me semblait plus propre.

Tout à fait. Je ne voulais juste pas faire trop long, et je n'avais pas
pensé au terme anglais 'only'.

> Pour etre compatible avec les derniers cvs, il faut passer la migration 
> suivante :

A mettre dans le script mysql de migration non ?

J'attends de vos nouvelles pour savoir dans quel sens je poursuis.

-- 
Christophe





reply via email to

[Prev in Thread] Current Thread [Next in Thread]