Bienvenue, Invité
Nom d'utilisateur : Mot de passe : Se souvenir de moi

SUJET : Limites & precision module charges sociales

Limites & precision module charges sociales il y a 2 ans 8 mois #78931

  • RotPerp
  • Portrait de RotPerp
  • Hors ligne
  • Fresh Boarder
  • Messages : 2
  • Karma: 0
détecté en version 3.8:
dans le module taxe et charges sociales les champs montants (amount) dans certaines tables comme llx_chargessociales, llx_paiementcharges sont typés en real dans postgresql hors ce type est sur 4 octets avec une précision de 6 digits
donc toute charge de plus de 9999.99 € se retrouve arrondie sur 6 digits
exemple: 11111.11 devient 11111.10, 111111.11 devient 111111.00, 1111111.11 devient 1111110.00, etc
est-il possible de les modifier en type double precision dans la base sans perturber le fonctionnement de dolibarr?
est-ce corrigé dans les versions supérieures?
Dernière édition: il y a 2 ans 8 mois par RotPerp.
L'administrateur a désactivé l'accès en écriture pour le public.

Limites & precision module charges sociales il y a 2 ans 3 mois #84825

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
Une réponse plus détailée nécessiterait plus de temps, mais a priori, dans PostgreSQL, les valeurs comptables doivent être de type "numeric":

www.postgresql.org/docs/10/static/dataty...type-numeric-decimal
The type numeric can store numbers with a very large number of digits. It is especially recommended for storing monetary amounts and other quantities where exactness is required. Calculations with numeric values yield exact results where possible, e.g. addition, subtraction, multiplication. However, calculations on numeric values are very slow compared to the integer types, or to the floating-point types described in the next section.
L'administrateur a désactivé l'accès en écriture pour le public.
Cet utilisateur a été remercié pour son message par: RotPerp

Limites & precision module charges sociales il y a 2 ans 3 mois #84976

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
MySQL est également impacté :
dev.mysql.com/doc/refman/5.7/en/floating-point-types.html
MySQL permits a nonstandard syntax: FLOAT(M,D) or REAL(M,D) or DOUBLE PRECISION(M,D). Here, (M,D) means than values can be stored with up to M digits in total, of which D digits may be after the decimal point. For example, a column defined as FLOAT(7,4) will look like -999.9999 when displayed. MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.

dev.mysql.com/doc/refman/5.7/en/fixed-point-types.html :
The DECIMAL and NUMERIC types store exact numeric data values. These types are used when it is important to preserve exact precision, for example with monetary data. In MySQL, NUMERIC is implemented as DECIMAL, so the following remarks about DECIMAL apply equally to NUMERIC.


Une vérification rapide montre que pour stocker un montant monétaire, certains modules de Dolibarr utilisent un champ real alors que d'autres modules sont codée en numeric :

llx_paiement => numeric
llx_don = real

Le seul codage acceptable pour un montant monéraire est "numeric".

Je vais proposer un correctif pour le core et en discuter avec les développeurs.
L'impact est important ... et je ne pense pas qu'un correctif soit disponible avant une mise à jour majeure.

Par contre, si vous êtes très pressés et ne pouvez pas attendre, il est possible d'utiliser un éditeur SQL (tel que pgAdmin3), pour transtyper les valeur real en numeric à l'aide de la requête suivante :

ALTER TABLE nom_table
ALTER COLUMN nom_colonne TYPE numeric;

Par exemple :
ALTER TABLE public.llx_don
ALTER COLUMN amount TYPE numeric;

Attention qu'un transtypage pourrait résulter en un arrondi.
Il se peut donc que certaines opérations comptables auparavant soldées laissent apparaître un écart minime.

Avant de procéder, faire un backup sur disque et sur média inaltérable ...

Comme je suis nouveau dans la communauté, je vais mener une investigation complète du code et proposer un correctif. Si vous ne connaissez pas SQL, ne faites rien et attendez le retour de la communauté.
Dernière édition: il y a 2 ans 3 mois par fperou.
L'administrateur a désactivé l'accès en écriture pour le public.
Cet utilisateur a été remercié pour son message par: RotPerp

Limites & precision module charges sociales il y a 2 ans 3 mois #84980

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
Je vais soumettre un patch :
github.com/Dolibarr/dolibarr/issues/7013
Dernière édition: il y a 2 ans 3 mois par fperou.
L'administrateur a désactivé l'accès en écriture pour le public.
Cet utilisateur a été remercié pour son message par: RotPerp

Limites & precision module charges sociales il y a 2 ans 3 mois #85023

  • fperou
  • Portrait de fperou
  • Hors ligne
  • Senior Boarder
  • Développeur indépendant, gestion/comptabilité
  • Messages : 50
  • Remerciements reçus 5
  • Karma: 3
Okay, j'ai compris. Les normes ne sont pas définies et certains développeurs ont utilisé real:
wiki.dolibarr.org/index.php/Langages_et_normes

Il faut ajouter
- numeric(24,8) pour une valeur monétaire
L'administrateur a désactivé l'accès en écriture pour le public.