database-design - 英国增值税从 17.5 变为 15% - 这将如何影响您的代码？

Question

英国增值税制度正在从 17.5% 变为 15%。您在代码中使用了哪些策略来存储增值税，以及更改将如何影响您的应用程序。您是否存储了大桶的历史记录以便计算旧价格，还是将旧发票存储在单独的表中？这是一个简单的配置设置，还是你拒绝了？存储增值税的理想方式是什么？

Answer 1

不要计算它。存储它!

HMRC 对获得适量的增值税非常挑剔。增值税计算的四舍五入在用户指南中的规定有些模糊，留给 future 的实现者来解决可能是自找麻烦。通过在输入发票/行项目时存储金额，可以避免此问题。

这似乎是对存储的浪费，违反了冗余原则，但涉及的存储量很小，将来可以省去很多麻烦。当然，不言而喻，货币金额(甚至可能是带有小数部分的增值税税率)应该存储为乘以整数，以避免二进制小数表示舍入错误也蔓延。

中央费率存储

您绝对应该使用中央速率存储。但是，我建议这仅提供输入新发票时使用的当前默认费率。这些可以与开始和结束日期一起存储，以便在必要时进行自动转换。可以为每张发票(或发票行)存储这些费率以及开具发票时计算的增值税金额，以提供当时情况的绝对快照。

不要忘记适应不同的增值税税率(例如标准、减税、零税率、无增值税)以及与其他欧盟国家/地区的增值税注册实体进行交易的可能性，在这些国家/地区您可能需要免增值税发票通常要缴纳增值税。

您最终可能会得到这样的表格(示例):

编号 |费率名称 |增值税率 |开始日期 |结束日期
-------------------------------------------------- -
1 |标准 | 1750 | 1991 年 1 月 1 日 | 2008 年 11 月 30 日
2 |标准 | 1500 | 2008 年 1 月 12 日 | 2009 年 12 月 31 日
ETC

上表只是一个例子。增值税率存储为“基点”的整数(例如百分之一百分点)，但假定增值税率永远不会超过小数点后 2 位。您显然可以用一个额外的列来扩展它来缓解这个问题，但这似乎有点太过分了!