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

[Laurent Destailleur (Eldy)]

Christophe wrote:

> 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.
>
>  
Helas, c'est pourtant vers cela qu'il faudra aller. En effet, la 
réglementation des factures impose que dans une facture le total de tva 
soit affiché non pas de manière global mais au detail par ligne de facture.
Ce que ne fait pas dolibarr a ce jour car le detail total_ht, total_ttc 
et total_tva est stocké au niveau de la facture et non de la ligne. Il 
faudra pourtant ajouter ces infos. C'est de plus requis pour gérer sans 
perte les arrondis lors du calcul des tva. En effet, l'arrondi de la 
somme des lignes (faite au niveau de la facture) ne donne pas une info 
exacte car différente de la somme des arrondis des lignes. Et c'est ce 
dernier cas qui est requis pour avoir un logiciel.

> 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.
>  
En effet, il faut ajouter total_ht et total_tva dans les detail des 
factures, commandes, contrats et propales.

> 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.
>  
C'est en effet plus simple, mais la premiere est meilleure pour les 
raison evoqués au dessus également.
De plus, l'evol du point avant permettra de resoudre d'autres points 
bloquant pour la compta (le detail est également requis pour les 
ventilations de tva).

> 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.
>  
Aie... :-(

J'espère que tu as gardé tes sources.   :-)

> > - 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 ;-)
>  
En effet, ca me semblait utile pour l'administrateur de comprendre la 
raison de ces différents taux.

> > 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 ?
>  
Fait.

> J'attends de vos nouvelles pour savoir dans quel sens je poursuis.
>  
Si y a d'autres avis, faut les remonter assez vite car Christophe me 
semble chaud....  :-)

--
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
Web: http://destailleur.fr
IM: IRC=Eldy, Jabber=Eldy

AWStats (Auteur) : http://awstats.sourceforge.net
Dolibarr (Contributeur) : http//dolibarr.com
CVSChangeLogBuilder (Auteur) : http://cvschangelogb.sourceforge.net
AWBot (Auteur) : http://awbot.sourceforge.net