Contributors

Hello @Juan José Scarafía 

Can you share the PR where the deprecation is happening?

the complementary account moves are an actual error (in fact if you combine them with the extra 2 lines that every line generate in the chase basis this will be a huge issue) 

In a few thousand invoices company (not that big) explain those extra moves will be complicated, I can not understand how 1 field vs thousands of lines just for the sake of a consistency that is and should be there is better.

But anyways before make any conclusion.

Do you have the PR?

Do you have the conversation where Odoo's explains the rationale?

Regards.

El jue, 8 jun 2023 a la(s) 14:52, Juan José Scarafía (notifications@odoo-community.org) escribió:

Hello Everyone.

It seams that odoo is going to deprecate the not so used field tax_base_amount 

The main reason odoo is going to do so is that now it may be inconsistent on how odoo is computing the base amount for a tax (the base for Odoo is always the sum of the balance of the aml's where the tax is applied on the tax_ids field)

Together with that field being deprecated, the idea behind is that there shouldn't be any aml (account.move.line) with tax_line_id that was not originated by another aml with tax_ids

We've some use cases where for us it's practical to be able to create tax aml's

Some examples:

• bank statements.
• on many banks operations (for eg. check deposits) we have expenses + taxes associated. So for on check deposit we may have 4 statement lines:
• check deposit (cash in)
• expense fee (cash out)
• tax 1 (based on the expense fee, cash out)
• tax 2 (based on the expense fee, cash out)
• On Odoo standard we're not able to reconcile that because we can't say that an statement line is 100% a tax In the odoo approach those two taxes should came from the tax being applied on the "expense fee"
• special invoice taxes
• we've some special invoice taxes where the base amount is not the subtotal of the invoice line but some specific computation (for ex. is the vat of that line)
• in that use case, we're storing the calculated base amount on tax_base_amount. Considering that the base amount is the sum of the subtotales of the lines where the tax is linked, is not correct.
• On master (and I believe 16 two). Odoo has a similar use case for belgium. When you offer a cash discount, no matter if the customer use it or not, the vat is computed on the discounted price. That's why there is a new option on the payment terms and, only for having the right base amount on the invoice, odoo is creating virtual lines (check attachment)
• supplier bills
• It's really common to receive supplier bills with some specific taxes that are totalized and without information on which are the base lines.
• in those use cases creating just a tax line (as it was possible on v12-) would be really handy. Nowadays we're adding that tax on the first invoice line (arbitrary) and then editing the amount on the subtotal section. The computed base amount by odoo on reports doesn't represent anything.
• For us it would make much more sense to add the tax on subtotal by choosing: tax, base amount, and amount. And that would create the aml without any need of linked base lines with tax_ids
• We also have some specific needs related to payment withholdings. Summarizing, when you pay or get paid you receive or apply different kind of withholdings for different amounts.
• This is the ideal for us

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Proffits withholding type 1		Proffits withholding type 1		60	600
4	Proffits withholding type 2		Proffits withholding type 2		80	400
5	Cash				1049

• This is the odoo proposal (to have all the base amounts computed by the tax base lines). Lines 6 till 11 are dummy lines just for the base amounts

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Profits withholding type 1		Profits withholding type 1		60	600
4	Profits withholding type 2		Profits withholding type 2		80	400
5	Cash				1049
6	Base for VAT withholding	VAT withholding		210
7	Negative for base VAT withholding				210
8	Base for Profits withholding type 1	Profits withholding type 1		600
9	Negative for Profits withholding type 1				600
10	Base for Profits withholding type 2	Profits withholding type 2		400
11	Negative for Profits withholding type 2				400

• We also know that in Brazil and some other countries, there are some webservices that returns the base amounts and taxes you need to apply to an invoice, Si in those use cases also the base amount of the tax may not be the sum of subtotals where the tax is applied

Summarizing.

• Odoo is working on removint tax_base_amount and enforcing that every aml that represents a tax should be created by some aml with that tax. The base amount of the tax would be the sum of the base lines
• IMHO
• That approach could work but requires a lot of dummy lines (plus and negative) to represent all the possible combinations of tax base amounts. This is not only for performance but also for db size, code complexity and bank reconciliation.
• to keep and improve, or at lease allow, the possibility of having amls taxes where the tax_base_amount represents the base amount, and the balance represents the tax amount, seems an easy to understand and flexible way to deal with base amounts on many different use cases
• Lastly, I also like the tax_base_amount field on the aml's as it's really easy to audit and check. On one record (the aml) you have all the data you need related to a tax.

Anyone else share these thoughts or can show me that my ideas are wrong?

Thanks!

Ing. Juan José Scarafía

(+54 9 341) 3 278039

twitter: @jjscarafia

github: @jjscarafia

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

--

Nhomar G Hernández

Vauxoo | CEO

¡Construyamos algo genial!
Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

México · Venezuela · Costa Rica · Perú

 nhomar@vauxoo.com  vauxoo.com/contactus  

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Hello Everyone.

It seams that odoo is going to deprecate the not so used field tax_base_amount 

The main reason odoo is going to do so is that now it may be inconsistent on how odoo is computing the base amount for a tax (the base for Odoo is always the sum of the balance of the aml's where the tax is applied on the tax_ids field)

Together with that field being deprecated, the idea behind is that there shouldn't be any aml (account.move.line) with tax_line_id that was not originated by another aml with tax_ids

We've some use cases where for us it's practical to be able to create tax aml's

Some examples:

• bank statements.
• on many banks operations (for eg. check deposits) we have expenses + taxes associated. So for on check deposit we may have 4 statement lines:
• check deposit (cash in)
• expense fee (cash out)
• tax 1 (based on the expense fee, cash out)
• tax 2 (based on the expense fee, cash out)
• On Odoo standard we're not able to reconcile that because we can't say that an statement line is 100% a tax In the odoo approach those two taxes should came from the tax being applied on the "expense fee"
• special invoice taxes
• we've some special invoice taxes where the base amount is not the subtotal of the invoice line but some specific computation (for ex. is the vat of that line)
• in that use case, we're storing the calculated base amount on tax_base_amount. Considering that the base amount is the sum of the subtotales of the lines where the tax is linked, is not correct.
• On master (and I believe 16 two). Odoo has a similar use case for belgium. When you offer a cash discount, no matter if the customer use it or not, the vat is computed on the discounted price. That's why there is a new option on the payment terms and, only for having the right base amount on the invoice, odoo is creating virtual lines (check attachment)
• supplier bills
• It's really common to receive supplier bills with some specific taxes that are totalized and without information on which are the base lines.
• in those use cases creating just a tax line (as it was possible on v12-) would be really handy. Nowadays we're adding that tax on the first invoice line (arbitrary) and then editing the amount on the subtotal section. The computed base amount by odoo on reports doesn't represent anything.
• For us it would make much more sense to add the tax on subtotal by choosing: tax, base amount, and amount. And that would create the aml without any need of linked base lines with tax_ids
• We also have some specific needs related to payment withholdings. Summarizing, when you pay or get paid you receive or apply different kind of withholdings for different amounts.
• This is the ideal for us

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Proffits withholding type 1		Proffits withholding type 1		60	600
4	Proffits withholding type 2		Proffits withholding type 2		80	400
5	Cash				1049

• This is the odoo proposal (to have all the base amounts computed by the tax base lines). Lines 6 till 11 are dummy lines just for the base amounts

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Profits withholding type 1		Profits withholding type 1		60	600
4	Profits withholding type 2		Profits withholding type 2		80	400
5	Cash				1049
6	Base for VAT withholding	VAT withholding		210
7	Negative for base VAT withholding				210
8	Base for Profits withholding type 1	Profits withholding type 1		600
9	Negative for Profits withholding type 1				600
10	Base for Profits withholding type 2	Profits withholding type 2		400
11	Negative for Profits withholding type 2				400

• We also know that in Brazil and some other countries, there are some webservices that returns the base amounts and taxes you need to apply to an invoice, Si in those use cases also the base amount of the tax may not be the sum of subtotals where the tax is applied

Summarizing.

• Odoo is working on removint tax_base_amount and enforcing that every aml that represents a tax should be created by some aml with that tax. The base amount of the tax would be the sum of the base lines
• IMHO
• That approach could work but requires a lot of dummy lines (plus and negative) to represent all the possible combinations of tax base amounts. This is not only for performance but also for db size, code complexity and bank reconciliation.
• to keep and improve, or at lease allow, the possibility of having amls taxes where the tax_base_amount represents the base amount, and the balance represents the tax amount, seems an easy to understand and flexible way to deal with base amounts on many different use cases
• Lastly, I also like the tax_base_amount field on the aml's as it's really easy to audit and check. On one record (the aml) you have all the data you need related to a tax.

Anyone else share these thoughts or can show me that my ideas are wrong?

Thanks!

Ing. Juan José Scarafía

(+54 9 341) 3 278039

twitter: @jjscarafia

github: @jjscarafia

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Hello Everyone.

It seams that odoo is going to deprecate the not so used field tax_base_amount 

The main reason odoo is going to do so is that now it may be inconsistent on how odoo is computing the base amount for a tax (the base for Odoo is always the sum of the balance of the aml's where the tax is applied on the tax_ids field)

Together with that field being deprecated, the idea behind is that there shouldn't be any aml (account.move.line) with tax_line_id that was not originated by another aml with tax_ids

We've some use cases where for us it's practical to be able to create tax aml's

Some examples:

• bank statements.
• on many banks operations (for eg. check deposits) we have expenses + taxes associated. So for on check deposit we may have 4 statement lines:
• check deposit (cash in)
• expense fee (cash out)
• tax 1 (based on the expense fee, cash out)
• tax 2 (based on the expense fee, cash out)
• On Odoo standard we're not able to reconcile that because we can't say that an statement line is 100% a tax In the odoo approach those two taxes should came from the tax being applied on the "expense fee"
• special invoice taxes
• we've some special invoice taxes where the base amount is not the subtotal of the invoice line but some specific computation (for ex. is the vat of that line)
• in that use case, we're storing the calculated base amount on tax_base_amount. Considering that the base amount is the sum of the subtotales of the lines where the tax is linked, is not correct.
• On master (and I believe 16 two). Odoo has a similar use case for belgium. When you offer a cash discount, no matter if the customer use it or not, the vat is computed on the discounted price. That's why there is a new option on the payment terms and, only for having the right base amount on the invoice, odoo is creating virtual lines (check attachment)
• supplier bills
• It's really common to receive supplier bills with some specific taxes that are totalized and without information on which are the base lines.
• in those use cases creating just a tax line (as it was possible on v12-) would be really handy. Nowadays we're adding that tax on the first invoice line (arbitrary) and then editing the amount on the subtotal section. The computed base amount by odoo on reports doesn't represent anything.
• For us it would make much more sense to add the tax on subtotal by choosing: tax, base amount, and amount. And that would create the aml without any need of linked base lines with tax_ids
• We also have some specific needs related to payment withholdings. Summarizing, when you pay or get paid you receive or apply different kind of withholdings for different amounts.
• This is the ideal for us

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Proffits withholding type 1		Proffits withholding type 1		60	600
4	Proffits withholding type 2		Proffits withholding type 2		80	400
5	Cash				1049

• This is the odoo proposal (to have all the base amounts computed by the tax base lines). Lines 6 till 11 are dummy lines just for the base amounts

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Profits withholding type 1		Profits withholding type 1		60	600
4	Profits withholding type 2		Profits withholding type 2		80	400
5	Cash				1049
6	Base for VAT withholding	VAT withholding		210
7	Negative for base VAT withholding				210
8	Base for Profits withholding type 1	Profits withholding type 1		600
9	Negative for Profits withholding type 1				600
10	Base for Profits withholding type 2	Profits withholding type 2		400
11	Negative for Profits withholding type 2				400

• We also know that in Brazil and some other countries, there are some webservices that returns the base amounts and taxes you need to apply to an invoice, Si in those use cases also the base amount of the tax may not be the sum of subtotals where the tax is applied

Summarizing.

• Odoo is working on removint tax_base_amount and enforcing that every aml that represents a tax should be created by some aml with that tax. The base amount of the tax would be the sum of the base lines
• IMHO
• That approach could work but requires a lot of dummy lines (plus and negative) to represent all the possible combinations of tax base amounts. This is not only for performance but also for db size, code complexity and bank reconciliation.
• to keep and improve, or at lease allow, the possibility of having amls taxes where the tax_base_amount represents the base amount, and the balance represents the tax amount, seems an easy to understand and flexible way to deal with base amounts on many different use cases
• Lastly, I also like the tax_base_amount field on the aml's as it's really easy to audit and check. On one record (the aml) you have all the data you need related to a tax.

Anyone else share these thoughts or can show me that my ideas are wrong?

Thanks!

Ing. Juan José Scarafía

(+54 9 341) 3 278039

twitter: @jjscarafia

github: @jjscarafia

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Hi Juan,

We used to generate tax lines for import charges as a tax only line.

When ordering products from foreign sources, a tax may be applied by the customs at time of import.

This tax is payable directly to the point of import, and is not associated with any lines.

We introduced a change to l10n_au (now included in Odoo enterprise) which defines an import tax:

au_tax_purchase_taxable_import

Which has is a tax included tax with a 100000000000 percent value.

This effectively allows a line on the invoice for a large figure, and with rounding, Odoo determines the base value as being the fraction of a cent and the whole amount ends up as tax, and then ends up in reporting, linked to an invoice line that has no real value.

Hope this gives you some ideas.

Richard

 

 

Kind Regards          Richard deMeester  Senior Development Analyst  www.willdooit.com  richard.demeester@willdooit.com          T: (03) 9135 1900 | M: 0403 76 76 76 | A: Bld 10/435 Williamstown Road, Port Melbourne, 3207

MAKING GROWTH THROUGH TECHNOLOGY EASY    Notice: This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, you may not disclose or use the information in this email in any way. If you have received this email in error please notify the sender. Although reasonable precautions have been taken to ensure no viruses are present in this email, no responsibility is accepted by WilldooIT Pty Ltd or its related entities for any loss or damage arising from the use of this email or attachments. Any views expressed in this email or file attachments are those of the individual sender only, unless expressly stated to be those of WilldooIT Pty Ltd  ABN 85 006 073 052 or any of its related entities.

 

---

From: Juan José Scarafía <notifications@odoo-community.org>
Sent: Friday, 9 June 2023 6:52 AM
To: Contributors <contributors@odoo-community.org>
Subject: tax_base_amount going to be deprecated. Anyone else using it?

 

Hello Everyone.

It seams that odoo is going to deprecate the not so used field tax_base_amount 

The main reason odoo is going to do so is that now it may be inconsistent on how odoo is computing the base amount for a tax (the base for Odoo is always the sum of the balance of the aml's where the tax is applied on the tax_ids field)

Together with that field being deprecated, the idea behind is that there shouldn't be any aml (account.move.line) with tax_line_id that was not originated by another aml with tax_ids

We've some use cases where for us it's practical to be able to create tax aml's

Some examples:

• bank statements.
• on many banks operations (for eg. check deposits) we have expenses + taxes associated. So for on check deposit we may have 4 statement lines:
• check deposit (cash in)
• expense fee (cash out)
• tax 1 (based on the expense fee, cash out)
• tax 2 (based on the expense fee, cash out)
• On Odoo standard we're not able to reconcile that because we can't say that an statement line is 100% a tax In the odoo approach those two taxes should came from the tax being applied on the "expense fee"
• special invoice taxes
• we've some special invoice taxes where the base amount is not the subtotal of the invoice line but some specific computation (for ex. is the vat of that line)
• in that use case, we're storing the calculated base amount on tax_base_amount. Considering that the base amount is the sum of the subtotales of the lines where the tax is linked, is not correct.
• On master (and I believe 16 two). Odoo has a similar use case for belgium. When you offer a cash discount, no matter if the customer use it or not, the vat is computed on the discounted price. That's why there is a new option on the payment terms and, only for having the right base amount on the invoice, odoo is creating virtual lines (check attachment)
• supplier bills
• It's really common to receive supplier bills with some specific taxes that are totalized and without information on which are the base lines.
• in those use cases creating just a tax line (as it was possible on v12-) would be really handy. Nowadays we're adding that tax on the first invoice line (arbitrary) and then editing the amount on the subtotal section. The computed base amount by odoo on reports doesn't represent anything.
• For us it would make much more sense to add the tax on subtotal by choosing: tax, base amount, and amount. And that would create the aml without any need of linked base lines with tax_ids
• We also have some specific needs related to payment withholdings. Summarizing, when you pay or get paid you receive or apply different kind of withholdings for different amounts.
• This is the ideal for us

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Proffits withholding type 1		Proffits withholding type 1		60	600
4	Proffits withholding type 2		Proffits withholding type 2		80	400
5	Cash				1049

• This is the odoo proposal (to have all the base amounts computed by the tax base lines). Lines 6 till 11 are dummy lines just for the base amounts

#	account	tax_ids	tax_id	debit	credit	tax_base_amount
1	Suppliers			1210
2	VAT withholding		VAT withholding		21	210
3	Profits withholding type 1		Profits withholding type 1		60	600
4	Profits withholding type 2		Profits withholding type 2		80	400
5	Cash				1049
6	Base for VAT withholding	VAT withholding		210
7	Negative for base VAT withholding				210
8	Base for Profits withholding type 1	Profits withholding type 1		600
9	Negative for Profits withholding type 1				600
10	Base for Profits withholding type 2	Profits withholding type 2		400
11	Negative for Profits withholding type 2				400

• We also know that in Brazil and some other countries, there are some webservices that returns the base amounts and taxes you need to apply to an invoice, Si in those use cases also the base amount of the tax may not be the sum of subtotals where the tax is applied

Summarizing.

• Odoo is working on removint tax_base_amount and enforcing that every aml that represents a tax should be created by some aml with that tax. The base amount of the tax would be the sum of the base lines
• IMHO
• That approach could work but requires a lot of dummy lines (plus and negative) to represent all the possible combinations of tax base amounts. This is not only for performance but also for db size, code complexity and bank reconciliation.
• to keep and improve, or at lease allow, the possibility of having amls taxes where the tax_base_amount represents the base amount, and the balance represents the tax amount, seems an easy to understand and flexible way to deal with base amounts on many different use cases
• Lastly, I also like the tax_base_amount field on the aml's as it's really easy to audit and check. On one record (the aml) you have all the data you need related to a tax.

Anyone else share these thoughts or can show me that my ideas are wrong?

Thanks!

Ing. Juan José Scarafía

(+54 9 341) 3 278039

twitter: @jjscarafia

github: @jjscarafia

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe