Discussion :

[FRED.G]

Bonjour,

La question que je me pose concerne certains champs calculés de mes factures :

sur chaque facture, je fais apparaître bien entendu le Total HT et le Total TTC de la facture.

Mais je distingue ces totaux, du "Total à payer".

Le montant Total à payer correspond au Total TTC de la facture + un "solde à reporter".

Ce solde correspond tout simplement au "Total à payer" de la précédente facture, diminué de tous les paimements enregistrés depuis l'édition de la précédente facture.

Cela donne ces champs :

A Dernier montant dû au xx/xx/xx
B Total des paiements enregistrés entre le xx/xx/xx et aujourd'hui
C solde à reporter (A - B)

D Total HT
E Total TTC

F Total à payer (E + C)


Jusqu'à présent, tous ces champs (A à F) étaient des champs calculés.
Mais avec le temps et l'accumulation des montants, j'arrive à des problèmes d'arrondis lorsque je fais les sommes totales de ces montants à partir à enregistrements correspondant au détails de mes factures.

Ainsi, j'obtiens un solde à reporter de 199,99 € au lieu de 200,00 €

La solution serait de stocker "en dur" pour chaque facture certains champs arrondis correctement, pour faire ensuite mes sommes globales à partir d'eux (et non du détails de chaque facture).


Quels pourraient être ces champs ? Simplement le Total TTC de la facture ?

Comment gérez-vous ce cas de figure (solde à reporter sur les facture) généralement ?


Merci d'avoir lu jusqu'au bout.

[ego]

N'as-tu pas en fait 2 solutions :
- soit tu stocke le dernier montant dû d'une fois sur l'autre et tu reprends donc ton calcul pour le mois en cours auquel tu ajouteras en fin le dernier montant dû stocké.
- soit tu ne stockes rien mais tu es obligé de refaire les calculs exactement dans le même ordre que ce que tu avais fait le mois d'avant. Mais comme le mois d'avant tu n'avais rien stocké aussi, tu dois revenir 2 mois avant et comme 2 mois avant tu n'avais rien stocké ......et ainsi de suite jusqu'à arriver au début de l'existance de ton application.

Bref, la solution n'est-elle pas finalement de stocker la facture elle-même sous forme "d'objet" dans lequel tu auras entre autre le dernier montant restant dû ?

[FRED.G]

Tu as bien compris la situation et je pense opter pour la première option que tu décris : stocker le "Dernier montant dû" dans l'enregistrement correspondant à une facture.

C'est le plus efficace / pratique.

Merci pour ton avis.

[Maxence HUBICHE]

Question....
dans les champs qui te servent aux calcul, tu n'aurais pas des Réel simple ou double ?

[FRED.G]

Je travaille avec Access et j'utilise des Currency pour mes valeurs monétaires.

Mais quand même je vais vérifier !

[Maxence HUBICHE]

Currency a une précision à 4 décimales.
Single et Double sont approchants.
Je suppose que tu les utilises pour les TAUX (notamment TVA) or, si tu utilise un calcul avec un Single ou un Double, tu auras un résultat approchant. Y compris si tu le stocke dans un currency.
Ce qui ne modifiera en rien ton problème, donc.

Je préconise de vérifier les types de données lors du calcul, de manière à t'assurer que tu n'iaes jamais plus de 2 décimales.
Par exemple, une conversion en LONG (Clng) de ton calcul * 100, le tout redivisé par 100

[FRED.G]

En fait dans mes tables, les champs sont toujours en currency. Ensuite à l'affichage dans l'état, j'utilise la fonction de conversion Ccur pour les contrôles servant aux calculs et à l'affichage des montants.

Cependant il peut y avoir des contrôles intermédiares dans l'état où je n'utilise pas cette fonction de conversion. Tout simplement parcequ'ils dépendent directement de champs ou de calculs basés sur des champs de type Currency, ou sur des contrôles calculés convertis avec Ccur().

[FRED.G]

Je viens lire ta réponse précédente.

Donc tu as raison pour les taux de TVA en réel double.

Par contre même si je règle mon problème d'arrondi avec ta solution, que penses-tu de l'idée de stocker en 'dur' des champs 'calculés' ?

[Maxence HUBICHE]

Je n'aime pas du tout la solution du stockage en dur des résultats sur du long terme parce que, ca peut donner ceci :

ID - NB - PU - TOTAL
1 - 3 - 10 - 30

et puis, voilà que, pour une raison quelconque :

• le traitement de mise à jour ne se fait pas...

Tu obtiens donc
ID - NB - PU - TOTAL
1 - 3 - 10 - NULL

• un accès extérieur aux données modifie une données

Tu obtiens
ID - NB - PU - TOTAL
1 - 3 - 9 - 30


Etc.
Bref, le mieux : le calcul dynamique.

[FRED.G]

Le calcul dynamique est la solution pour laquelle j'avais opté dans la précédente version de mon appli.
Vu que tu m'as expliqué comment résoudre le problème des arrondis, je vais pouvoir la maintenir.