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

时间:2008-11-25 09:02:41

标签: database-design configuration-management

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

9 个答案:

答案 0 :(得分:38)

不要计算它。存放它!

HMRC非常挑剔地获得适当数额的增值税。在用户指南中有点模糊地指定了增值税计算的四舍五入,并且将其留给未来的实施者以使其正确可能会遇到麻烦。通过在输入发票/项次料品时存储金额,可以避免此问题。

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

中央费率存储

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

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

你最终可能得到一个像这样的表(例子):

id | Rate name | VAT rate | Start date | End date
---------------------------------------------------  
1  | Standard  | 1750     | 01/01/1991 | 30/11/2008
2  | Standard  | 1500     | 01/12/2008 | 31/12/2009
etc

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

答案 1 :(得分:16)

不要存储它。计算它!


我建议的存储基于百分比的利率/利息的方法是:

您应该有一张表'VAT_param',如

利率|自(日期)|生效有效期(日期)

我相信,

  

任何可以计算的内容,   不应保存“

特别是在你需要根据他人的百分比计算价值的情况下(比如税收,利息等)。不要让时空权衡躲避你。你以后会花时间在太空上祝福自己。

然后,应根据发票日期,根据期间的有效汇率整齐计算增值税。它会

  • 确保最少的冗余(请永远不要谈论旧桌子或新桌子......如果利率每年变化一次,你会在几年内开始拉头)< / p>

  • 使用集中式单轴来控制费率。您的VAT_param表。

答案 2 :(得分:4)

我的想法......

a-我通常更喜欢使用calc over store,但在这种情况下计算的增值税(以及用于计算的费率和代码)应与每笔交易一起存储。这是因为它将是必须重复生成的文档的源数据。您还希望能够将销售中的增值税金额与财务分类帐中的增值税金额相匹配。您希望冒着无法每次都重新生成发票或增值税报表等文档的风险。

b-增值税(或其他税)值应绝对存储在表格中,并附有有效日期和费率。如果它是硬编码的,现在就开始对其进行软编码,因为它可能会在不久的将来再次发生变化。

c-这在美国是一项巨大的(并已解决)交易,因为销售税因州,县甚至城市而异。我在洛杉矶县生活和工作,销售税率为8.25%。向南10英里,在奥兰治县,销售税率为7.75%。互联网和目录零售商必须知道正确的费率,因为它取决于交货地点!

祝你好运。

答案 3 :(得分:3)

我们从所有内部应用程序共享的数据库表中提取增值税,这对我们新代码所涉及的内容来说并不是什么大问题。保持这种集中化必须是明智之举。

答案 4 :(得分:1)

我有一种令人讨厌的感觉,我继承的两个系统的速率在某处硬编码。

更糟糕的是,如果它是硬编码的,我将简单地替换硬编码值,因为我没有时间进行适当的更改。

更糟糕的是,我不知道我将在哪里有时间实际做出改变。所以我想,周一的改变不会及时完成。当然还有更多有趣的问题,例如我们的10英镑订阅是基于10英镑,包括17.5%增值税(8.515英镑或其他任何东西)。它现在只需9.79英镑左右,将所有宣传它的东西弄得一团糟10英镑,所有网站的计算都是基于10英镑。

这一切都是因为负责存钱罐的白痴想要一个标题。

答案 5 :(得分:0)

我们已将增值税税率存储在数据库表中,因此对我们来说这并不算太大,尽管我必须举起手来说,由于我们对代码增值税所做的一些修改的性质是在几个地方硬编码(我的坏!),我已经设法以另一种更激动人心的方式重新捏造!

答案 6 :(得分:0)

我正在努力为费率变回时做点什么。

无论你采用哪种方式,都不需要在你的增值税表中记录一个开始结束日期,因为增值税期间直接相继运行。

您可以通过执行以下查询来访问正确的增值税,其中vat_date是增值税率的开始日期。

SELECT * FROM vat WHERE NOW() > vat_date ORDER BY vat_date DESC LIMIT 1

答案 7 :(得分:0)

关于store vs calc参数。如果你存储它,你可以随时计算它 - 如果你改变主意;)

答案 8 :(得分:-1)

我昨晚在代码中找到了一个表,它存储了应用程序的重要配置设置。

Table tbl_config
   config_id int
   config_name varchar(255)
   config_value varchar(255)

其中一个设置是我们服务器的主管理员用户名和密码组合(未散列)。我想创建它的开发人员总是想要访问它以防他忘了!不用说,它现在已经消失了。