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: Sat, 20 Aug 2005 14:15:37 -0400

Le samedi 20 août 2005 à 19:18 +0200, Laurent Destailleur (Eldy) a
écrit :
> 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.

Ah ! Bon, ben alors, je ne me sens pas de taille.
Les différents modules
facture/propal/commande/contrat/facture_rec/facture_fourn etc ont trop
de manque d'homonénéïté entre eux. Et c'est pareil pour les tables, y
compris dans les noms des champs.
Pour faire une telle modif, faut comprendre parfaitement comment chaque
chose fonctionne en détail. Et seul, comme je l'ai été depuis le début
sur ce coup là, malgré mes nombreux appel à l'aide, y compris par mail
privé, je ne me vois pas m'aventurer là dedans.

> En effet, il faut ajouter total_ht et total_tva dans les detail des 
> factures, commandes, contrats et propales.

S'il n'y avait que ça...
Donc, comme je te l'ai dit par mail, et contrairement à ce que tu
annonçais au départ, c'est finalement un assez gros chantier.
Trop gros pour moi pour l'instant, désolé.

> C'est en effet plus simple, mais la premiere est meilleure pour les 
> raison evoqués au dessus également.

C'est largement plus simple. J'ai pu le faire en très peu d'heures, et à
priori c'est fonctionnel, alors qu'avec l'autre, une journée de 15h ne
m'avait pas suffit, et c'était encore bien incomplet.

> >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.   :-)

Non, juste un patch, mais que je n'appliquerai pas. Je n'aime pas la
méthode que j'ai employée, c'est du bidouillage, et ça ne peut en aucune
manière être efficace. C'est de toutes les façons source de troubles, y
compris pour ceux qui n'utiliseraient pas ces taxes. Donc trop risqué
pour moi.
Selon moi, pour engager une telle réforme, il aurait fallu, au
préalable, revoir précisément les formats des tables et les classes,
pour rendre les choses homogènes et cohérentes entre les différents
modules. En effet, certaines classes utilisent la fonction calcul_price,
d'autres pas. Certaines fiches utilisent pleinement les classes,
d'autres font leurs propres requêtes. Le montant HT est dans une table
"price", sans une autre "total_hc", dans une 3ième "amount", et c'est
pareil pour le taux de tva ("txtva","taux_tva"...).
Je ne critique pas, car je sais très bien que ça vient de la
multiplicité des codeurs, je constate.
Par contre, en tant que codeur non officiel, personnellement, avant de
coder quelque chose, j'étudie comment ont fait les autres, même dans la
façon d'indenter (même si elle ne me plaît pas), afin de rester cohérent
avec le développement global. C'est simplement dommage que tout le monde
ne fasse pas comme ça.
L'idéal, mais déjà dit, serait une doc développeur fournie, à laquelle
se référer pour toutes ces choses, mais bon.

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

Ça m'avait initialement semblé utile, mais pas pour les mêmes
raisons. ;-)

> >A mettre dans le script mysql de migration non ?
> >  
> >
> Fait.

Ok.

> Si y a d'autres avis, faut les remonter assez vite car Christophe me 
> semble chaud....  :-)

Toujours. C'est probablement mon immense défaut, mais je ne sais pas
attendre, surtout quand je sais faire par moi même, et même quand je ne
sais pas trop, la preuve ;-)

-- 
Christophe





reply via email to

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