Split of the ecotax modules

[florian-dacosta]

The ecotax modules did change a lot these last months. There are different ways to implement it. 1) The original module (l10n_fr_account_ecotaxe), where we do NOT use odoo taxes, because the ecotax is not actually a tax or at least a different type of tax because as far as I know it must count in the turnover.

2) The new module (account_ecotax) which DO use odoo taxes, because, it is quite practical.

From what I see, is that, depending on the use cases, the first solution may be preferable and for others, the second one is better. (At least, I have a customer, working on previous version who won't accept to migrate to the second one, with tax, I'll explain why below)

After looking at the differences between the version 1) and 2), what I see is that most of the code (maybe 90% or more) is the same. So, I was wondering if it would be worth it to maintain both mode, or at least, split the present modules to allow the other implementation, even if we do not maintain the other implementation in the OCA.

As a first step, I propose to have : 1 base module : account_ecotax_base, with 90% of the current code of current account_ecotax, basically every thing but what is linked to the account.tax Having a second module account_ecotax_tax (or something like that, feel free to propose a better name) that would only implement the account.tax related features.

And do the exact same for the sale part : account_ecotax_sale_base and account_ecotax_sale_tax

Then, We'd be able to have 2 concurrent modules to account_ecotax_tax and account_ecotax_sale_tax, that would do the implementation without using the account.tax. These 2 could not be in the OCA if we consider it would be to confusing to have 2 concurrent modules (which to choose in which cas maybe quite hard if you did not dig the subhect), we could decide that later.

The advantage is that all of 98% of the database structure needed for ecotax modules would be common, so in the base modules. Additional modules helping the declaration, doing statistics of whatever should also work for both cases (could depend only on the base modules, because it would be using the common model account.move.line.ecotax)

Now, I'll try to list a bit the advantages of both modes. Here is the list of differences I see between the 2 ways :

Advantages using odoo's tax system : 1) You can choose if the ecotax amount is included in the price_unit (by setting the tax as included or not) It is a nice feature, mainly for B2B companies or at least some of them. 2) You can choose if you want to apply the discount on the price whithout ecotax or with ecotax (by setting the same parameter as above, if price is not included, discount won't apply on the ecotax amount). 3) The ecotax amount is isolated in the accounting account, inside the invoice accounting entries (the other way would require an aditional module, probably generating accounting entries in a seperated journal...)

Disadvantages with odoo tax : 1) Odoo consider ecotax as a tax, and so, the price_subtotal does not contain the ecotax amount. So in all Odoo reporting, you don't see the ecotax amount in the price subtotals. But ecotax is actually a part of the turnover, and I guess the subtotal should take it into account. So if you analyse your turnover from a general balance, it would be ok (because you can configure a revenue account on your ecotax tax) but if you do the same analyze from your customer invoice, you would not have the same result. It seems important that the ecotax is part of the price_subtotal for sale orders and invoice This is the main issue of this implementation IMO. 2) A bit more complicated to configure and maybe a bit more fragile (you have to configure a tax with specific configuration for it to work.

• in specific cases whare you don't want/can't have the configuration at product level, it would force you to have a lot of taxes (I have a case like this, but I agree it is quite specific)

Separating the present 2 modules in 4 module does not really add a technical complexity, but it allows to ease the possibility of working in an other manner. I could do the necessary, while the PR are not merged yet... Also, I would not change the database structure, so the "migration" should be quite straightforward

I am aware it is one more change in modules that already have changed, and these modules, although not merged may already be used in production. But this time, it would add more flexibility and I think it really worth it doing it now. (it is quite easy to do and could help us a lot for project where the tax implementation is not the best way to go)

Opinions are welcome @gurneyalex @mourad-ehm @hparfr @bealdav @yankinmax @epanisset @rvalyi

[hparfr]

I'm in favor for the split. Thanks @florian-dacosta

[mourad-ehm]

Thanks @florian-dacosta for this explanation. I'm OK to split

[bealdav]

Ok for the Split. Thanks

[epanisset]

Hello, Thanks for the message, I don't see any issue with the split. I am also attached to the previous way of managing ecotax 'l10n_fr_account_ecotaxe' but I also understand why we want to bring it back to a more tax standard way, and to make it available not only on the french legislastion.