Archives
Contributors
-
Re: Proposing myself as Tools PSC
+1 Thank you for your contributions to the communityEl sáb, 17 jun 2023 a la(s) 11:37, Carlos Lopez (notifications@odoo-community.org) escribió:+1El sáb, 17 jun 2023 a las 8:57, Juan José Scarafía (<notifications@odoo-community.org>) escribió:El sáb, 17 jun 2023 a la(s) 08:57, Sergio Corato (notifications@odoo-community.org) escribió:+1^¹⁰Sergio CoratoIl giorno sab 17 giu 2023 alle ore 13:37 Rémy Taymans <notifications@odoo-community.org> ha scritto:You get my vote, Sylvain. :)_______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Saludos Cordiales._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Luis Romero - 04:06 - 18 Jun 2023 -
Re: Proposing myself as Tools PSC
+1El sáb, 17 jun 2023 a las 8:57, Juan José Scarafía (<notifications@odoo-community.org>) escribió:El sáb, 17 jun 2023 a la(s) 08:57, Sergio Corato (notifications@odoo-community.org) escribió:+1^¹⁰Sergio CoratoIl giorno sab 17 giu 2023 alle ore 13:37 Rémy Taymans <notifications@odoo-community.org> ha scritto:You get my vote, Sylvain. :)_______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Saludos Cordiales.
by Carlos Lopez - 06:35 - 17 Jun 2023 -
Re: Proposing myself as Tools PSC
El sáb, 17 jun 2023 a la(s) 08:57, Sergio Corato (notifications@odoo-community.org) escribió:+1^¹⁰Sergio CoratoIl giorno sab 17 giu 2023 alle ore 13:37 Rémy Taymans <notifications@odoo-community.org> ha scritto:You get my vote, Sylvain. :)_______________________________________________
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
by Juan José Scarafía - 03:56 - 17 Jun 2023 -
Re: Proposing myself as Tools PSC
+1^¹⁰Sergio CoratoIl giorno sab 17 giu 2023 alle ore 13:37 Rémy Taymans <notifications@odoo-community.org> ha scritto:You get my vote, Sylvain. :)_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 01:56 - 17 Jun 2023 -
Re: Proposing myself as Tools PSC
You get my vote, Sylvain. :)
by Rémy Taymans - 01:36 - 17 Jun 2023 -
Re: Proposing myself as Tools PSC
+1
Il 16/06/2023 23:12, Sylvain LE GAL (GRAP) ha scritto:
Hi all,
I like to become member of the "Tools PSC Team". (https://odoo-community.org/psc-teams/tools-30). My contributions in this area:
- Funder of interface-github and odoo-module-migrator repositories
- I have proposed the following modules to the community : auth_admin_passkey, module_analysis, module_change_auto_install, server_action_navigate, pos_environment, user_all_groups and deeply refactored : server_action_mass_edit (formely "mass_editing")
Thanks for your attention.
-- Sylvain LE GAL - GRAP, service informatique - 3 Grande rue des Feuillants 69001 LYON, 09.72.32.33.17 - Astreinte : 06.81.85.61.43 // informatique@grap.coop
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Antonio M. Vigliotti
Mobile (+39) 342.8740910
by Antonio M. Vigliotti - 09:46 - 17 Jun 2023 -
-
Re: Proposing myself as Tools PSC
+1
16 jun. 2023 23:12:08 Sylvain LE GAL (GRAP) <notifications@odoo-community.org>:
Hi all,
I like to become member of the "Tools PSC Team". (https://odoo-community.org/psc-teams/tools-30). My contributions in this area:
- Funder of interface-github and odoo-module-migrator repositories
- I have proposed the following modules to the community : auth_admin_passkey, module_analysis, module_change_auto_install, server_action_navigate, pos_environment, user_all_groups and deeply refactored : server_action_mass_edit (formely "mass_editing")
Thanks for your attention.
-- Sylvain LE GAL - GRAP, service informatique - 3 Grande rue des Feuillants 69001 LYON, 09.72.32.33.17 - Astreinte : 06.81.85.61.43 // informatique@grap.coop
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Tom Blauwendraat - 05:56 - 17 Jun 2023 -
Re: Proposing myself as Tools PSC
+1.00000thanks for your job SylvainFlorent THOMAS
☎ +33 972 457 755
✉ florent.thomas@mind-and-go.comMind & Go
14, Rue Pierre Cartelet | 66000 PERPIGNANDe: "Sylvain LE GAL (GRAP)" <notifications@odoo-community.org>
À: "contributors" <contributors@odoo-community.org>
Envoyé: Vendredi 16 Juin 2023 23:12:01
Objet: Proposing myself as Tools PSCHi all,
I like to become member of the "Tools PSC Team". (https://odoo-community.org/psc-teams/tools-30). My contributions in this area:
- Funder of interface-github and odoo-module-migrator repositories
- I have proposed the following modules to the community : auth_admin_passkey, module_analysis, module_change_auto_install, server_action_navigate, pos_environment, user_all_groups and deeply refactored : server_action_mass_edit (formely "mass_editing")
Thanks for your attention.
-- Sylvain LE GAL - GRAP, service informatique - 3 Grande rue des Feuillants 69001 LYON, 09.72.32.33.17 - Astreinte : 06.81.85.61.43 // informatique@grap.coop
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Florent THOMAS - 12:11 - 17 Jun 2023 -
Re: Proposing myself as Tools PSC
+1Le ven. 16 juin 2023, 23:41, Raphaël Valyi <notifications@odoo-community.org> a écrit :+1 of course!Thank you so much for all the hard work in the OCA BTW.On Fri, Jun 16, 2023 at 6:12 PM Sylvain LE GAL (GRAP) <notifications@odoo-community.org> wrote:
Hi all,
I like to become member of the "Tools PSC Team". (https://odoo-community.org/psc-teams/tools-30). My contributions in this area:
- Funder of interface-github and odoo-module-migrator repositories
- I have proposed the following modules to the community : auth_admin_passkey, module_analysis, module_change_auto_install, server_action_navigate, pos_environment, user_all_groups and deeply refactored : server_action_mass_edit (formely "mass_editing")
Thanks for your attention.
-- Sylvain LE GAL - GRAP, service informatique - 3 Grande rue des Feuillants 69001 LYON, 09.72.32.33.17 - Astreinte : 06.81.85.61.43 // informatique@grap.coop
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Houssine BAKKALI - 11:51 - 16 Jun 2023 -
Re: Proposing myself as Tools PSC
+1 of course!Thank you so much for all the hard work in the OCA BTW.On Fri, Jun 16, 2023 at 6:12 PM Sylvain LE GAL (GRAP) <notifications@odoo-community.org> wrote:Hi all,
I like to become member of the "Tools PSC Team". (https://odoo-community.org/psc-teams/tools-30). My contributions in this area:
- Funder of interface-github and odoo-module-migrator repositories
- I have proposed the following modules to the community : auth_admin_passkey, module_analysis, module_change_auto_install, server_action_navigate, pos_environment, user_all_groups and deeply refactored : server_action_mass_edit (formely "mass_editing")
Thanks for your attention.
-- Sylvain LE GAL - GRAP, service informatique - 3 Grande rue des Feuillants 69001 LYON, 09.72.32.33.17 - Astreinte : 06.81.85.61.43 // informatique@grap.coop
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant
by "Raphaël Valyi" <rvalyi@akretion.com> - 11:40 - 16 Jun 2023 -
Proposing myself as Tools PSC
Hi all,
I like to become member of the "Tools PSC Team". (https://odoo-community.org/psc-teams/tools-30). My contributions in this area:
- Funder of interface-github and odoo-module-migrator repositories
- I have proposed the following modules to the community : auth_admin_passkey, module_analysis, module_change_auto_install, server_action_navigate, pos_environment, user_all_groups and deeply refactored : server_action_mass_edit (formely "mass_editing")
Thanks for your attention.
-- Sylvain LE GAL - GRAP, service informatique - 3 Grande rue des Feuillants 69001 LYON, 09.72.32.33.17 - Astreinte : 06.81.85.61.43 // informatique@grap.coop
by Sylvain LE GAL - 11:10 - 16 Jun 2023 -
Re: Documentation on Management System module and its related sub-modules
Hello Ketan.
You should find a few links in the repository README.
And I also did a presentation on it in last year's OCA Days:
https://www.youtube.com/watch?v=w2nf_O9TajM
Thanks
Daniel
--
DANIEL REIS
MANAGING PARTNERM: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office B, 3º Escr.34, 2649-517 Cascais
by Daniel Reis - 01:17 - 16 Jun 2023 -
Documentation on Management System module and its related sub-modules
I was hoping if someone here can help or guide me in gaining any kind of detailed documentation / user guide for the OCA module https://github.com/OCA/management-system and all its sub-modules so that it gives a good understanding on how to best install and use it.
Thank you in anticipation
by Ketan Chandaria - 05:40 - 16 Jun 2023 -
Re: tax_base_amount going to be deprecated. Anyone else using it?
Hi Nhomar!I don't have a PR. It was a conversation with Odoo team (localizations PO) + developer.The "rationale" that I understood from the conversation was:
- nowadays, on odoo standard, there is no usage of the tax_base_amount except on the tax audit report view
- on odoo reports, they are considering as the tax_base_amount the amount of the base lines where those taxes where applied. so there could be some difference between the stored tax_base_amount and the one used on reports
- my opinions:
- instead of fixing/improving it, just removing seems easier
- in countries where the tax is send globally, tax_base_amount on the tax line it self makes lot of sense (simpler code, less lines, less complexity, less computations)
- in countries where the taxes are computed and reported by line, may be something different is needed
Example of odoo report where they are not using the tax_base_amount but computing itEl mar, 13 jun 2023 a la(s) 03:52, Nhomar Hernández (notifications@odoo-community.org) escribió:Hello @Juan José ScarafíaCan 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_amountThe 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_idsWe've some use cases where for us it's practical to be able to create tax aml'sSome 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!_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Juan José Scarafía - 04:35 - 13 Jun 2023 -
Re: tax_base_amount going to be deprecated. Anyone else using it?
Hello @Juan José ScarafíaCan 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_amountThe 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_idsWe've some use cases where for us it's practical to be able to create tax aml'sSome 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!_______________________________________________
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: @nhomarMéxico · Venezuela · Costa Rica · Perú
by Nhomar Hernández - 08:51 - 13 Jun 2023 -
Re: tax_base_amount going to be deprecated. Anyone else using it?
Hi Juan,I'm also from Argentina so we use it too. I agree with all your points and I really don't like the suggested "way" of doing it that Odoo is proposing.The deprecation of this field is a final decision? I think we will need to find a new approach to this, since all those dummy lines are confusing even for accounting people.On Thu, Jun 8, 2023 at 5:52 PM Juan José Scarafía <notifications@odoo-community.org> wrote:Hello Everyone.It seams that odoo is going to deprecate the not so used field tax_base_amountThe 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_idsWe've some use cases where for us it's practical to be able to create tax aml'sSome 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!_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Nicolas Rodriguez Sande - 02:11 - 13 Jun 2023 -
Re: tax_base_amount going to be deprecated. Anyone else using it?
Hi Richard!Thanks, I believe we've a similar need. On imports we register "purchase bills" for the import import clearance where you only pay taxes.What we're doing till now is adding invoice lines that represent each base amount with the corresponding taxes and later on negative lines to balance the.Indeed doing what you said could work but we wouldn't have the tax_base_amout (and we needed for later tax declaration)Thanks!El jue, 8 jun 2023 a la(s) 23:01, Richard deMeester (notifications@odoo-community.org) escribió: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
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_amountThe 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'sSome 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!
_______________________________________________
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
by Juan José Scarafía - 10:00 - 10 Jun 2023 -
Re: New repository OCA/sign
>>> On our side we developed integration to Lex Persona >> I will start working on the electronic signature in the next few weeks, >> maybe with lex persona. >> Do you plan to open source your work? >> > Yes indeed > I cloned the repo yesterday and I'm gonna push soon. > But there will be hard work to be OCA compliant :-/ > You're welcome to help... Great ! I will contribute with pleasure, let me know when it is available to take a look. Simon > Best regards > -------------------------------- > Cyril VINH-TUNG > INVITU > Computer & Network Engineering > BP 32 - 98713 Papeete - French Polynesia > Tél: +689 40 46 11 99 > contact@invitu.com <mailto:contact@invitu.com> > www.invitu.com <http://www.invitu.com> > > Le ven. 9 juin 2023, 21:52, Simon Maillard > <notifications@odoo-community.org > <mailto:notifications@odoo-community.org>> a écrit : > > On 21/04/2023 18:31, Cyril VINH-TUNG wrote: > > Hello, > > (https://www.lex-persona.com/plateforme-de-signature-electronique/ > <https://www.lex-persona.com/plateforme-de-signature-electronique/> > > <https://www.lex-persona.com/plateforme-de-signature-electronique/ > <https://www.lex-persona.com/plateforme-de-signature-electronique/>>) > > which is a french API to sign documents on the fly. > > > Hi Cyril, > > > Regard, > Simon > > -- Simon Maillard simon@ogesta.fr <mailto:simon@ogesta.fr> > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > <https://odoo-community.org/groups/contributors-15> > Post to: mailto:contributors@odoo-community.org > <mailto:contributors@odoo-community.org> > Unsubscribe: https://odoo-community.org/groups?unsubscribe > <https://odoo-community.org/groups?unsubscribe> > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 > <https://odoo-community.org/groups/contributors-15> > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe > <https://odoo-community.org/groups?unsubscribe> > -- Simon Maillard simon@ogesta.fr - 0680587358
by Simon Maillard - 03:01 - 10 Jun 2023 -
Re: [FIX]:Weblate - use po file download/upload - revisions
Hi Stefano,I also support the idea, obviously ;)Unfortunately that alone will not help get things moving as I have several other priorities with OCA infrastructure and tooling that already barely fit in the time I can allocate to it.For instance, just preventing weblate to bring down the OCA server swallowed several hours already, recently (and there is still more to do).I'm happy to tweak any configuration you propose but I'd need precise indications of what to do with links to the weblate documentation.The process part also needs to be elaborated. The high level principle you mentioned sound good but how do we concretely do that in practice? For instance, when one asks to get translation access how will Rebecca know which role to give them? What is the process to accept a new reviewer for a given language? Can we have languages with reviewers and other without? Do we need to publish who has reviewer rights? What does all that imply in terms of weblate configuration?Regarding glossaries and translation memories there are also important questions to be investigated. For instance, we now have one project per repo and branch. Is it possible to share glossaries across these? If not, should we / can we group them? Who should have permissions to manage glossaries, etc.So there is quite a bit of research to do that, as far as I know, as not been done by anyone yet.As I don't think these can be easily experimented live on the OCA instance (I may be wrong about that), I'd recommend anyone who would like to dive in that to setup a test weblate on their local machine and play with that to come up with a proposal or a plan. I'm happy to help with that too.Best regards,-StéphaneOn Thu, Jun 8, 2023 at 10:01 PM Stefano Consolaro <notifications@odoo-community.org> wrote:Hi Stéphane,did you give a look to mine and Sergio replies (i attached them below)?Last month, as italian community, we had the Odoo Italia Days in Milan. We talked with other people interested in setting up a better way to manage translations, at least for italian language.We met Simone Orsi, OCA member, that support this idea.In fact we think that what we are looking for could be useful for all language teams.If you, or someone else, can invest some time to configure Weblate to activate the requested features, we can test it and give a fast feedback.Obviously, we welcome all people willing to join the project.Thanks for your time and help.StefanoDa "Stefano Consolaro" stefano.consolaro@mymage.itCcData Mon, 23 Jan 2023 08:40:30 +0100Oggetto Re: [FIX]:Weblate - use po file download/upload - revisions
I give my reply for italian language/community:
> Clearly define the problem we are attempting to solve? For instance, Is it "vandalism" of existing translations (this could be solved by banning offenders)? Or is it incorrect/low quality new translations (which can be fixed easily after the fact, I suppose)? Or something else?
As far I know we don't have problems of a misuse of the tool. What we noticed is that the "need" and the "hurry" to have the translations, or a lack in the definition of a glossary for common terms, or the contributions of a new entry (like in part I am), goes to some incorrect or not so pertinent translations.
> What would be the process to appoint/elect reviewers? Currently we accept anyone who asks.> How to make sure translation proposals are not stuck for too long waiting for review?
Hm, here I don't know what to say, can't be done in the "same way" that PSC are nominated for repository in GitHub?
Yes, this is a weakness. I don't know if it can be done and how, but I'd like to have a system in which the reviewed terms can be changed only by reviewers and other terms can be changed (and then loaded) by anyone (view *).
> Should/can we enable the review process per language? This may be important as not all language communities have the resources to have dedicated reviewers.
Absolutely yes: the lack of resources is a problem and (*) I prefer that a thing is done now than perfect never. So the activation of the review process should be decided by each community.Thanks for expanding the discussion, I hope others will join.Da "Sergio Zanchetta" notifications@odoo-community.orgA "Contributors" contributors@odoo-community.orgCcData Mon, 23 Jan 2023 10:36:56 -0000Oggetto Re: [FIX]:Weblate - use po file download/upload - revisionsIl giorno dom 22 gen 2023 alle ore 11:27 Stéphane Bidoul <notifications@odoo-community.org> ha scritto:We discussed a translation review mechanism before, I think, but IIRC we concluded we need a process first.Yes, you are right. :-)Below, as italian community in addition to Stefano answers, you can find a proposal.Here are a few questions that come to mind. There might be more.- Clearly define the problem we are attempting to solve? For instance, Is it "vandalism" of existing translations (this could be solved by banning offenders)? Or is it incorrect/low quality new translations (which can be fixed easily after the fact, I suppose)? Or something else?The second one. Incorrect/low level translations, not only new, that don't follow current community guidelines and glossaries (language specific).- What would be the process to appoint/elect reviewers? Currently we accept anyone who asks.- How to make sure translation proposals are not stuck for too long waiting for review?I would replicate Transifex structure or similar, if possible. Here is a proposal:- Anyone can be accepted as translator, strings are pushed as soon as translated. (or on a periodic basis)- There is a reviewer role, reviewed strings are freezed and can't be changed by translators.- The coordinator role has reviewer power and can appoint translators as reviewers.The coordinator could be nominated by each localization repository PSC. (l10n-*)He would be in charge of appointing reviewers evaluating the quality of their translations over time, based on guidelines/glossary compliance.- Should/can we enable the review process per language? This may be important as not all language communities have the resources to have dedicated reviewers.Sure, I add that not all communities have translation guidelines. [*][*] e.g. italian guidelines (and glossaries) https://www.odoo-italia.org/documentazione/14.0/traduzioni.htmlDa "Stéphane Bidoul" notifications@odoo-community.orgA "Contributors" contributors@odoo-community.orgCcData Sun, 22 Jan 2023 10:27:40 -0000Oggetto Re: [FIX]:Weblate - use po file download/upload - revisions
We discussed a translation review mechanism before, I think, but IIRC we concluded we need a process first.Here are a few questions that come to mind. There might be more.- Clearly define the problem we are attempting to solve? For instance, Is it "vandalism" of existing translations (this could be solved by banning offenders)? Or is it incorrect/low quality new translations (which can be fixed easily after the fact, I suppose)? Or something else?- What would be the process to appoint/elect reviewers? Currently we accept anyone who asks.- How to make sure translation proposals are not stuck for too long waiting for review?- Should/can we enable the review process per language? This may be important as not all language communities have the resources to have dedicated reviewers.Best regards,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 02:30 - 10 Jun 2023
