A lot of the separate files were kept up to now because it made the
process easier while applying the script to rebase.
The files can now be merged.
Some code is also cleaned by using CSV instead of a python dict.
Part-of: odoo/odoo#114164
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
- [IMP] l10n_it_edi: Tax exemption kind N7 description
New specs from October 1st 2022:
https://www.doxee.com/it/blog/fatturazione-elettronica/nuove-specifiche-tecniche-per-la-fattura-elettronica-2022-in-vigore-dal-1-ottobre/
The description of Tax Exemption kind N7 is changed to:
"IVA assolta in altro stato UE (prestazione di servizi
di telecomunicazioni, tele-radiodiffusione ed elettronici
ex art. 7-octies, comma 1 lett. a, b, art. 74-sexies DPR 633/72)"
Courtesy of Tony Mascii
- [FIX] l10n_it_edi: San Marino self-invoice from paper
San Marino is a very small country completely enclosed in Italy.
That country has special agreements with Italian as far as
e-invoicing is concerned.
When a paper invoice is received from San Marino, any Italian
company has the responsability to submit that invoice integrated
with Italian tax information to the Tax Agency, indicating in the
e-invoice filling the Document Type field with the special value 'TD28'.
- [IMP] l10n_it: Round globally by default in Italian CoA
The Italian Tax Agency (and therefore any business in Italy)
makes it mandatory to compute roundings based on a Round Globally policy.
Invoices not rounded globally are refused by Italian EDI.
- [IMP] l10n_it, l10n_it_edi, l10n_it_stock_ddt: Deferred invoice
Context:
The Italian State allows making one invoice per month
to recurrent clients buying goods several times a month.
This process is called "Deferred invoice" (Fattura differita)
in contrast to Direct invoice (Fattura immediata).
To enable this, the vendor must issue one Transport Document
per client delivery. The Document is attached to the goods themselves.
Many Transport Documents (DDTs) delivered can then be invoiced together
in a single invoice up to the 15th day of the following month.
This task allows the Italian EDI to correctly communicate
the Deferred invoices data to the Tax Authority
An export test has been added.
Official FAQ (n.21) - https://www.agenziaentrate.gov.it/portale/documents/20143/287582/15+Tutte+le+faq+%28aggiornate+al+11+maggio+2021%29+.pdf/2db944b9-22c3-fa80-7c14-dfa0bcbbd65e
Reference task link: https://www.odoo.com/web#model=project.task&id=1914640closesodoo/odoo#108230
X-original-commit: 87dd99e8abd8281fd81164d1f007ceaff3123834
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@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
There is an issue with the Italian carryover, line vp14b.
Use case:
- Month 1, have a value of 25 in this line => will trigger a carryover to line vp7
- Month 2, add more value to vp14b so that it goes above 25.82.
This will set the bound as None, and thus this will not impact the carryover.
This is wrong, because then the next month we will see a value of 25 in vp7
while it should be 0.
closesodoo/odoo#84938
X-original-commit: ffbc7af321a36d4fd0aebb94d7a636cb1fc34b88
Related: odoo/enterprise#24555
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The Italian VAT report is needed to help Italian customers fill in
their VAT report.
Task id #2079462
X-original-commit: 570afc9f237ce6048bd412dd6f3cd7ad38ffb17a
[ADD] Added VAT report for Italy and simplify tax templates
The Italian VAT report is needed to help Italian customers fill in
their VAT report.
Task id #2079462closesodoo/odoo#77565
X-original-commit: 616839df835283b5d682323cf96bbae579d3900a
Related: odoo/enterprise#21330
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
william-andre