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

[Christophe]

Le vendredi 19 août 2005 à 19:02 -0400, Christophe a écrit :
> J'attends de vos nouvelles pour savoir dans quel sens je poursuis.

J'ai malgré tout poursuivi, en espérant vivement que ma proposition soit
acceptée.

Je vous propose le patch joint, qui met en place l'utilisation de cette
tva négative, et qui corrige quelque bugs que je crois avoir trouvé ici
et là.

J'espère avoir traité tous les cas, factures client et fournisseur,
factures récurrentes, commandes, propal...

Par contre, avec la limite à 40Ko des mails sur la liste, je crains fort
qu'il ne doive passer par la validation du modérateur, comme le
précédent. Au cas où, je me permet de mettre Laurent en copie de ce
mail.

Pour la tva négative, personnellement, ça ne me gêne pas qu'elle
s'affiche de la sorte, mais si cela doit poser un problème, c'est
évidemment seulement la valeur d'affichage du select_tva() qui serait à
modifier, en laissant le value="" en négatif.

De même, je n'ai pas trop vu l'intérêt de la table facture_tva_sum, qui
ne semble utilisée que pour la fonction getSumTva(), elle même utilisée
uniquement dans le modèle de facture pdf_bernique.modules.php.
Il y avait pourtant des moyens beaucoup plus simples de récupérer les
différentes lignes de tva, comme je l'ai fait dans mes factures et
propals, sans passer par la gestion d'une table supplémentaire, et d'une
fonction spécifique.
A moins que cette table doive trouver son utilité dans la suite des
développement.
Mais du coup, je n'ai pas su si je devais y enregistrer mon -8.5% et
8.5% en une même ligne ou pas.
D'où le commentaire dans price.lib.php :
// s'il faut rassembler les tva facturables ou non, du même taux
// dans un même ligne du tableau, remplacer la ligne suivante par :
//                      $result[5][abs($prod_txtva)] += $line_tva;
                        $result[5][$prod_txtva] += $line_tva;

Autre petit commentaire à destination de Laurent, je n'ai pas bien
compris pourquoi avoir passé le champ "recuperableonly" en integer au
lieu du enum que j'avais mis, dans la table c_tva. Mais bon, c'est un
détail et c'est juste pour info.
A ce sujet, j'ai bien aimé l'idée du oui/non sur ce champ, dans le
dictionnaire. Mais pourquoi ne pas avoir mis un alias genre :
recuperableonly as yesno
de façon à pouvoir utiliser cette traduction pour d'autres
dictionnaires, comme ça semble être le principe pour d'autres champs ?

Merci de votre attention.

-- 
Christophe

novazur_tva_v1.2.patch
Description: Text Data