database-design configuration-management

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

发布于 2024-07-08 17:58:29 字数 145 浏览 7 评论 0原文

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

物价感观 2024-07-15 17:58:30

我的想法...

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

b- 增值税（或其他税）值绝对应存储在表格中，并附有生效日期和税率。如果它是硬编码的，请立即对其进行软编码，因为它可能在不久的将来再次发生变化。

c- 这在美国是一项巨大的（且已解决的）交易，因为州、县、甚至城市之间的销售税各不相同。我在洛杉矶县生活和工作，销售税率为 8.25%。以南 10 英里处的奥兰治县，销售税率为 7.75%。互联网和目录零售商必须知道正确的费率，因为它是由交货地点决定的！

祝你好运。

回复收藏 0 原文

远昼 2024-07-15 17:58:30

我们从所有内部应用程序共享的数据库表中提取增值税，这意味着对于我们的新代码而言，这对我们来说并不是什么大问题。像这样保持中心化一定是明智之举。

回复收藏 0 原文

卖梦商人 2024-07-15 17:58:30

我有一种不舒服的感觉，我继承的两个系统在某处硬编码了费率。

更糟糕的是，如果它是硬编码的，我将简单地替换硬编码值，因为我没有时间正确更改它。

更糟糕的是，我不知道从哪里得到时间来实际进行改变。所以我想周一的改变不会及时完成。当然还有更有趣的问题，比如我们的 10 英镑订阅是基于 10 英镑包括 17.5% 的增值税（8.515 英镑或其他任何数字）。现在它的价格将是 9.79 英镑左右，这使得所有宣传它的价格为 10 英镑的东西都变得一团糟，并且所有网站的计算都基于 10 英镑。

这一切都是因为负责存钱罐的白痴想要成为头条新闻。

回复收藏 0 原文

明月夜 2024-07-15 17:58:30

我们将增值税率存储在数据库表中，因此这对我们来说并不是什么大不了的事，尽管我必须举手说，由于我们对代码所做的一些修改的性质，增值税是硬编码的在几个地方（我的错！），我设法以另一种更令人兴奋的方式重新捏造！

回复收藏 0 原文

九厘米的零° 2024-07-15 17:58:30

我正在做一些事情，以便在汇率恢复正常时做到这一点。

无论您采用哪种方式，都无需在增值税表中记录开始日期和结束日期，因为增值税期间是直接连续的。

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

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

I am just working on something to do this for when the rate changes back.

Which ever way you do it, there's no need to record a start and an end date in your vat table since the vat periods run directly after each other.

You can access the correct vat by doing a query like the one below, where vat_date is the start date for the VAT rate.

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

回复收藏 0 原文

舞袖。长 2024-07-15 17:58:30

关于存储与计算的争论。如果您存储它，您以后随时可以计算它 - 如果您改变主意；）

回复收藏 0 原文

我三岁 2024-07-15 17:58:30

我昨晚在代码中发现了一个表，其中存储了应用程序的重要配置设置。

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

其中一项设置是服务器的主要管理员用户名和密码组合（未散列）。我猜创建它的开发人员总是希望访问它，以防他忘记！不用说，现在已经消失了。

I found a table in the code last night that stored important configuration settings for the application.

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

One of these settings was our main admin username and password combination for the server (unhashed). I guess the dev who created it always wanted access to it in case he forgot! Needless to say, it's disappeared now.

回复收藏 0 原文

凉墨 2024-07-15 17:58:29

别算了。储存起来！

英国税务海关总署对于缴纳适量的增值税非常挑剔。用户指南中对增值税计算的四舍五入的规定有些模糊，将其留给未来的实施者来正确处理可能会带来麻烦。通过在输入发票/行项目时存储金额，可以避免此问题。

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

中央速率存储

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

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

您最终可能会得到这样的表格（示例）：

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

上表只是一个示例。增值税率存储为“基点”的整数（例如百分之一），但假设增值税率绝不会超过小数点后两位。显然，您可以通过额外的列来扩展它来缓解这个问题，但这似乎有点太过分了！

Don't calculate it. Store it!

HMRC are very fussy about getting paid the right amount of VAT. The rounding of VAT calculations is somewhat vaguely specified in the user guides, and leaving it up to future implementers to get it right is possibly asking for trouble. By storing the amount when the invoice/line-item is entered, this problem is avoided.

This seems like a waste of storage and a violation of redundancy principles, but the amount of storage involved is tiny and it could save a lot of trouble in the future. Of course, it goes without saying that the currency amounts (and potentially even VAT rates with a fractional part) should be stored as a multiplied integer to avoid binary fractional representation rounding errors creeping in too.

Central rate storage

You should absolutely use central rate storage. However, I would recommend that this only provides the current default rates used when entering new invoices. These can be stored with start and end dates to give automatic changeover if necessary. These rates can be stored for each invoice (or invoice line) along with the calculated VAT amounts at the time the invoice is raised to give an absolute snapshot of the situation at the time.

Don't forget to accommodate the different VAT rates too (e.g. standard, reduced, zero-rated, no-VAT) and the possibility of trading with VAT registered entities in other EU countries where you may have to no-VAT an invoice that would normally be subject to VAT.

You could end up with a table like this (example):

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

The above table is only an example. The VAT rate is stored as an integer of "basis points" (e.g. hundredths of a percentage point), but does assume that the VAT rate will never be to more than 2 decimal places. You could obviously extend this with an extra column to relieve this problem, but it would seem possibly a step too far!

回复收藏 0 原文