开发计费系统中学到的 5 件事

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