Un catalogue doit séparer le produit, le prix, la devise, la période de validité et les règles qui déterminent le montant affiché.
Un changement de prix ne doit pas modifier silencieusement un devis déjà envoyé. Conservez la version du tarif utilisée et la date d’effet. Une commande peut référencer un prix historique tout en utilisant le catalogue courant pour les nouvelles demandes.
Définir les règles
Indiquez les unités, taxes, remises et arrondis. Une règle égale au seuil doit avoir un résultat précis. Les calculs monétaires doivent être identiques dans l’écran, le PDF et l’API.
Contrôler la visibilité
Un tarif client peut être différent d’un tarif public. Le serveur choisit la liste selon l’espace, le rôle et le contrat. Un cache doit inclure ces paramètres pour éviter de partager un montant.
Tester les changements
Testez une date future, une devise, un produit archivé, une remise et une quantité fractionnaire. Vérifiez les exports et les documents déjà validés. Une correction doit conserver une trace et une raison.
Sources : Martin Fowler, Money, OWASP, autorisation.
Planifier un tarif
Une nouvelle valeur peut être publiée à une date future. Affichez l’ancienne, la nouvelle, la devise et la règle d’arrondi. Les devis déjà envoyés conservent le tarif utilisé ou sont recalculés seulement selon une procédure explicite.
Un catalogue peut contenir des prix par client, volume ou période. Vérifiez les intervalles qui se recouvrent et les valeurs sans règle. Un produit archivé ne doit pas disparaître d’une facture historique.
Tester les intégrations
Comparez le catalogue, les devis, les factures, les exports et les appels API. Une répétition ne doit pas appliquer une remise deux fois. Journalisez les changements sensibles et limitez l’accès aux tarifs confidentiels.