Meilleures pratiques et implémentation multidevises
J'ai du mal à trouver une discussion sur les meilleures pratiques pour traiter avec plusieurs devises. Quelqu'un peut-il fournir des informations ou des liens pour aider?
Je comprends qu'il existe un certain nombre de façons de le faire - soit transactionnellement où vous stockez la valeur entrée telle quelle, soit fonctionnellement lorsque vous convertissez en un taux de base. Dans les deux cas, le taux de change doit être stocké pour couvrir le temps de transaction pour chaque devise dans laquelle il peut être nécessaire de la convertir à l'avenir.
J'aime la flexibilité de l'approche transactionnelle, qui permet de saisir les anciennes informations sur le taux de change à une date ultérieure, mais qui a probablement plus de frais généraux (car vous devez stocker plus de données sur le taux de change) que l'approche fonctionnelle.
Les performances et l'évolutivité sont des facteurs majeurs. Nous avons (tous .net) un client win & web, une suite de rapports et un ensemble de services web qui fournissent des fonctionnalités à un back-end de base de données. Je peux mettre en cache les informations sur le taux de change quelque part (par exemple sur le client) si nécessaire.
EDIT: Je voudrais vraiment des liens vers certains documents, ou des réponses qui incluent des "pièges" de l'expérience précédente.
Je n'ai trouvé aucune discussion définitive, alors je poste mes résultats, j'espère que cela aide quelqu'un.
Le tableau des devises doit inclure le code de culture pour utiliser toutes les classes de mondialisation.
Méthode transactionnelle
- Stockez dans la devise locale au client et stockez plusieurs taux de conversion pour la devise de transaction qui s'appliquait lorsque la transaction a eu lieu.
- Nécessite plusieurs taux de change pour chaque devise
- Le tableau des paramètres du site stockerait la devise d'entrée
- L'entrée et la sortie des valeurs au niveau du client n'auraient pas de frais généraux car on peut supposer que la valeur est dans la bonne devise
- Pour appliquer des taux de change, vous devez connaître la devise des valeurs saisies (qui peut être différente pour les rapports entre clients), puis multiplier celle-ci par le taux de change de l'entité associée qui était valide pendant la période des transactions.
Méthode fonctionnelle
- Stockez dans une devise de base, maintenez des taux de conversion pour cette devise qui s'appliquent dans le temps
- Il faut tenir compte du point entre le frontal et la base de données est le meilleur endroit pour convertir les valeurs
- Les performances des entrées sont légèrement affectées car une conversion vers la devise de base devrait avoir lieu. Le taux de change peut être mis en cache sur le client (notez que chaque entité peut utiliser un taux de change différent)
- Cela nécessitait un ensemble de taux de change (de la base à toutes les autres devises requises)
- Pour appliquer les taux de change, chaque transaction devrait être convertie entre la devise de base et les devises requises
Composite
- Au point de transaction, stockez la valeur transactionnelle et la valeur fonctionnelle, de cette façon, aucune information sur le taux de change ne devrait être stockée. (Ce ne serait pas une solution appropriée car elle vous limite effectivement à deux devises pour une valeur donnée)
Comparaison
De façon réaliste, vous devez choisir entre la fonction et les méthodes transactionnelles. Les deux ont leurs avantages et leurs inconvénients.
La méthode fonctionnelle n'a pas besoin de stocker la devise locale pour la transaction, doit convertir les valeurs actuelles de la base de données en devise de base, n'a besoin que d'un seul ensemble de taux de change, est légèrement plus difficile à mettre en œuvre et à maintenir, mais nécessite moins de stockage.
La méthode des transactions est beaucoup plus flexible, bien qu'elle nécessite plus d'informations sur le taux de change et que chaque transaction doit être associée à une devise d'entrée (bien que cela puisse être appliqué à un groupe de clients plutôt qu'à chaque transaction). Cela n'affecterait généralement pas le code déjà en production, car les monnaies locales seraient toujours utilisées au niveau local, ce qui rendrait cette solution facile à mettre en œuvre et à maintenir. Bien évidemment, tout rapport ou valeur devant être converti dans une autre devise serait affecté.
Dans les deux cas, chaque transaction aurait besoin de taux de change pour le moment de la transaction pour chaque devise dans laquelle elle doit être convertie - cela est nécessaire au point de transaction pour la méthode fonctionnelle, mais la méthode transactionnelle permet plus de flexibilité car les données de taux de change antérieures pourraient être entrées à à tout moment (permettant d'utiliser n'importe quelle devise), c'est-à-dire que vous perdez la possibilité d'utiliser d'autres taux de change dans la méthode fonctionnelle.
Conclusion
Une méthode transactionnelle de gestion des devises fournirait une approche flexible, évitant tout impact négatif sur les performances des clients et aucune modification du code client. Un impact négatif sur les performances se produirait probablement dans les rapports, où tous devront être retravaillés si différentes devises sont requises. Chaque site client devra stocker une référence de devise indiquant sa devise d'entrée. Il devrait être possible de s'en tirer avec le stockage des taux de change à un niveau élevé (par exemple, un groupe de sites clients, etc.), cela minimisera la quantité de données stockées. Des problèmes peuvent survenir si des informations sur le taux de change sont requises à un niveau inférieur.
Il n'y a pas de réponse unique, car cela dépend beaucoup de la façon dont une entreprise gère les transactions dans ces devises. Certaines entreprises utilisent des méthodes assez sophistiquées pour gérer les devises étrangères. Je vous suggère de lire sur la comptabilité multidevise.
La principale chose à faire est de capturer les données dans l'unité, la valeur et la date à laquelle la transaction commerciale est effectuée sans aucune conversion, ou vous risquez de perdre quelque chose en traduction. Pour l'affichage et les rapports, convertissez à la demande, en utilisant soit le taux de change d'origine, soit tout autre taux de change selon l'intention de l'utilisateur.
Stockez et calculez avec des valeurs de type 'décimal' (en C #) - n'utilisez pas float/double ou vous vous exposez à des erreurs d'arrondi.
Par exemple, la façon dont je faisais une application multi-devises dans une vie antérieure était:
- Chaque jour, les taux de change du jour étaient fixés et stockés dans une base de données et mis en cache pour la conversion dans l'application.
- Toutes les transactions seraient capturées sous forme de valeur + devise + date (c.-à-d. Pas de conversion)
- L'affichage de la transaction dans la devise d'un utilisateur a été effectué à la volée. Indiquez clairement qu'il ne s'agit pas de la devise de transaction, mais d'une devise d'affichage. Cela ressemble à un relevé de carte de crédit lorsque vous partez en vacances. Il indique le montant de la transaction à l'étranger, puis combien cela finit par vous coûter dans votre devise d'origine.
Notre entreprise gère la comptabilité et la budgétisation en plusieurs devises. La solution que nous avons implémentée est assez simple et comprend les éléments suivants:
une table de devises, avec quelques champs comprenant le nombre de décimales à prendre en compte pour la devise (oui, certaines devises doivent être gérées avec 3 décimales ...) et une valeur de taux de change, qui n'a d'autre signification que d'être une proposition/taux de change par défaut "lors de l'évaluation des transactions financières" non exécutées "ou" en attente "(voir infra)
Dans ce tableau des devises, l'un des enregistrements a un taux de change de 1. Il s'agit de la devise principale/pivot de notre système
Toutes les transactions financières, ou toutes les opérations ayant une dimension financière (ce que nous appelons des engagements dans notre langue), sont soit triées comme "en attente" ou "exécutées":
Les transactions en attente sont par exemple des factures qui devraient être reçues pour un certain montant à une certaine date. Dans notre système de suivi budgétaire, ces montants sont toujours réévalués en fonction du "taux de change proposé/par défaut" disponible dans le tableau des devises.
Les transactions exécutées sont toujours enregistrées avec la date d'exécution, le montant, la devise ET taux de change, qui doit être confirmé/tapé lors de la saisie des données d'exécution.
(Je suppose que vous savez déjà que vous ne devriez certainement pas stocker les données monétaires en tant que flottant et pourquoi)
À mon avis, travailler avec une monnaie de base unique pourrait être plus facile; cependant, vous devez enregistrer le montant d'origine, la devise d'origine, le taux de conversion et le montant de la devise de base, sinon votre service de comptabilité. pourrait vous manger vivant, car ils sont susceptibles de garder différentes devises en quelque sorte séparément.
Étant donné que les taux de change fluctuent, une approche est celle que vous avez mentionnée: enregistrez un montant "entré tel quel" qui n'est pas converti, mais affichez un champ complémentaire qui s'affiche uniquement et affiche le montant converti. Pour effectuer la conversion, un tableau des taux de change et leurs plages de dates applicables seraient nécessaires. Si la taille de ceci est petite, la mise en cache sur le client est une option. Sinon, un appel à distance serait nécessaire pour effectuer la conversion.