French accounting: missing tax mappings in fiscal positions

French l10n experts could you please confirm and give more detailed instructions to fill the tax mappings ?
Lionel.

Hello Numérigraphe ,

I have checked your issue . Tax is mapping with all fiscal positions.
You mind have done some wrong configuration like type sale /purchase .Please check further.
If you still got the problem . undoubtedly inform us .

Thanks!

Hello,

Lionel is right, the fiscal positions and taxes on l10n_fr are incomplete and false.

As instance, if you create a sale order with the fiscal position Zone Euro with
 - a product at 199 € with a "TVA collectée (vente) 19,6%" tax

The "TVA collectée (vente) 19,6%" tax will be replaced by :
 - TVA due intracommunautaire 19,6% (% ratio: -0.1960 )
 - TVA 0% exportation (% ratio: 0)

This means that your product will be sold : 160€ with -39€ of taxes!

The "TVA déductible intracommunautaire" 19,6% is missing.

Also, in the fiscal positions "Hors Euro" as instance, there is no tax mapping at all.

So could you reconsider this issue please ?
Thanks
Guewen

Hello,

I have checked further,Some of tax have no mapping .
My request to French experts ,please provide sufficient information on "tax mapping " in French scenario.

Thanks!!!

Hi there,

We recentely have some time to reviewed l10n_fr for few french customers implementation.
We noticed that the current set-up is wrong in many places wich make l10n_fr unusable 'out-of-thebox'

Please do the following changes :
- go to the chart of account and change the type of account 44566 from 'view' to 'normal'
- go to the chart of account and make account 4456 parent of the account 445662
- go to the tax list view and change coef to -1 for invoices and 1 for refund for all taxes with type 'purchases'
- taxes 2,3 and 4 : change account for refund : use 445713 instead of 44571
- taxes 13, 14, 15 and 16 :
 type must be 'purchases' (instead of 'sales') --> so coef must be -1 for invoices and 1 for refunds
-

Changes taxes the following way (following taxes current numbers/sequence):

1 - ok
2 - account for refund : use 445713 instead of 44571
3 - account for refund : use 445713 instead of 44571
4 - account for refund : use 445713 instead of 44571
tax no 5 to 12

- on tax form vue : change coef. to -1 on invoices (1 for refunds

oups ... comment posted but unfinished...let me start again

Hi there and thanks lionel for opening this bug (it is on my TODO for ages but this time I take the opportunity)

We recentely have some time to review l10n_fr for few french customer implementations we noticed that the current set-up is wrong in many places which make l10n_fr unusable 'out-of-the-box'. So I have listed necessary changes that we had to do:

on chart of account:
- go to the chart of account and change the type of account 44566 from 'view' to 'normal'
- go to the chart of account and make account 4456 parent of the account 445662

on taxes:
- taxes 2,3 and 4 : change account for refund : use 445713 instead of 44571
- taxes 13, 14, 15 and 16 :
     *type must be 'purchases' (instead of 'sales') --> so coef must be -1 for invoices and 1 for refunds
     *remove the base tax code (for invoice & refund of course) and leave it blank
- tax 13 : change account for refund : use 445201 instead of 4452
- tax 14 : change account for refund : use 445203 instead of 4452
- tax 15 : change account for refund : use 445202 instead of 4452
- tax 16 : change account for refund : use 445203 instead of 4452
- tax 21 : it is a tax on sales (not on purchases)
- tax 23 : tax account 445201 for invoice & refund (instead of 44571)
- change coef to -1 for invoices and 1 for refunds for all taxes with type 'purchases'

on fiscal positions:
Only 2 fiscal positions are necessary (so remove others)

'Zone Euro'
     *please rename 'Zone Intracommunautaire' as it has nothing to do with the currency EUR so it can be confusing)
     *please make sure the mapping is now the following:
          1 -> 23
          2 -> 23
          3 -> 23
          4 -> 23
          5 -> 13
          5 -> 17
          6 -> 14
          6 -> 18
          7 -> 15
          7 -> 19
          8 -> 16
          8 -> 20

