[14.0] add support for VAT return with teletransmission

[alexis-via]

l10n_fr_account_vat_return: adds support for French VAT return
l10n_fr_account_vat_return_teledec: allows to teletransmit the French VAT return via teledec.fr

Express demo of the module : https://www.youtube.com/watch?v=40sJ9kHXoEk
Blog post with lots of information about these new modules: https://akretion.com/fr/blog/nouveau-module-odoo-declaration-de-tva-avec-teletransmission

[legalsylvain]

Hi alexis. Thanks for sharing this module.

I'm not using teledec, so not interested by the whole PR. However, your PR introduce a type on fiscal position that is interesting and is missing in odoo.

I propose that I refactor this part to have something more generic and also to take advantage of fiscal position template to avoid useless configuration.

(https://github.com/odoo/odoo/blob/15.0/addons/account/models/chart_template.py#L1277)

Please wait before merging this PR.

Regards.

[alexis-via]

I don't plan to merge this PR in the short term. I want to add tests first (the work has already started, but it's far from finished).

I'm ok to add a field "fr_vat_type" on account.fiscal.position.template and add the data for the 4 fiscal position templates provided by l10n_fr. What do you mean exactly by "to have something more generic" ?

[legalsylvain]

I'm ok to add a field "fr_vat_type" on account.fiscal.position.template and add the data for the 4 fiscal position templates provided by l10n_fr. What do you mean exactly by "to have something more generic" ?

I think that having a type on fiscal position could be a great feature. For that purpose, I imagine the following design :

• a module named account_fiscal_position_type (OCA/account-fiscal-rule) that adds a new selection field position_type on account.fiscal.position and account.fiscal.position.template (and the according views)
• a module named l10n_france_fiscal_position_type (OCA/l10n-france) that adds french types to the selection, and update l10n_fr datas on fiscal position templates.

then,

• you can remove some part of your code.
• some other localization can implement other "types".
• the field can be reused in other custom modules.

what do you think ?

Note : as there is a module name account_fiscal_position_type in V12, the existing module should be renamed in V14 in to account_fiscal_position_usage but not a big deal in my opinion.

[alexis-via]

Well, that's a good idea in theory, but I'm not sure about the result in real life. It's good to have a common field, but then we would have to agree on the content of the selection list if we really want to have several modules that use the same field. For example, the module "intrastat_base" adds an "intrastat" boolean on account.fiscal.position, cf https://github.com/OCA/intrastat-extrastat/blob/14.0/intrastat_base/models/account_fiscal_position.py#L11
First idea: great, intrastat_base could use that new field too!
But, in real life, we would need to agree on the content of this new field, because, in my module I want a distinction between "intrastat_b2b" and "intrastat_b2c". But imagine that another module in another localization would also be interested by the field, but he needs to split "intrastat" in 3 subdivisions "intrastat_gov", "intrastat_sme" and "intrastat_large_companies" ! In the end, it may be a coordination nightmare, which generate more frustration than solutions (reminds me of the "agreement_*" modules in OCA/contract: too many people wanted too many different things... it was a coordination nightmare and I eventually stopped using those modules in the Chorus Pro connector).

Concretely, how do YOU plan to use that new field? Do you already have an idea in mind?

[legalsylvain]

Hi @alexis-via. Thanks a lot for your answer. this puts the finger on a discomfort I had with my proposal, but which I could not identify.

Concretely, how do YOU plan to use that new field? Do you already have an idea in mind?

