多币种最佳实践及实施

Question

多币种最佳实践及实施

currency

67

我很难找到关于处理多种货币最佳实践的讨论。能否提供一些见解或链接来帮助？

我了解有多种方法可以做到这一点-事务性地存储输入值或功能性地将其转换为基准汇率。在两种情况下，都需要存储包括未来可能需要转换成的每种货币在内的交易时间所涉及的汇率。

我喜欢事务性方法的灵活性，它允许稍后输入旧的汇率信息，但可能比功能性方法需要更多的开销（因为您必须存储更多的汇率数据）。

性能和可扩展性是重要因素。我们拥有（全部 .net）一个win和web客户端、一个报告套件以及一组Web服务，为数据库后端提供功能。如果需要，我可以在某个地方缓存汇率信息（例如在客户端）。

编辑：我真的希望提供一些文档链接或包括以前经验中的“陷阱”的答案。

- Mr Shoubs

我发现了一份来自Peter Selinger的好教程，可能会有所帮助。http://www.mathstat.dal.ca/~selinger/accounting/tutorial.html - Maske

5个回答

19

没有一个单一的答案，因为这很大程度上取决于企业处理这些货币交易的方式。一些公司使用相当复杂的方法来管理外汇。我建议您阅读关于多币种会计的资料。

主要做法是在不进行任何转换的情况下捕获业务交易中的单位、价值和日期数据，否则可能会在翻译过程中丢失信息。对于展示和报告，根据用户意图，使用原始汇率或其他汇率进行按需转换。

使用“Decimal”类型（在C#中）存储和计算数值-不要使用float/double，否则可能会遭受舍入误差的风险。

例如，我以前开发的多货币应用程序的处理方式如下：

每天，当日的汇率将被设置并存储在数据库中，并进行缓存以便在应用程序中进行转换。
所有交易将被捕获为价值+货币+日期（即没有转换）。
在用户的货币中显示交易是即时完成的。请明确说明这不是交易货币，而是一个展示货币。这类似于您去度假时的信用卡账单。它显示外币交易金额，然后显示您在本地货币中的实际花费。

- Frederik

7

每天没有“一个汇率”。这个概念不适用于现实生活中，因为在同一天内，您可以以两种不同的汇率从银行购买欧元。 - Philippe Grondier

2

有趣的观点。你说的大部分都没有考虑到这方面的开销。我们的大多数客户将拥有一组涵盖3-6个月的固定汇率。这似乎是大公司的做法。由于我们没有一个业务，我们需要一个标准化的方法。我不太明白你所说的“在翻译中失去某些东西”的意思 - 只要您在交易发生时拥有有效的汇率，就不会有这个问题。 - Mr Shoubs

+1 对于好的回答，但我不确定它是否是我们软件的最佳方法。 - Mr Shoubs

#Philippe - 你会发现很多大企业用特定汇率购买大量货币，然后为内部使用设置自己的汇率。 - Mr Shoubs

2

Philippe，每天使用一个汇率是业务决策，并适合业务管理和谈判交易的方式。您说汇率波动是正确的，这是货币交易市场的结果。通常，企业不直接与市场打交道，而是使用中介（银行/经纪人）。根据与中介的安排，将添加一定的加价到汇率，并在某些时间（每日、每周等）发生，这意味着交易时间的银行间/即期汇率未被使用。

- Frederik

9

我们公司处理多种货币的会计和预算。我们实现的解决方案非常简单，包括以下内容：

一个货币表，其中包含一些字段，包括要考虑的小数位数以及汇率值，该值没有其他意义，只是在评估“未执行”或“待处理”的财务交易时作为“建议/默认汇率”（请参见下文）。
在此货币表中，其中一条记录的汇率为1。这是我们系统中的主/基准货币。

所有具有财务维度的财务交易或操作（我们称之为承诺）均分为“待处理”或“已执行”：

待处理交易是指预期收到某个日期的某个金额的发票。在我们的预算跟踪系统中，这些金额总是根据货币表中可用的“建议/默认汇率”重新评估。
已执行交易始终保存有执行日期、金额、货币和汇率，并且在输入执行数据时必须确认/输入。

- Philippe Grondier

