[14.0][IMP][FIX] l10n_nl_account_tax_unece: Update account_tax_codes

[bosd]

Update the UNECE tax codes according to https://www.softwarepakketten.nl/wiki_uitleg/10&bronw=7/UBL_en_BTW_algemene_informatie.htm

As discovered in:
OCA/edi#323 (comment)
Current mapping is incorrect.

Todo:

• Update 6,9,21% tax rates to S code:

/ocabot add-lebal help-wanted

• Check other tax codes
• G = Free export item, tax not charged, code specifying that the item is free export
  and taxes are not charged.

Marked as done: Implemented in update of code

• K = VAT exempt for EEA intracommunity supply of goods and services. A tax category code indicating the item is VAT exempt
  due to an intracommunity supply in the European Economic Area.
  Wordt gebruikt bij de facturering van intracommunautaire goederen (ICP).

Marked as done: Implemented in update of code

• F = Value Added Tax (VAT) margin scheme second hand goods. Indication that the VAT margin scheme for second hand
  goods is applied. Wordt gebruikt bij facturering van tweede hands goederen volgens de margeregeling.

Marked as done because: categoriecode F (Margin Scheme) niet is toegestaan in de basisfactuur. Gebruik code E
Met excempt reasong

• Create migration script

cc: @gjotten , @thomaspaulb , @astirpe

[bosd]

Please also check if these are still correct:

Check, is this correct? I assume first one should be K

    <record id="l10n_nl.btw_I_overig" model="account.tax.template">
        <field name="unece_type_id" eval="ref('account_tax_unece.tax_type_vat')" />
        <field name="unece_categ_id" eval="ref('account_tax_unece.tax_categ_s')" />
    </record>

    <record id="l10n_nl.btw_I_overig_d" model="account.tax.template">
        <field name="unece_type_id" eval="ref('account_tax_unece.tax_type_vat')" />
        <field name="unece_categ_id" eval="ref('account_tax_unece.tax_categ_s')" />
    </record>

This is not according to peppol standard.
Should be AE (binnenland) or K (ICP)? What do you think?

    <record id="l10n_nl.btw_verk_0" model="account.tax.template">
        <field name="unece_type_id" eval="ref('account_tax_unece.tax_type_vat')" />
        <field name="unece_categ_id" eval="ref('account_tax_unece.tax_categ_b')" />
    </record>

[gjotten]

@bosd good catch!

Based on the 'UBL en BTW' information linked, I'd agree with the changes to code S you've made up until now. As for how I'm reading the rest:

• what's tax_categ_b in 'Buiten de EU / Verkoop' right now could be categ_g. However, we're not making a goederen/diensten distinction in our account.tax.template records yet. I suspect diensten would need to be separated under code Z maybe? See the 0% BTW page
• regarding l10n_nl.btw_I_overig[_d] I'm a bit confused, the linked pages tell us about sales but I'm missing info on purchases and their VAT regimes
• regarding l10n_nl.btw_verk_0: my intuition says AE since the 'verlegd' regime has mostly been applied to intra-NL transactions with special circumstances in my experience. But that's a bit thin since N=1 so ideally we have this checked somehow

The more I look at this the less sure I am what's supposed to be correct. A quick search on TaxCategory implementation at other vendors netted me nothing; might contacting peppolautoriteit.nl make sense? I'm suspecting they're just some hollow shell 'facilitating' private entities who 'support' this standard 😞

[bosd]

Found some usefull info on: https://www.forumstandaardisatie.nl/open-standaarden/nlcius
Which links to this pdf: https://www.forumstandaardisatie.nl/sites/default/files/Downloads/Bijlagen%20OS/NLCIUS/E-Factureren-Gebruiksinstructie-voor-de-basisfactuur-v1.0.2.pdf

TL;DR all.
But adjusted tags according to info from page 37.

Also found a gap in implementation.
Currently the odoo CoA / Tax Tags does not have a seperate tag for:
Z Nultarief (0%)
E BTW Vrij

This could mean we would be unable to parse some peppol / ubl invoices
(Checked odoo version 14 CE )

Not sure why tests are failling after last commit. Should be ok.

[gjotten]

@bosd self.assertTrue(tax.unece_categ_id.id in unece_categ_ids) will lead to a false if it won't find them in the references no?

[bosd]

@astirpe , @thomaspaulb Can you please review?

[bosd]

@NL66278 Can you please review?

[NL66278]

👍 LGTM

[NL66278]

@bosd Can you rebase this one?

[bosd]

Can we proceed with this pr and to other ones. To get some more traction in this repo

[thomaspaulb]

/ocabot merge patch

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 14.0-ocabot-merge-pr-404-by-thomaspaulb-bump-patch, awaiting test results.

[thomaspaulb]

Can we proceed with this pr and to other ones. To get some more traction in this repo

If you want to speed things up, the only way really is review swapping - you review other people's PR's, they review yours. It doesn't help to become impatient, unfortunately.

[OCA-git-bot]

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

[bosd]

If you want to speed things up, the only way really is review swapping - you review other people's PR's, they review yours. It doesn't help to become impatient, unfortunately.

Many thanks ❤️
Noted
I'm already reviewing a lot of pr's. But mainly those users are not active in this localization repo 😉
Understandable they won't swap.
I've patiently waited 3 months.. 😄

[thomaspaulb]

3 months is nothing :) everyone has the same problem