Well, in a few word.
I have an instance with 70 companies, so having setting on fiscal.position.template saves me time, and reduce errors.
Regarding fiscal position, I use the default ones created by l10n_fr here and add an extra fiscal position to make internal trade between companies that belong to the same main company. (That's a specific point for the CAE french concept that requires to remove VAT AND to map accounts.
For that purpose, I requires a field to check if the setting is correct. So something like if fp.type =='position_internal_trade' interest me. (but also add other checks)

we would need to agree on the content of this new field ... too many people wanted too many different things

You're right. This situation should be avoided.

V2 Proposal !

What about a module named account_fiscal_position_tag (OCA/account-fiscal-rule) that adds a new M2M field tag_ids on account.fiscal.position and account.fiscal.position.template (and the according views)

the model could be something like :

_name = 'account.fiscal.position.tag'  # and 'account.fiscal.position.tag'

    name = fields.Char()
    code = fields.Char()
    active = fields.Boolean()

• Then each business module can inherit of this module and just create new tags by xml. (no need to add it python, in the view, and handling fiscal position template)

• Then, you can make a test like if "intracom_b2c" in fp.mapped("tag_ids.code") or whatever.

• and each module can also define default tags on template, so when you create a new company or install a chart of account all the fiscal position are correctly set. (or as best as possible.)

Ex 1 : for your module

    <record ...>
        <field name="name">France</field>
        <field name="code">france</field>
    </record>
    <record ...>
        <field name="name">Intra-EU B2C over 10k€ limit</field>
        <field name="code">intracom_b2c</field>
    </record>

Ex 2 : for intrastat_base

    <record ...>
        <field name="name">Intrastat</field>
        <field name="code">intrastat</field>
    </record>

Better ?

[legalsylvain]

@alexis-via : here is a PoC. OCA/account-fiscal-rule#245

you could remove :

• full file l10n_fr_account_vat_return/models/account_fiscal_position.py
• full file l10n_fr_account_vat_return/models/account_fiscal_position.xml
• fiscal_position_fr_vat_type in l10n_fr_account_vat_return/models/account_move.py + account_move.xml

replace by a data file of tags, and optionally another to configure templates (so that configuration will be correct when installing l10n_fr chart of account on a new company)

[rvalyi]

One remark and proposal for VAT on payment with advance payments. Currently, when doing a native "sale down payment invoice" we don't have VAT taxes on the "advance payment product". it means that later on, when doing the VAT return computation we will miss the advance payment VAT in this part of the code:
https://github.com/akretion/l10n-france/blob/14-add-vat_return/l10n_fr_account_vat_return/models/l10n_fr_account_vat_return.py#L1351

@alexis-via what's you idea to deal with such cases? My idea would be to attach the different VAT taxes on the advance payment invoice line with amounts proportional to the global amount paid in advance proportion. Then we would find the proper VAt account move lines in the advance payment invoices for the VAT return declaration. What do you think? cc @clementmbr

[rvalyi]

reply to self, here is a workaround to collect the proper taxes in Down Payments at least in France https://github.com/akretion/odoo-usability/pull/175/files

[alexis-via]

Travis error says "AttributeError: module 'PyPDF2' has no attribute 'filters'".
I'm very surprised, because I have PyPDF2 version 1.26.0 on my laptop and it works well. And PyPDF 1.26.0 is the version listed in the requirements.txt of Odoo, cf https://github.com/odoo/odoo/blob/14.0/requirements.txt#L38
I don't see any reason why Travis would have a different PyPDF2 version...

[ivantodorovich]

I recommend we take the opportunity to switch to GitHub actions ci on this repo, as it's what's been done in most oca repositories. Might just solve this issue too

[alexis-via]

Yes, feel free to propose a PR to switch to Github actions or what-ever-is-the-new-standard.

[ivantodorovich]

Yes, feel free to propose a PR to switch to Github actions or what-ever-is-the-new-standard.

@alexis-via :

• [14.0] [UPD] Update dotfiles from template and switch to Github Actions #366

[ivantodorovich]

@alexis-via
Now that #366 is merged, you can try rebasing and see if CI is green

[alexis-via]

My TODO list on the VAT return module is now empty :)

[alexis-via]

/ocabot merge nobump

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 14.0-ocabot-merge-pr-321-by-alexis-via-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 6746eb5. Thanks a lot for contributing to OCA. ❤️