Un logiciel métier doit définir l’unité, la précision et la règle d’arrondi avant de calculer un prix, une taxe ou un total.
Un écart d’un centime peut sembler insignifiant jusqu’à ce qu’il apparaisse dans une facture, un export comptable et un rapprochement bancaire. Les erreurs viennent souvent d’une règle implicite : un prix stocké comme nombre décimal, une taxe arrondie par ligne ou seulement sur le total, ou une conversion de devise effectuée au mauvais moment.
Écrivez la règle avant de choisir le type technique. Le logiciel doit savoir quelles valeurs sont saisies, quelles valeurs sont calculées et quelle précision doit être conservée. Une règle différente peut être nécessaire pour un prix unitaire, une remise, une taxe et un total.
Définir l’unité et la précision
Décidez si les montants sont conservés dans l’unité monétaire ou dans une sous-unité entière. Pour une devise qui utilise deux décimales, une valeur entière en centimes peut éviter certaines erreurs de représentation. Une quantité avec trois décimales ne peut pas utiliser la même règle sans perdre de précision.
Le prix affiché et le prix stocké peuvent avoir des précisions différentes. Une interface qui montre deux décimales ne doit pas forcément arrondir la valeur originale avant le calcul. Documentez ce que l’utilisateur voit et ce qui est utilisé pour le total.
Les taux et pourcentages méritent aussi une précision définie. Un taux de taxe arrondi trop tôt peut modifier le total sur une série de lignes. Conservez la précision nécessaire, puis appliquez la règle au point prévu par le métier.
Choisir le moment de l’arrondi
Pour une facture, l’entreprise peut arrondir chaque ligne, le montant de taxe par ligne ou le total général. Deux règles différentes donnent des résultats différents. Le logiciel doit appliquer une seule règle pour l’affichage, l’export et l’écriture comptable.
Un total peut être calculé comme la somme des lignes arrondies ou comme l’arrondi de la somme des lignes non arrondies. L’écart doit être accepté par le métier et visible dans les exemples de recette. Ne laissez pas chaque écran choisir son propre calcul.
Une remise proportionnelle peut créer une fraction de centime. Décidez qui supporte l’écart et où il apparaît. Pour une commande divisée entre plusieurs lignes, la règle peut distribuer le reste selon un ordre stable, avec une explication dans le détail si l’utilisateur doit le vérifier.
Gérer les taxes et devises
Une taxe dépend de la base, du taux et du contexte. Une ligne exonérée ne doit pas être traitée comme une ligne à taux zéro sans conserver la raison attendue. Les catégories doivent être contrôlées par une règle métier, pas uniquement par une valeur saisie dans un tableur.
Une conversion de devise doit conserver le taux, la date et la source de la conversion utilisés. Le montant original doit rester disponible lorsque l’entreprise doit retrouver la valeur saisie. Un export qui ne montre que le montant converti peut rendre le rapprochement impossible.
Les taux peuvent changer entre le devis et la facture. Décidez si le taux est figé à la date du document ou recalculé à la date d’émission. Une modification de la règle doit créer une nouvelle version ou un événement qui explique le changement, comme dans la gestion des versions de documents.
Tester avec des exemples limites
Préparez des montants proches de la moitié d’un centime, des remises élevées, des quantités fractionnaires et un total nul. Ajoutez plusieurs lignes dont les taxes produisent un reste. Comparez l’écran, la base, le PDF, l’export et l’intégration comptable.
Testez aussi une valeur négative, une note de crédit et une facture annulée. Les signes et les règles d’arrondi doivent rester cohérents. Une correction de montant ne doit pas modifier silencieusement le document déjà validé.
Les tests doivent utiliser des résultats attendus écrits par une personne responsable de la règle. Un développeur peut calculer le résultat de façon cohérente avec son code, mais ce code peut appliquer la mauvaise convention pour l’entreprise.
Éviter les conversions invisibles
Les formats d’affichage peuvent remplacer une virgule par un point ou inversement. Le serveur doit recevoir une valeur normalisée et refuser une entrée ambiguë. Un import CSV doit préciser le séparateur décimal et le format accepté.
Les systèmes externes peuvent représenter les montants comme chaînes, nombres ou unités mineures. Le contrat d’API doit définir ce choix. Une intégration qui convertit deux fois un montant peut produire un total cent fois trop grand. Les tests de contrat API doivent couvrir un montant simple et un montant avec plusieurs décimales.
Conserver l’explication du total
Un utilisateur doit pouvoir retrouver le prix, la quantité, la remise, le taux, la taxe et le montant final. Un total sans détail rend la vérification difficile. Le système peut conserver un instantané des valeurs utilisées, surtout lorsque les catalogues et taux évoluent.
Les journaux doivent enregistrer les changements sensibles sans dupliquer tout le document. Le journal d’audit peut indiquer l’ancien et le nouveau total, l’auteur et la raison, selon la politique de données.
Un calcul monétaire fiable est une règle partagée entre le métier, l’interface, la base et les intégrations. Les exemples limites révèlent rapidement les divergences et évitent qu’un petit écart devienne une série de corrections manuelles.
Sources : Martin Fowler, représentation de l’argent, Python, module decimal.