系统设计 | 多币种设计

在国际化的软件系统中，币种也是非常重要的一项设计，尤其是出现跨国交易的场景，可能会涉及大量的汇率换算。如果提前考虑到多币种的问题，在整套设计中会更加统一和简单，避免一些问题。

多币种设计在计算机领域体现不多，更多是相关领域知识，尤其是财会和金融知识。

币种常见的概念

货币，对于所有人来说都不算陌生，毕竟我们每天都在和它打交道，不过我们常常把一些概念混淆强调，为了更清晰的使用这些概念，我们需要更深刻地理解它们。

以人民币为例来说明货币代码。如果我们住了一次海外品牌的酒店（例如万豪），有可能给到我们的水单是英文的。在水单上，可能会出现币种 “CNY”，但在金额后面会使用 “YUAN”。

有时候我们可能混淆使用 “CNY” 和 “YUAN”，有时候甚至会出现 “CNH” 和 “RMB” 这些缩写。

首先在很多地方使用 “RMB” 这个缩写个并没有问题，“RMB”是中国的官方货币非标准货币代码，虽然在业界被广泛使用。

在国际标准化组织的货币代码标准 ISO 4217 中，中国的官方货币代码为 “CNY”，符合统一的制定习惯，“CNY” 代表中国的代码“CN”和人民币元（Yuan）的首字母Y组成。

在很多地方 “YUAN” 是作为货币基本单位使用的，但注意，“YUAN”不是货币代码，也就是常说的币种。

我们在系统设计时，应该尽量使用 ISO 4217 的标准代码，这样在系统之间传递币种时，有统一的规范，无需额外的转换。

除了 “CNY” 之外，有时候我们会使用 “CNH”。通常来说，“CNY”特指在岸人民币，“CNH”为离岸人民币。由于汇率管制的原因，在岸人民币在大陆境内发行和流通；而离岸人民币指的是在境外交易，会根据金融市场自由波动。

跳出人民币的例子，ISO 4217 规定了大多数国家和地区的货币代码，我们只需要遵守使用即可。例如，美元的货币代码为 “USD”，货币基本单位为 “Dollar”。

除货币代码之外，ISO 4217 还给货币进行了编号。该编号为 3 位数不足时补 0，所以有时候我们也会在一些场景看到三位数的货币编号。

在国际化系统中，由于存在多种货币，让系统设计非常复杂，所以在很多系统中出现了以本位货币为基础的设计方式。

本位货币又称本位币，本位币是为业务单位指定的一种单一固定货币，它通常为记账货币。通常为总公司所在国家或地区的法定货币，相关业务和财务报表通常使用这种货币。

例如一家中国的公司开发的系统，通常以人民币为本位货币，配合美元作为业务货币的实现多币种设计。

业务货币是业务发生时所用的货币，例如中国公司研发的系统在美国发生业务往来，收到的发票使用美元（USD）表示，则业务货币为 USD，而本位货币依然为 “CNY”。

为了设计上的统一性，一个重要的经验性原则为统一使用本位货币存储业务发生的金额，并使用额外的字段存储业务货币的币种和金额。由本位货币配合业务货币的设计足够应对大部分的设计场景，并使系统足够简单。

在多货币环境下，通常需要使用汇率进行多币种金额之间进行换算。例如需要对英镑（GBP）和拿大元（CAD）进行换算。

汇率的计算公式比较简单：汇率=外币金额/本币金额。根据这个公式也可以通过汇率换算出目标货币金额。

由于汇率是每天变化的，业务实践中一般以上一个外汇交易日的收盘价格作为当天的汇率进行计算。这就需要我们首先获取汇率表，这个数据往往是收费的，甚至有公司仅仅提供汇率数据，例如 Open Exchange Rates。

不过好在，各个国家会发布其以其官方货币为基准的汇率信息。在中国大陆，中国人民银行会按天发布以人民币为基准的汇率信息。

这就用到了前面介绍的本位币设计。如果需要计算英镑和加拿大元之间的汇率，我们可以获取每日的人民币汇率，然后通过本位币作为中间值计算需要目标汇率值。

在多币种系统中，另外一个常见的业务需求是多币种定价的方案。这看似是一个非常简单的业务需求，所以我们想到的两个方案是：

实际业务实践往往介于这两个方案之间，采用的是业务大区（Business Area）方案。原因是，世界经济发展极不平衡，我们无法简单根据货币制定有竞争力的价格策略，不仅汇率不同，其货币的购买力和税率也非常不同。

如果为每个货币定价，其工作量和数据量也大到不可接受，而且也没有必要。例如在欧盟，使用同样的货币，但是德国和希腊的经济水平不同，就无法使用同样的定价策略。相反，在非洲和南美，虽然国家和货币众多，但对于某些公司的产品来说，由于占有率过低，并不值得为其专门定价。

介于前面这两个方案之间，大部分国际化的公司会根据自己的经营情况，将所有进入的市场划分为有限的几个区域，通过这些区域来定价，其价格模型如下所示。

当然，定价是一个非常复杂的业务场景，区域和币种也仅仅是其影响定价的一个因素，所以有时候也需要使用定价单来实现。