多币种最佳实践和实作 [英] Multi-Currency Best Practice & Implementation

问题描述

我发现很难找到有关处理多种货币的最佳做法的任何讨论。任何人都可以提供一些见识或链接以提供帮助吗？

I'm finding it difficult to find any discussion on best practices for dealing with multiple currencies. Can anyone provide some insight or links to help?

我知道可以通过多种方式进行此操作-无论是在事务中存储输入的值，还是在功能上您可以将其转换为基本费率。在这两种情况下，都需要存储汇率，以涵盖将来可能需要转换为每种货币的交易时间。

I understand there are a number of ways to do this - either transactionally where you store the value entered as is, or functionally where you convert to a base rate. In both cases the exchange rate is needed to be stored that covers that transactions time for each currency that it may need to be converted to in the future.

我喜欢灵活性交易方法，它允许在以后的日期输入旧汇率信息，但可能比功能方法具有更多的开销（因为您必须存储更多的汇率数据）。

I like the flexibility of the transactional approach, which allows old exchange rate info to be entered at a later date, but probably has more overhead (as you have to store more exchange rate data) than the functional approach.

性能和可伸缩性是主要因素。我们（所有.net）都赢了& Web客户端，报告套件和一组Web服务，这些功能为数据库后端提供功能。如果需要，我可以将汇率信息缓存在某个位置（例如，在客户端上）。

Performance & Scalability are major factors. We have (all .net) a win & web client, a reports suite and a set of web services that provide functionality to a database back-end. I can cache the exchange rate information somewhere (e.g. on client) if required.

编辑：我真的很想链接到一些文档，或包含

推荐答案

我找不到任何明确的讨论，因此我发表了自己的发现，我希望它能对某人有所帮助。

I couldn't find any definitive discussion, so I post my findings, I hope it helps someone.

货币表应包含文化代码以利用任何全球化类别。

The currency table should include the culture code to make use of any Globalisation Classes.

交易方法

• 以客户本地货币存储，并存储交易发生时应用的交易货币的多种转换率。


• 每种货币需要多种汇率


• 网站设置表将存储输入的货币


• 输入&在客户端级别输出值不会产生任何开销，因为可以假设值使用正确的货币


• 要应用汇率，您需要知道输入值的货币（ （对于跨客户报告而言可能有所不同），然后将其乘以在交易时间段内有效的关联实体汇率。

• Store in currency local to customer and store multiple conversion rates for the transaction currency that applied when the transaction occurred.
• Requires multiple exchange rates for each currency
• Site Settings table would store the input currency
• Input & Output of values at client level would have no overhead as it can be assumed the value is in the correct currency
• To apply exchange rates, you would need to know the currency of the entered values (which may be different for cross client reports), then multiply this by its associated entity exchange rate that was valid during the transactions time period.

功能方法

• 以一种基本货币存储，保持该货币在一段时间内的转换率


• 需要在前端和数据库之间的位置进行考虑，这是转换值的最佳位置


• 输入性能会受到一定程度的影响，因为需要进行基础货币的转换。汇率可能会缓存在客户端上（注意每个实体可能使用不同的汇率）


• 这需要一组汇率（从基本货币到所有其他必需货币）


• 要应用汇率，每笔交易都需要在基本货币和所需货币之间转换

• Store in one base currency, hold conversion rates for this currency that apply over time
• Consideration needs to be given at point between front end and database is the best place to convert values
• Input performance is marginally affected as a conversion to the base currency would need to take place. Exchange rate could be cached on the client (note each entity may use a different exchange rate)
• This required one set of exchange rates (from base to all other required currencies)
• To apply exchange rates, every transaction would need to be converted between the base and required currencies

复合

• 在交易时，存储交易价值和功能价值，因此不需要存储任何汇率信息。 （这不适合作为解决方案，因为它会有效地限制您使用任何给定值的两种货币）

比较

实际上，您必须在函数方法和事务方法之间进行选择。两者都有其优势和优势。缺点。

Realistically, you have to choose between function and transactional methods. Both have their advantages & disadvantages.

功能方法不需要存储本地货币进行交易，需要将当前的db值转换为基础货币，只需要一套汇率，就很难了

Functional method does not need to store local currency for transaction, needs to convert current db values to base currency, only needs one set of exchange rates, is slightly harder to implement and maintain though requires less storage.

事务处理方法要灵活得多，尽管它确实需要保留更多的汇率信息，并且每笔交易都需要关联输入货币（尽管可以将其应用于一组客户而不是每次交易）。由于本地货币仍将在本地使用，因此该解决方案易于实现和维护，因此通常不会影响已经在生产中的代码。尽管显然任何需要转换为其他货币的报告或值都会受到影响。

Transactions method is much more flexible, though it does require more exchange rate information to be held and each transaction needs to be associated with an input currency (though this can be applied to a group of customers rather than each transaction). It would generally not affect code already in production as local currencies would still be used at the local level making this solution easy to implement and maintain. Though obviously any reports or values needing to be converted to a different currency would be affected.

在两种情况下，每笔交易在交易时都需要汇率它需要转换成的货币–功能方法需要在交易时使用，但是交易方法具有更大的灵活性，因为可以随时输入过去的汇率数据（允许使用任何货币），
即

In both cases, each transaction would need exchange rates for the time of transaction for each currency it needs converting to – this is needed at point of transaction for functional method, however the transactional method allows more flexibility as past exchange rate data could be entered at any time (allowing any currency to be used), i.e. you lose the ability to use other exchange rates in the functional method.

结论

一种货币管理交易方法将提供一种灵活的方法，避免对客户端性能和零客户端代码修改造成任何负面影响。如果需要使用不同的货币，则在所有报表中都需要重新处理的报表中可能会产生负面的性能影响。
每个客户站点都需要存储货币参考，以说明其输入货币是什么。
应该有可能摆脱高水平存储汇率（例如一组客户站点等）的情况，这将使存储的数据量最小化。如果需要较低级别的汇率信息，则可能会发生问题。

A transactional method of currency management would provide a flexible approach, avoiding any negative impact on client performance and zero client code modification. A negative performance impact would likely occur in reports where all will need rework if different currencies are required. Each client site will need to store a currency reference that states what their input currency is. It should be possible to get away with storing exchange rates at a high level (e.g. a group of customer sites etc), this will minimise the amount of data stored. Problems may occur if exchange rate information is required at a lower level.

这篇关于多币种最佳实践和实作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！