We’ve found that when using the same tax in an invoice and mixing positive and negative amounts the tax lines is duplicated.
Here are some screenshoots that ilustrate the situation:
As the tax used for the lines is exactly the same I will expect that only a single tax line with the resulting base is created. This is the current behaviour when the lines are for the same sign.
Is there any reason to split the lines depending on the sign or this is a something that should be fixed?
Because the _TaxKey use the base sign as _key.
This is because we allow to distinct in the tax code reporting the types “Invoice” and “Credit” which is a common requirement.
But and invoice is an “Invoice” or a “Credit Note” not both of them.
If we have a mixed lines in the invoice the sign determines the type of the invoice (at least is what we do for determining the number sequence). So I think the taxes should work the same way.
Not the lines, it depends of the sign of the amount.
The numbering does not determine how the line is booked.
No because it has not sense on an accounting point of view. The invoice document is just a grouping of lines which are credit or debit.
Yes, but the total amount of the invoice not the amount of each line separatly.
On our case the tax uses the same credit and debit account. So there is no diference on accounting balance just a mather of having a single line instead of two.
Indeed our issue is not really linked to the accounting as there is no diference on the behaviour but the problem is that the tax lines are duplicated on the invoice report (and in the UI) which is strange for the end user.
This has not meaning in accounting.
We do not care if the account is the same. It is a credit and a debit.
Tax reporting does not care about the balance (otherwise there will be no tax code).
The user should not care.
But it cares.
It is strange to have two lines when the user expects a single one.
Indeed the customer receiving the invoice should not take care how we account the taxe amounts. It should only see the amounts that are relevant for him. And this is just:
Maybe looking on the other way arround is easier to understand the issue:
If you receive a supplier invoice having two lines for the same tax you will need to sum this up to check that you entered the invoice correctly on the system.
Feel free to find a better way to do as long as the reporting is correctly split between credit and debit.
Yes it should because the credit line should be booked as a credit and the other as debit.
The base of each debit and credit is relevant.
This is not the same tax as there is a credit and a debit.
No because if the system is correct, it will require to have the credit and debit separated.
It is, this is the tax I used on the example above
Indeed this is the key of the question. How you will know that it requires credit and debit should be separated? Shouldn’t be this determined by the account/tax code used for reporting?
No it is not, there is a debit and a credit.
We do not need to know as we always separate them following the good accounting practice.
Reporting should not influence how the accounting is done because they are done after and can evolve over time.
I’ve beening digging on the spanish taxes law and I just found that in article 78, chapter 3 they talk about what must not be included as tax base:
1.º Las cantidades percibidas por razón de indemnizaciones, distintas de las contempladas en el apartado anterior que, por su naturaleza y función, no constituyan contraprestación o compensación de las entregas de bienes o prestaciones de servicios sujetas al impuesto.
2.º Los descuentos y bonificaciones que se justifiquen por cualquier medio de prueba admitido en derecho y que se concedan previa o simultáneamente al momento en que la operación se realice y en función de ella.
Lo dispuesto en el párrafo anterior no será de aplicación cuando las minoraciones de precio constituyan remuneraciones de otras operaciones.
3.º Las sumas pagadas en nombre y por cuenta del cliente en virtud de mandato expreso del mismo. El sujeto pasivo vendrá obligado a justificar la cuantía efectiva de tales gastos y no podrá proceder a la deducción del impuesto que eventualmente los hubiera gravado.
In second paragraph they say that the discounts and bonifications (lines with negative amount) that are conceded in the same time as the invoice should not be included as part of base of the tax.
This means that when mixing negative and positive lines, the base of the tax is the diference between both of them. So at least for Spain we should create only a single line.
My initial tought was that we could just use the account to decide if the tax should be splited or not but I’ve seen this behaviour has been added in Wrong tax base type (#8759) · Issues · Tryton / Tryton · GitLab which does not include any example of the usage but talks about having the same tax and account.
So I’m wondering if it will be good to have some flag on the tax to determine if the same tax and account should be included on the same base line or in diferent ones.
I do not know what you mean by that.
This is not a discount. If you want to make a discount change the unit price. This is the point of the sale_discount module.
When you make an invoice like you showed, it means that you are invoicing 10h and you are reimbursing 2h that you previously invoiced.
If you wanted to make a discount of 20%, you should have to invoice 8h or 10h at 40€.
There is the case that you want to make a fixed discount on the invoice. Some examples:
Both cases can not be computed updating the unit price of the lines.
Such thing do not have a taxes. Usually this goes into a special account and this is not set when the invoice is posted (because you do not know if the customer will be in advance).
So as you said it is the price that is changed. This is managed by the module sale_promotion.