'Import/Export'
          1 -> 22
          2 -> 22
          3 -> 22
          4 -> 22
          5 -> 21
          6 -> 21
          7 -> 21
          8 -> 21

Thanks for considering these changes and making corrections.
I cannot explain here everything it would be too long be but do not hesitate to ask me questions
Thanks

Frederic @ Camptocamp

I have created an OPW about this so please tag it 'maintenance'
Thanks
Frederic

Frederic, of course you are 100% right !

It would be a good thing that Simon Jaillet from www.crysalead.fr confirms it (as he is the first author for the module)

best regards

I am preparing the merge proposal for addons-trunk

There is lack for DOM-TOM fiscal position. For other points, validation must be done point by point. for me, tax for euro zone must be a tax with 2 childs, one with 19.6% and the other with -19.6% and 2 differents accounts (childs of 44566 and 4452) like in http://www.eguens.com/v2/comptabilite/cours/tva-intracommunautaire.php

Here is my work :

https://code.launchpad.net/~akretion-team/openobject-addons/trunk-fix-l10n_fr-round1

I haven't initiated the merge proposal yet ; I plan to do it very soon. All comments are welcomed. I called this branch "round1", because I don't intend to fix all issues with l10n_fr right now. There will be other merge proposals (round2, round3, ...) in the future to fix more points.

In this "round1", there are all the changes proposed by Frederic in comment #7 along with some other changes that are listed in the commit messages.

@hedererjs : the implementation for VAT in the EU is similar to the solution that you propose ; the implementation is not the same (we replace the VAT 19.6% tax by two taxes), but the result is the same.

As promised, I have made the merge proposal :

https://code.launchpad.net/~akretion-team/openobject-addons/trunk-fix-l10n_fr-round1/+merge/104985

Hello,

I would like to make clear that the current i10n_fr does not handle intra-european purchases without VAT.
I opened several times a bug but it was closed each time because developers did not understand.

When you purchase from the European Union without VAT, you should declare VAT and refund it immediately.
The reason behind is to be able for customs to be able to control your Intrastat buying.

At present I consider OpenERP going against the French accounting rules.
People using i10n_fr are eligible for a 3% fine on tax declaration because tax amounts are always WRONG when including intra-european purchases.

Are you going to fix intra-european purchase without VAT?
In today's world EVERY company makes at least a purchase every month.

If this not fixed, I consider contacting the French customs and/or the French tax to have OpenERP officially banned.
I am not kidding, we have to comply with laws, even if OpenERP is free software. It make NO difference.

Just another comment:

The "TVA déductible intracommunautaire" 19,6% is missing.

IMHO there should be no "TVA déductible intracommunautaire".

There are two cases:

* Either you buy goods (let's say Germany) with German VAT. You cannot deduct the VAT and have to pay the French VAT on imports on the total. Yes, you have to pay twice: French and German VAT. Then you deduct French VAT.

* If you buy goods from the EU without VAT, you should pay VAT and deduct it immediately.

So using TVA déductible is the same. It does not have to be "intracommunautaire".
On the converse, it is interesting to have a "TVA collectée intracommunautaire" as it will allow to declare your purchase in the EU without VAT.

What is really missing in OpenERP is the notion of "Purchase without VAT" in the EU.
Again, this makes OpenERP unusable ... I am sorry to be a little bit brutal.

But after all these years ... OpenERP being unable to handle taxes is a mistery.
Some people are doing lectures and tutorials and selling services ... and the resulting service is simply WRONG from a fiscal point of view.

@Kellogs
My merge proposal for l10n_fr has been accepted in trunk, but it is not present in the 6.1 branch. Are you doing your tests with an up-to-date trunk or with 6.1 ?

It is important to say which branch you are using exactly.

 Merged into lp:openobject-addons at revision 6798

 Merged into lp:openobject-addons/6.1 at revision 6911

Thanks,
Naresh Soni