Vat rounding

I've created the following pull request
1992

Here the description:

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.

Thanks a lot, Markus!

By the way, could you please clarify about PdfService7? When and how do you use it? What is the difference with the current implementation? It's a little bit unclear

PdfService7 is a draft version for a new invoice or order confirmation report. It's main purpose was to show how a classical invoice report can be implemented using iText7 using its new features for table headers, table footers and page numbers. It is not RTL atm as you might need a license for it.

I've also forgot to mention that we've also added a separate field for the invoice number. It's implementation works but I would rather prefer to have an own number series setting for it. For instance, like with currencies, to be able to define an own number series.

Here also an example for the actual limitations of vat calculation:

NOP calculates VAT correctly in most cases. There is however a limitation. In the EU there is the need to show on invoices not only the VAT amount per rate but also its base amount.

Settings: prices including vat, one tax category with 10% VAT and one with 20%. Subtotal discount of 10%.

This must give the following amounts (L = line amount incl, D = discount incl, B = base excl).

Differences are in bold. Furthermore, please notice the rounding difference in D. Total D is 1.59, item 1 has 0.8 but item 2 must have 0.79.

  VAT%  L  D  B  VAT  Tot
Item1  10%  7.95  0.8  6.50  0.65  7.15
Item2  20%  7.95  0.79  5.97  1.19  7.16
  Tot  15.9  1.59 12.47  1.84  14.31


Using NOP you will get the following where B and Tot has to be calculated from VAT as this data is not stored.
  VAT%  L  D  B  VAT  Tot
Item1  10%  7.95    6.50  0.65  7.15
Item2  20%  7.95    5.95  1.19  7.14
  Total  15.9  1.59  12.45  1.84  14.31

Forgot to merge some changes and have updated the code. Am I allowed to squash the commits?

falkao wrote:
Sure. Thanks!

While implementing a new tax rounding logic and related points, several issues have to bee addressed.
One of them is how purchase method fees and order total discount should be implemented.
Atm order total discount is calculated in OrderTotalalculationServices/GetShoppingCartTotal after payment fee has been applied. Is that correct? Shouldn't payment fee come at last position as the fee is based on the total amount to pay?

The following ordering seems correct to me.

+Subtotal
-SubtotalDisc
+Shipping
-InvDisc 
-RewardPoints 
(+/-)Payment Fee/Disc

Payment fees can be positive but also negative. For instance, in Austria it is not allowed to charge an additional payment fee, but it is allowed to give a payment discount. This to guarantee that costs in shopping cart are not raised on checkout.

What makes things difficult is to have discounts and fees configurable so that they are taxable or not.
The definition of taxable is not very clear to me.
You can have goods or services taxable with a tax rate of zero.
Something taxable, indifferent of tax rate, should reduce the order amount, whereas something non taxable only the amount to pay. Was that the intention?