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.
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.
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:
The aplicable tax and it’s rate
The base amount
The total amount.
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.
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?
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.
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:
Early payment discount (if the customer agreed to have a lower maturity date at the invoice it is possible to do the discount directly on the invoices).
Because we may agree to have a lower price if the invoice exceeds a threshold
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.