UK Vat从17.5变为15％ - 这将如何影响您的代码？ [英] UK Vat change from 17.5 to 15% - How will this affect your code?
问题描述
不要计算。存储！
HMRC对于获得适当的增值税金额非常的挑剔。增值税计算的四舍五入在用户指南中有些模糊的规定，并将其留给未来的实施者来取得正确的可能是麻烦。通过存储输入发票/订单项的金额，避免了此问题。
这似乎是浪费存储和违反冗余原则，但是存储量很小，今后可能会节省很多麻烦。当然，毫无疑问，货币金额（甚至可能是具有小数部分的增值税税率）应该存储为乘法整数，以避免二进制分数表示法四舍五入也在爬行。
中央费率存储
您应该绝对使用中央费率存储。但是，我建议这仅提供输入新发票时使用的当前默认费率。这些可以存储起始日期和结束日期，以便在需要时进行自动切换。这些费率可以存储在每个发票（或发票行）上，以及发票开具时计算的增值税金额，以便给出当时情况的绝对快照。
不要忘记适应不同的增值税率（例如标准，降低，零分级，无增值税），以及在其他欧盟国家/地区可能需要增值税的交易的增值税注册实体的可能性通常需要支付增值税的发票。
您可以使用这样的表格（例如）：
id |价格名称|增值税率|开始日期|结束日期
-------------------------------------------- -------
1 |标准| 1750 | 01/01/1991 | 30/11/2008
2 |标准| 1500 | 01/12/2008 | 31/12/2009
etc
上表只是一个例子。增值税率存储为基点的整数（例如百分之一百），但是假定增值税率将永远不会超过2位小数。你可以用一个额外的列来扩展这个，以减轻这个问题，但是看起来可能还有一个步骤！
The UK VAT system is changing from 17.5% to 15%. What strategies have you used in your code to store the VAT, and how will the change affect your applications. Do you store a history of vats so you can calculate old prices, or are old invoices stored in a separate table? Is it a simple config setting, or did you bodge it? What's the ideal way to store VAT?
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!
这篇关于UK Vat从17.5变为15％ - 这将如何影响您的代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
