The Belgian localization has been updated to reflect the official Charts
of Accounts.
Users now have the choice between the official CoA for Companies or the
one for Associations and Foundations.
All related terms and translations have been reviewed and corrected in
the 3 official languages (nl, fr, de).
Non-official languages have been removed, since they both don't make
sense and they did not work because of targeting an ancient version of
Odoo.
Finally, the 580000 account has been set as the default Internal
Transfers account, avoiding a second 58 account to be created.
task-3086473
task-3258014
closesodoo/odoo#117480
Related: odoo/enterprise#35771
Related: odoo/upgrade#5291
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
This commit replaces the outdated expressions and unsigned tags in mod 111, 115, and 303 with tax_tags expressions. This update follows the removal of the old technical decision after Reportalypse. A migration script is included to ensure proper conversion of accounting history. As a result, Spanish reports are more standardized and performance is significantly enhanced due to batching in the tax_tags engine.
closesodoo/odoo#120675
Task-id: 3126178
Related: odoo/enterprise#40777
Related: odoo/upgrade#4800
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
`default_get` is bad m'kay?
Reproduce:
* Accounting > Configuration > Taxes > Create
* Just add a name, save.
There are no repartition lines, but there should be at least one line
for the base line.
This happens because `default_get` was only computing the main field
`repartition_line_ids` and it was allowed because the contraint was not
checking that same field.
closesodoo/odoo#129840
X-original-commit: f05457c82af63358c292350ef110f0b18c27f164
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Bugfix. When installing l10n_eu_oss with l10n_de_skr03, an OSS account
'17010 Unsatzsteuer 19% OSS' is created. However, this account has
no account tags set on it, so it gets left out from the Balance Sheet
report. (Note that in Germany, due to there being two CoAs, the Balance
Sheet report still works using account tags.)
The solution: when creating the OSS account, re-use the account tags
of the account we are copying.
closesodoo/odoo#130287
X-original-commit: f541ef903085ed95b0aa0bc6d3e82bf9efa2a23d
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Following the new accounting act of 2023 in Danemark, by checking the list of
taxes we saw that one particular tax was missing and for the other either they
can be associated to existing ones or have minor uses and so no need to add them
Also, we added a mapping for OSS to map in the section "Category B (Not to be
reported for EU sales without VAT)"
I have also changed some name where the translation were a bit shaky.
closesodoo/odoo#125720
Task: 3334595
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The aimf of this commit is to make the query of a specific tag with a
specific sign easier by avoiding all the filtering in
`expression._get_tax_tags().filtered(lambda t: t.tax_negate)`
With this commit, we just leverage the existing filtering on domain to
only get the desired tag.
no-task
closesodoo/odoo#117167
X-original-commit: 6eb53a3802d24e283b8334b6f245ffe87dddcbe8
Related: odoo/enterprise#39044
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Taxes in Luxembourg have been reduced until the end of 2023: 17% -> 16%, 14% -> 13% and 8% to 7%.
This change remaps the OSS tax mappings for Luxembourg to the new tax rates.
task-3159138
closesodoo/odoo#111286
X-original-commit: e7edd71a3a4d8d7297c07f44b6b701052f2c5b7d
Related: odoo/enterprise#36477
Signed-off-by: Josse Colpaert <jco@odoo.com>
A. UX Improvement:
1. get rid of the `.0%` in the tax names (makes the UI a bit harder to read)
2. For TTC taxes, remove the TTC in the description to prevent it from appearing on the invoice's pdf
B. Tax issue:
Fix some mistakes in the taxes, based on reliable feedback of french partner Didier Six.
1. Fuel purchase taxes: shouldn't imact the P1_base and P1_tax grids because these are for petroleum product to sale.
Instead, put them in grid 20 (normal goods bought)
2. All tax "IMPORT":
- base line shouldn't impact the [{08/09/9B}_{base/tax}] tax grid as these are for sales operation in France and the [I{number}_{base/ tax}] are already there
Currently, the tax is putting up [{08/09/9B} _tax] and [Ix_tax] which induce a double calculation of the due VAT
- tax line should also impact the [24] `24 - Dont TVA déductible sur importations` in addition of the [20]
This tax grid isn't taken into account for the total deductible VAT calculation as it is after the total and label "dont TVA déductible[...]"
4. OSS: add the tax grid E3 on invoice base line and F8 on refund base line
task-3087037
closesodoo/odoo#107351
X-original-commit: 0cea284eec5d3d2bb9aa8d94c0edcb211ba08a50
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The aim of this commit is to:
- allow OSS to use tax that aren't declare by TaxReportLine
- have the oss tax automatically populated with the correct tags for spanish
tax report
- Add taxes specific to the spanish OSS : No sujeto y acogidas a la OSS (Servicios) and No sujeto y acogidas a la OSS (Bienes)
using the official modulo 124 tag
closesodoo/odoo#101121
Community-pr: https://github.com/odoo/odoo/pull/99273
Task: 2930758
X-original-commit: 2a21e4c084ba952eba1b4a7bb6f6ee31875d70ea
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Co-authored-by: Camille Casp Spiritus <casp@odoo.com>
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>
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>
Dylan Kiss (dyki)