This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
This commit aims to allow assigning tags to the taxes
created by the OSS feature by providing the xml_id of their
report.line in the eu_tag_map.py file.
Before this commit:
In l10n_be, the taxes created by OSS (l10n_eu_services) didn't set
the tag +47 on invoice_repartition_lines nor +49 on
refund_repartition_lines.
This make the VAT report for Belgium wrong.
After this commit:
Taxes created by OSS for a company using the belgian CoA will get
their tags set properly and thus will the taxes impact the
belgian tax report correctly.
task: 2770182
ticket: 2768622
Community-PR: https://github.com/odoo/odoo/pull/85607
Design choices:
This fix is currently solving the issue for l10n_be but we have
no doubt that it will be raised for other EU countries too.
In order to provide the tags, we decided to be consistent with
what as been done regarding the tax mapping. Thus we decided to
create and maintain a simple mapping file and to test it.
several other methods were explored:
- create a global variable and update it from all localization
modules. This method would work but is ugly and error prone.
- create a templating method and override it from localization
modules.
The problem is where to set the root of the template method?
The naïve solution would be to create a bridge module between
l10n_eu_services and l10n_be but that would lead to an explosion
in the number of bridge modules which we don't want.
In order to keep things simple and generic, we could put the
template method directly into the account module. But it is kind
of ugly because account shouldn't know anything about the oss
feature and it would encourage such a leaky design to happen
again in the future.
closesodoo/odoo#86314
X-original-commit: 7dcc2ae4665d2d7b577ed10160691775b86a848f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
Multivat means you are submitting its national tax report to a foreign country. In this case, you never want to use OSS taxes for that country. Hence, we exclude the countries for which we are submitting such a report when generating the fiscal positions for OSS.
closesodoo/odoo#77080
X-original-commit: ab2d2916e469586bb6c2b63c49de766369aa7277
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this fix, a cash basis OSS tax used together with a product using the "non-EU origin" tag didn't appear properly in the OSS import report. This was due to the fact the product tag was not copied on the cash basis move: it only appeared on the invoice, on non exigible lines.
To fix that, we make the choice to keep the product tag as markup on the invoice, and to copy it to the cash basis lines created from move lines containing this tag. We therefore need a non-ambiguous way to identify account.account.tag objects that are used on products, since we don't want to copy tags used by taxes. Hence, we introduct a new value for the 'applicability' field of account.account.tag, limitating their use to products.
closesodoo/odoo#76626
X-original-commit: 0dd712b876844c3e342447e4cf26b324fcaffc37
Related: odoo/enterprise#20916
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
This module is now used to support OSS taxes, which replaced MOSS a few months ago. This renaming follows the changes introduced in stable by https://github.com/odoo/odoo/commit/0e7c289003a0a69075188dbfaea724919dac32a4 .
[IMP] l10n_eu_oss: remove dead code from former l10n_eu_service feature
[IMP] account, product, l10n_eu_oss: community adjustements to support enterprise's OSS report
The following changes where introduced in order to support the features implemented in the new l10n_eu_oss_reports module:
- account.tag objects applicable on taxes are no longer required to have a country_id. This way, we allow using tags in generic reports (i.e. the ones available for multiple countries) as well.
- add account_tag_is on product.template and product.category: this fields are m2m to account.account.tag applicable on taxes. When making an entry from this product, these tags will be set on all the tax move lines created for it. We use it in OSS to differentiate between imported and non-imported goods in the report.
- always display country_id on fiscal positions' form view: OSS taxes require to be used in some fiscal position with a country_id set, so that we can infer the country they are mapping the vat from. We make that change in the view so that users are not obliged to create auto-applied fiscal positions to fix the OSS taxes they created manually, and can directly set the country on the fiscal position.
Task 2591541
closesodoo/odoo#73602
Related: odoo/upgrade#2669
Related: odoo/enterprise#19628
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
oco-odoo