Problem
---------
Before 16.2, the fields were empty, which meant that the expense and
income accounts of the chosen category could be used.
Since 16.2, when a product is created, the expense and income accounts
are automatically pre-filled.
Objective
---------
This task aims at retrieving the old behavior to allow using category
accounts.
Solution
---------
Remove the `property_account_expense_id` &
`property_account_income_id keys` in `_get_xx_template_data` in all
localization packages that define them.
task-3438931
closesodoo/odoo#134796
X-original-commit: dae46c926d5e63683968107f06bf2bfb8e07d267
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
The default taxes for most localisations have been left undefined by
default. When loading the chart template, the model generally selects
the first sales and purchase taxes, based on the order in which the
taxes appear in the csv, for the default sales and purchase taxes
respectively.
This behaviour can be confusing to those who are not yet familiar with
it. It has been decided that it is preferable instead to specify the
default tax in _get_*_res_company function on the account chart template
model, such that the default taxes are defined explicitly for every
localisation.
task-3453997
closesodoo/odoo#130733
Related: odoo/enterprise#45531
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Complement module to allow generate the PLE reports.
- Missing purchase tax groups and taxes added to complete the vendor
bills flow
- Demo data completed to has data to allow generate the PLE reports
- Document types for vendor bills completed in the data
- Method to improve the domain in document types for customer invoices
added
- Extend method to autocomplete the number on vendor bills with the
standard expected by the document type.
closesodoo/odoo#124595
X-original-commit: 821d313a5de857a4903bb35aaea49c3a35f8781e
Related: odoo/enterprise#42345
Signed-off-by: Josse Colpaert <jco@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
Odoo ORM has special optimization for installing module with a stored related
fields, but it requires the final field be not computed [1] (I'm not sure why),
which is not the case for the `group_id` field. Since `account.move.line` table
may have millions of records, we have to optimize the installation and fill
`l10n_pe_group_id` via a single sql query.
[1]: https://github.com/odoo/odoo/blob/0aff8bb9484a23c0d875d3b12259dd4e0d51e716/odoo/fields.py#L818
opw-2762510
closesodoo/odoo#107157
X-original-commit: 63341b5856b4a5cbc6fda17a4cc1d40f84cf7476
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Add the Coa and tax data for the peruvian
localisation (in english with translations)
closesodoo/odoo#104073
Task: task-2774275
Related: odoo/enterprise#33183
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Before, if you would put Peru Street 23, it would put Peru in House number.
This is because the editable field was the street field, so behind the scenes,
Odoo will split it and according to the standard format without country,
this means Peru will go into House.
We tried first with a change inversing it, but as we are doing the change,
the best thing is to remove the split all together. We added also onchange
logic that if you put a district it would automatically put the right city.
City or city_id should depend on the country and is correctly inherited by a
fields_view_get.
Task 2724531
closesodoo/odoo#85194
X-original-commit: 47cd0b51fb60cebb88e3a84b7e332e1ff800b0a8
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently all latam localizations except Chile use country_id in _localization_use_documents().
account_fiscal_country_id should be used instead in all modules.
closesodoo/odoo#84756
Task: 2761248
X-original-commit: cf61089d9480d7450d2916911b0859cd5f6efcce
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Tastemirova Aliya (alta) <alta@odoo.com>
Part of task 2124952
This is needed in order to be able to create the demo data.
It was not done earlier because of stable policy but it was added to
l10n_pe_edi instead.
closesodoo/odoo#60148
Related: odoo/enterprise#15213
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
base_vat: Correct management of the check of peruvian VAT without prefix.
l10n_pe: Correct income account the last one is not correct.
l10n_pe: Forced Round globally for peruvian companies once l10n_pe is
installed, and with the onchange.
l10n_pe: For peruvian companies it does not make sense a sequence per
year and the year in the prefix is incorrect, we must force XXX- as
a sequence prefix.
closes odoo/odoo#38854
Forward-port-of: #38764
Signed-off-by: Josse Colpaert <jco@openerp.com>
And making ready for the future EDI modules.
- Added related account group on the move lines to
show account moves in a way Peru is used to.
As this allows to group by the account group
and to divide the hierarchical structure.
- Completely new CoA structure and tax structure
- Minimal fields for the EDI module later
- Districts and cities as we also need codes for
the EDI.
Antoine Boonen