Ecotax management


(Richard PALO) #1

Has anybody taken the time to develop a mechanism to implement eco-contribution? (principally for supplier purchases)

In France, the most recent publication of the tarifs iséglementation/1_DEEE/1_Barème%20des%20éco-participations%20au%2015%20août%202018/Bareme%202018%20OK%20BD.pdf

I’m sort of at a loss on how others deal with the recent loss of tax info on the product via account_product
where I believe it was somewhat easy to implement (seems I quickly tried a year or so ago - although iirc things needed to be on the variant and not the template).

The eco code could possibly be put in an attribute with perhaps an accounting category variant created including eco contribution but how now, in this case, to use this eco-contribution code attribute on the product to select the correct eco participation “tax” in order calculate the amount of the contribution which is to be included in the price for VAT purposes and put that amount in the correct account?


(Cédric Krier) #2

The eco-tax is not a tax because it is a part of the product price. It will be wrong to use tax mechanism for it.
So on purchase there is nothing to do except put the price with the eco-tax included. Except if the eco-tax is not paid directly to the supplier but to another company in charge of the service, in this case it is just a purchase of a service (and account_stock_landed_cost can be used to update the cost price of the product).
For sale, it is quiet the same, it should be included in the price except that its part should be display. So this could be done by adding a field on the product or account category.
Some report could be needed about product sold with such eco-tax.

(Richard PALO) #3

No, that’s for end-user (consumer).
For distributors (or assimilated such as an installation company) it is a pass-through…
Purchases have two accounts (one for the product, one for the contribution) and sales as well.
VAT is on the cumulated amount.
[added] I should perhaps mention the reason is that, in France at least, it is not acceptable to marge the eco-participation.
BTW - eco participation should not be called eco-tax(a banned term since a real long time since it is not a tax)
The usefulness of using taxes is(or was) 1) possibility to affect to a different account while affecting the price of the line item after margin, 2) separate display, and 3) the possibility of have date ranges for the contribution. There are perhaps more.
Perhaps there should simply be something similar as the tax mechanisms to be able to add sub line items to products , which may be related to packaging, installation, transport.
Also, I forgot the link to the contribution for furniture elements

(Cédric Krier) #4

As far as I see there are no such obligation.
But one could extend the Invoice to put the ecotax in another account.

That’s why the ecotax should be in the unit price.

Except it is wrong because the ecotax will not be included in the cost price computation of the product.

(Richard PALO) #5

Okay, invoicing extension for the accounts, but …

If using attributes to store the DEEE or DEA code, how to reference in the price list processing this attribute in order to calculate the amount to be added to the cost price?
(ignoring, for the moment, any potential validity date issues)
Something like {“DEEE”:“65020”} which, by the way, still needs to lookup the amount for the code.
Or would this need purchase/sale, product and/or price_list module extensions too?

(Cédric Krier) #6

I think the customs module is a good example on how it could be designed.
For the usage on price list, the module is designed to ease the addition of variable in the context evaluation.