主要/中心货币是什么？听起来有些矛盾。如果您提供了有用的答案，我们会给您加1分。您是否曾经使用过将货币转换为基础货币的系统？我们不会将汇率信息与数据一起保存，因为汇率适用于一段时间。这就是我们的客户似乎这样做的方式。获取每笔交易的实时汇率会产生太多的开销。 - Mr Shoubs

1

通过在交易中存储汇率，这难道不意味着限制自己只能允许转换一种货币（然后再转回来）吗？ - Mr Shoubs

2

我假设你已经知道绝对不应该将货币数据存储为浮点数以及为什么。

在我看来，使用单一基础货币可能更容易；然而，你应该保存原始金额、原始货币、转换率和基础货币金额 - 否则，你的会计部门可能会把你吃掉，因为他们很可能会将不同的货币分开处理。

- Piskvor left the building

我同意，我认为单一的基础货币可能更容易。这不是为了我们公司 - 该产品是为外部客户而设计的，因此我们的会计部门并不关心。存储所有这些信息对我们来说开销太大了。感谢提及它。 - Mr Shoubs

1

我正在寻找适当的分析，肯定有一些网站或白皮书涉及这种事情吧？ - Mr Shoubs

1

由于汇率波动，一种方法是像您提到的那样 - 存储一个未转换的“按原样输入”的金额，但显示一个伴随字段，该字段仅用于显示并显示转换后的金额。为了进行转换，需要一个汇率表及其适用日期范围。如果其大小较小，则可以在客户端上缓存。否则，需要远程调用才能执行转换。

- btreat

用户输入的数据对于此转换并不感兴趣，他们只想看到和输入他们本地的货币。其他国家可能希望以另一种货币查看聚合数据的报告。 - Mr Shoubs

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mr Shoubs · Accepted Answer

我没有找到任何权威的讨论，因此我发布了我的发现，希望能帮助到某些人。

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

交易方法

存储客户本地货币并存储在交易发生时适用的交易货币的多个转换率。
每种货币需要多个汇率
网站设置表将存储输入货币
在客户端级别输入和输出值不会产生额外负担，因为可以假定该值是以正确的货币表示
要应用汇率，您需要知道输入值的货币（可能对于跨客户报告而言是不同的），然后将其乘以其关联实体汇率，该汇率在交易时间段内有效。

功能方法

以一种基准货币进行存储，保存适用于此货币的转换率
需要考虑前端和数据库之间点之间的最佳转换位置
输入性能受到轻微影响，因为需要将值转换为基础货币。汇率可以被缓存在客户端上（请注意，每个实体可能使用不同的汇率）
这需要一组汇率（从基础货币到所有其他所需货币）
要应用汇率，每个交易都需要在基准货币和所需货币之间进行转换

复合

在交易点上，存储交易值和功能值，这样就不需要存储任何汇率信息。（此解决方案不适合，因为它实际上将您限制在给定值的两种货币中）

比较

实际上，您必须在功能和交易方法之间做出选择。两者各有优缺点。

功能方法不需要为交易存储本地货币，需要将当前数据库值转换为基础货币，仅需要一组汇率，虽然需要更少的存储空间，但实施和维护稍微困难一些。

交易方法更加灵活，但需要保存更多的汇率信息，并且每个交易需要关联到一个输入货币（尽管这可以应用于一组客户而不是每个交易）。它通常不会影响已经在生产中的代码，因为本地货币仍然在本地级别上使用，因此易于实施和维护。但是显然，任何需要转换为不同货币的报告或值都会受到影响。

在两种情况下，每个交易都需要交易时间的汇率信息，以便将其转换为所需的每种货币-对于功能方法，这是在交易点需要的，但事务方法允许更大的灵活性，因为过去的汇率数据可以随时输入（允许使用任何货币），即您失去了使用功能方法中其他汇率的能力。

结论

货币管理的交易方法提供了一种灵活的方法，避免了对客户性能的任何负面影响和零客户端代码修改。如果需要不同的货币，则可能会在所有报告中出现负面的性能影响，因为它们都需要重新制作。每个客户站点都需要存储一个货币参考，说明他们的输入货币是什么。在高级别（例如一组客户站点等）存储汇率信息应该是可行的，这将最小化存储的数据量。如果需要低级别的汇率信息，则可能会出现问题。