不是所有货币都有小数位
在设计数据库表结构时，有一个普遍观点是“永远不要用浮点数来表示钱”。一些人建议使用MONEY数据类型，另一些人则告诉你要使用DECIMAL。
对于计费系统来说，这两种类型在某些情况下都是错的。当然，在美国和大多数欧洲国家，货币是有小数位的。
在日本，情况就不是这样的——你不能收取 2500.50 日元的费用。除了日本，冰岛的货币也没有小数位。相反，伊拉克第纳尔（伊拉克货币单位）有三个小数位。
从技术上讲，你可以认为整数也是一种小数，但如果你没有考虑到一些情况，有可能会给你的系统带来麻烦。在构建计费系统时，你必须考虑足够的扩展性，以便处理这些国家的货币，即使它们可能不是你当前关注的焦点。
在保存数值时，可以包含可能会使用到的小数位。
例如，在大多数情况下：
100 美元可以存为 10000
2500 日元存为 2500
2500 冰岛克朗存为 2500
100 伊拉克第纳尔存为 100000
以下是部分没有小数位的货币。
ISO 4217 标准规定了世界各国的货币编码，可以在维基百科上找到其他更多内容。
票据一旦创建就无法取消
至少在欧洲大部分地区不能取消。在美国，取消未支付的票据是很常见的事情。然而，这在许多欧盟国家是不合法的。如果你因此犯了错，它将成为一个巨大的痛点！
这属于“标准会计”的一部分，但有时它确实很伤人，因为错误总是会不可避免地发生。票据一旦创建，如果你想要取消，只能再创建一个全额的贷记单。
什么是贷记单？你可以把它看成是一种反向票据。贷记单是一种独特的单据，就像发票一样，它们也有自己的编号。
因此，贷记单是一种可以用来将原始发票标记为“已支付”的文件，即使没有发生金钱转移。
不是所有的计费系统都是合规的
当你进入一个新区域开发业务，你要做的不仅仅是为你的产品和服务定价，还必须确保自己遵守各种规章制度——这可能比你想象的要微妙得多。
很多公司从第三方 SaaS 公司购买服务，我们通常认为这样做是合规的。
但我发现情况并非总是如此(当然，我们有责任去核实)。
这里有两个例子：
1.在欧盟，供应商必须在每次销售前确保客户的增值税号码(如果使用了)是正确的。
例如，Stripe 会做一次增值税信息检查，但不做任何其他后续检查，也不检查与客户详细信息是否匹配。
其他一些服务根本什么都不检查，所以请确保你是合规的！
2.欧盟增值税发票必须包含公司增值税的具体信息。然而，很多发票生成器(包括 Stripe 公司)生成的票据甚至不包含增值税信息。
你可能需要找到一种方法，比如利用地址栏备注税务相关信息。无论使用哪种方式，你都要确保自己是合规的！
当用户变更了付费计划该怎么办
我原以为让一家公司成为付费用户是很容易的。他们注册后，经过短暂的试用，就成为付费用户(“Evergreen”)，一切都很棒!
理想情况下，一家公司开始使用产品，在后续的整个生命周期当中都不做付费计划变更（直到退出）。
与很多其他公司一样，我们也提供了不同级别的服务，需要客户预付一个月的使用费。因此，如果客户对服务进行了升级或降级，我们要在未来的某个时刻修改他们的付费计划。
付费计划可以在将来某个时刻发生变化，但客户可能希望立即使用升级后的服务。
这好像没什么问题，直到你开始考虑一些情况：
如果他们想立即使用升级后的服务该怎么办？
我们可以升级他们的付费计划，但不向他们收费。这意味着你需要将计费引擎与指定服务级别的授权引擎分开！
你也可以立即收费，但比例该怎么算呢？
如果他们也想立即为新付费计划付费该怎么办？
这比你想象的要常见得多。我们可以立即进行升级！但是，我们是只收取差价呢，还是把整个月的费用都记在账上，再收取新服务的费用呢？
我们偶然发现了可怕的比例问题，这会导致你、客服和客户很难理解票据上的内容。
一个例子，有时候上面会有几十个细项。
实际上，我们也想把他们的试用期延长一点，这样他们在变更付费计划时就有更长的宽限期。
这个其实没那么难……
但有时候他们在开始付费计划后才想要变更计划。
这真是一个噩梦，你可能还需要赊销一些发票！
可能还会有其他情况发生，虽然可能不是每次都会发生。但随着客户数量的增加，它们就会发生。所以，请提前计划好你要如何处理这些情况！
强行制定规则来应对边界情况？
客户不是公司，他们是人，而且不同的人有不同的需求。
除非你是在非常严格的环境中，否则你必须要考虑强制执行规则的难度。
下面是一些例子：
1.我们只针对英国客户推出折扣。
这样当然可以，但如果一个英国客户在德国有分公司呢？分公司也可以享受这个折扣吗？(答案是肯定的！)
2.我们发起一项活动，每个注册用户都可以免费使用产品，直到 2021 年 4 月 1 日。这适用于所有客户，即使是签订了多年合同的客户。
然而，在签了合同后，一些客户却执意要付费。
3.一些客户想在 2020 年底提前支付 2021 年的费用，因为他们有多余的预算不能在 2021 年使用。
我们的系统不支持提前付费。
除了计划如何应对这些问题，也要考虑是否可以绕过它们，因为这些问题都将可能发生。
在我看来，最好的策略是为业务提供支持，赢得客户，而不是制定太过严苛的规则。
事情从来没那么简单
无论一个问题最初看起来多么简单，它总是有一定的深度和大量需要解答的疑问。
设计和开发计费系统是一件很难的事情，哪怕你只是稍微偏离了“标准”一点点。但如果你努力找到正确的方法，带给你的将是快乐的客户、快乐的销售和支持代表，以及快乐的财务部门！
这些是我在开始开发计费系统前希望知道的 5 件事，当然，它们并不能代表全部。
- END -
推荐阅读：
关注我
学习架构知识
互联网后端架构
1206
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
