Tax Exclusive System is the opposite, that is, a system that specifies prices displayed excluding tax (HT in France). Here, I abbreviate these systems as TIS and TES for clarity.

ERP5's main model is TES. When the user enters unit prices in paths or movements, they do not include tax amounts. And, the corresponding tax amounts are calculated with model lines, and inserted separately into orders and invoices. In this page, I discuss how to implement TIS within ERP5 in a reasonable way.

How TES works¶

First, I describe the Tax Exclusive System in the current ERP5. Suppose that you have an order with two lines: 3 units of A, and 2 units of B, where A and B are distinct resources (e.g. products). Then, ERP5 finds and applies the unit price of each of A and B. So, let's say, A is 10 EUR, and B is 20 EUR per unit. Then, we get a total price:

  10 * 3 + 20 * 2 = 70 EUR

Now, let us assume that A and B are both charged with 10% of VAT (Value Added Tax) for simplicity. The tax is calculated as:

  70 * 0.1 = 7 EUR

against the total price. So, the net total price is:

  70 + 7 = 77 EUR

So, we need only a single line for the VAT which amounts 7 EUR.

How TIS works¶

Now, I describe the Tax Inclusive System. Here, I assume that A and B are 11 and 22, respectively, per unit, and charged with 10% of VAT.

When calculating the net total price:

  11 * 3 + 22 * 2 = 77 EUR

In order to obtain the total price, we need to know the amount of VAT:

  11 / 1.1 * 3 + 22 / 1.1 * 2 = 7 EUR

So we obtain:

  77 - 7 = 70 EUR

So, this looks perfect, but how should this be represented in ERP5?

The prerequisites¶

• Tax is not always of one type. In the above, I used only VAT, but there are more variants of taxes in the world: tax against tabacco, tax against alcohol, and so on. Thus, one item can be charged against multiple taxes, potentially.
• Unit prices entered by the user must include taxes in TIS. Otherwise, it is too difficult to use.

The caveats¶

• How taxes are applied depends on a region, a trading target region, etc., so TIS potentially requires a lot of price lists.
• In TIS, you may not calculate taxes based on a total, because of legal definitions. This makes difference when rounding is required. For example, if you have 10 as a unit price with 7% of VAT, when you buy 10 items of this. If you apply the VAT against the total, 10 * 10 / 1.07 = 93.48. If you apply the VAT against individuals, (10 / 1.07 = 9.35) * 10 = 93.50 (with Asymmetric Arithmetic Rounding).

My proposals¶

One way (easy to implement, but somehow inconsistent)¶

The user enters unit prices with tax included, as he wants. So, getPrice and setPrice can be used both for tax included prices and tax excluded prices. Then, based on the definition of a given resource (i.e. base amount), ERP5 applies all effective tax models against each order line, and generates Ni tax lines for each order line Li , where Ni is the number of taxes applied to the resource on Li.

Then, getTotalPrice subtracts the total amount of taxes applied to a given line from the total price, and getNetTotalPrice does not, which is nearly the opposite of TES, where getNetTotalPrice adds up the amounts of taxes.

This implies that tax lines must have a category to denote whether inclusive or exclusive.

Also, this implies that each movement must specify a base amount differently, either taxable or taxed.

Another way (more consistent, but somehow difficult to implement)¶

The problem is that you may not know if getPrice returns a tax included price or a tax excluded price easily, so, especially when you mix up TIS and TES in a single order, it is ratherconfusing to display the lines in reports.

So, the beautiful way is to define a new property net_price. If a resource is tax inclusive, the user enters the net price with setNetPrice. Otherwise, she enters the price with setPrice. When a movement has net_price, getPrice must calculate the value from the net price and corresponding tax lines. Otherwise, getNetPrice must calculate the value from the (non-net) price and corresponding tax lines.

This is nearly the same as above, but getPrice always returns a unit price without tax. So, as a design, this is more consistent. But the configuration of the UI becomes harder, because ERP5 must exchange a field based on base amount, that is, if a resource is tax inclusive, ERP5 must show my_net_price, otherwise my_price.

Discussion¶

• If a resource is sometimes tax inclusive and sometimes not (for example, depending on a market segment), how should this be represented? Clearly, we cannot claim if the resource is tax inclusive or not in the resource itself. So, the difference between TIS and TES might be something different from base amount. Therefore, it might be necessary to put the information in supply lines instead. But how?
• With the combination of discounts, things get more complicated. As you see above, in TIS, the amounts of taxes must not be calculated from a total. So this implies that discounts should not be applied to a total, either.

Examples¶

A stationery shop near to Nexedi Japan¶

He shows all prices with tax included (TIS). He always applies a 25% discount. Let us say, you buy a set of white papers in 100 JPY (this is different from the real price, but just an example). Since Japan applies 5% VAT, this is 95 + 5 in TES. He applies 25% against 100. So this results in 75 JPY. The VAT is 4 JPY.

If you buy a set of white papers in 100 JPY, and a set of pens in 80 JPY, at a time, he applies 25% discounts to them as usual. This results in 75 + 60 (= 135). And, due to the requirement of the law, the VAT is calculated as 4 + 3 (= 7). Note that if you calculate the VAT against the total, the result is different (i.e. 6).

An imaginary car shop¶

I think this is done frequently, but I don't refer to any specific case. So, note that the reality might be different from my idea.

Let us say, you buy a new car in 2,600,000 JPY. Of course, this is tax included. Then, the sales person proposes a 7% discount, because you are a nice customer. So the result is 2,418,000. So far, it is easy.

But his shop has a policy of cutting off any extra less than 10,000. So it results in 2,410,000. And the VAT is 114,762. Still, it is easy.

Now, suppose that you purchase some optional goods with the car. For example, a car audio in 54,000. He does not want to apply the 7% discount to this one. So, before the cutting off, the total is 2,472,000. After the cutting off, 2,470,000.

The problem is how to re-distribute the total to the car and the car audio. One way is to be weight-based, i.e., 2,410,000 : 54,000. Another way is to put the cutting off discount completely to the car price which is much higher than the other. Anyway, once the prices of the car and the car audio are corrected, you can calculate the VAT precisely.

Related Articles¶