VAT calculation and rounding

[mfalkao]

This is a suggestion for a possible new VAT calculation and should be verified and tested.
There is also a suggestion for an invoice report using iText7 implemented in PdfService7 but not activated yet. You can do this for testing purposes in Nop.Web.Framework\DependencyRegistrar using builder.RegisterType<PdfService7>().As<IPdfService>().InstancePerLifetimeScope();.

The main scope of this change is to implement VAT calculation as used in ERP systems to be compatible with most vat regulations.
There are still some issues that should be clarified:

1. Nop uses InclTax and ExclTax fields like OrderSubtotalInclTax, OrderSubtotalExclTax to maintain both tax settings. This will necessarily lead to rounding problems. The most used approach is to have only one tax setting per document. For instance, the document shows prices including or excluding VAT but not both. This is independent from the overall price setting (with or without VAT) and is only related to the customer setting (private person or company).
2. Nop’s ordertotal is misleading in some way. It should be named “amount to pay” as order total is always the total of all goods and services minus discounts.
3. Discounts do reduce the VAT base amount and therefore they will also reduce VAT. This is atm only the case for the subtotal discount, but this should be also the case for the total discount as implemented with the new calculation. Moreover, there is a similar issue with reward points. Earned reward points are discounts for the next order and should reduce VAT. Please note, that gift cards are different. They do reduce the payment amount and are therefore not relevant for VAT calculation. Hence, there are two distinct case: 1) amounts that do reduce the order base amount and therefore reduce also VAT (discounts, reward points) and 2) amounts that do reduce the payment amount (gift cards or reward points used for that purposes).
4. Tax setup should be enhanced by adding a vat-code. This vat-code plus the vat-rate would then be used to sum up vat. Atm sums are per vat-rate and therefore we can’t distinguish vat exemptions. For instance, there might be a vat-rate of 0% for goods and one of 0% for services. On the invoice you must show two different base amounts with vat = 0 but different VAT exemption description.

Implementation

1. Added taxSummary Class for VAT calculation. This class sums up line amounts per vat-rate, applies discounts rounding accordingly and calculates VAT per vat-rate and total VAT.
2. Modified roundinghelper: added amount rounding function. It is commonly used to round prices differently from amounts. In the EU prices can be rounded to any precision but amounts have to be rounded to two decimals using midpoint rounding away from zero.
3. Added vat-rate to orderitems and shoppingcartitems.
4. Added order amount and order amount incl. vat.
5. Modified tax display per rate.
6. Added Invoice No. to order

Use setting ordersettings.autoupdateordertotalsoneditingorder=true for OrderTotal update when editing an order in admin panel.

ToDo:
Migration of old orders. To update Order.TaxRates you have to edit the order and to save one of the products.

[mfalkao]

I've added tax calculation for associated products. With this you can sell sets having products with different tax rate.
May I suggest to define the next steps.

First of all a code review is needed. The pull request is a concept proposal to show how tax calculation could be implemented.

Example where the actual implementation fails. Prices incl. tax and setting shoppingcartsettings.roundpricesduringcalculation = true
with 10% Subtotal discount.
Version 3.8
Item1 = 7.99 and 10% tax
Item2 = 7.95 and 20% tax
Result: Subtotal 15.94, discount 1.59, tax 1.84 -> total 14.34. Should be 14.35.
Reason is a rounding error when calculating discount.

New
Result: Subtotal 15.94, discount 1.59, tax 1.84 -> total 14.35

To go further on we need to decide several issues:

1. Do we need the fields Incl/Excl in order? We could limit everything to what the order is intended for. For instance, orders with CustomerTaxDisplayTypeId = DisplayTax would have respective fields with tax, otherwise fields are without.
   If we decide to keep them, then OrderDiscount should also have both fields (OrderDiscountInclTax and OrderDiscountExclTax) as it involves now tax calculation. Furthermore, in this case we should make CustomerTaxDisplayTypeId modifiable after the order has been posted, to allow printing invoices with different tax setup. This would be the case when a customer had the wrong setting.

2. Should we add a tax-code to tax setup? Do we have the need to show tax texts per taxrate and tax exemption?

3. Reward points. Should they reduce tax?

4. Configurable tax and amount rounding?