Here's a backport of the latest patch in review3341002 for tryton 3.0. It drops
the start_date/end_date and drop the parent relationship of old taxe rates so
that they remain separate instead of being used on products tagged with the
parent tax.

This means I tested the account.py update code and it worked well. Thank you Cédric!

Thanks, it cleared my doubt about renamed tax code. So I uploaded a new version
where new tax codes are created instead of replaced.

The main form 3310-CA3:
http://www.impots.gouv.fr/portal/deploiement/p1/fichedescriptiveformulaire_8754/fichedescriptiveformulaire_8754.pdf

A complementary form that we use sometimes:
http://www.impots.gouv.fr/portal/deploiement/p1/fichedescriptiveformulaire_8761/fichedescriptiveformulaire_8761.pdf

Here is the version with tax historization and migration: review3341002
I still have some doubt about the tax code names and configuration, could
someone provide an example of the VAT declaration for 2014?

On 31 Jan 10:00, Raphaël Hertzog wrote:
> So the tax patches alone is in review3161002
> 
> The historization feature has not yet been committed how can I already rely on
> it? We can't force French users to wait until 3.2 and not do anything until then.

Yes it will. No data change inside series.

> And even with historization/timeline, this would mean that the parent tax (which
> should be independent from the tax rate) would have to reuse the current
> identifier which embeds the tax rate. This is not very clean IMO.

Yes, ir.model.data will need to be updated.

I was also wondering. Could the module maybe embed some Python upgrade code that
would do the tax replacement on products automatically ?

So the tax patches alone is in review3161002

The historization feature has not yet been committed how can I already rely on
it? We can't force French users to wait until 3.2 and not do anything until then.

And even with historization/timeline, this would mean that the parent tax (which
should be independent from the tax rate) would have to reuse the current
identifier which embeds the tax rate. This is not very clean IMO.

I was wondering though, is it possible/reasonable to keep the old identifiers in
the tax_fr.xml file but clearly mark them as obsolete ? Because right now, when
I do the update, the old taxes are kept around and they are not marked as
obsolete. People can sort this out except that for the 5,5% rate which is
unchanged we have the same tax name twice... (one for the old rate-specific
identifier and one for the rate-agnostic identifier, and the full view doesn't
display the tax identifier..)

Please provide a patch for one feature. So here only the patch about the tax
rate change. Which by the way, really need to use the historization to give to
existing users an easy path to update.

I'm not convinced that we need historization first. I have submitted a patch in
review3121002 ... users will have to adapt their products but it's sort of
required anyway since the chart of account embeds the rate in the identifier. :-|

L'application des taux France métropolitaire et DOM/TOM en 2014 :
http://vosdroits.service-public.fr/professionnels-entreprises/F23567.xhtml

Indeed we need first the historization as define in issue3600

Thanks to submit issue in English.

J'ai modifié le fichier account_fr.tax_fr.xml en remplaçant ce qui est relatif à
19.6% par 20% et ce qui est relatif à 7% par 10%. Si la procédure est correcte,
je soumettrai un patch.