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>
Set a default tag on the bank suspense account, outstanding accounts
and transfer accounts so that they are found and used by the trial
balance and COA reports.
TAsk id #2612900closesodoo/odoo#82532
Related: odoo/enterprise#23383
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
When we get the existing tags to append them a new id, we don't get a
list of id but a list of tuple with one id, this only append if you have
more than one accounting of these country installed, as the first time
it will return an empty list. So the command sent to the ORM, is not
built correctly.
To fix this we just append commands '4' that will be append in a list.
When have more than one company, for all companies, the cash
basis journal set in accounting configuration will be
always the related to first company.
This issue cause the followiong error trying to validate an
invoice for a company different to fisrt one:
'Cannot create moves for different companies.'
Because exist a 'cross-configuration' in the cash basis
journal.
The solution to this issue is include the company in domain
that does the search for cash basis journal.
* Added accounts provided following the structure provided by the SAT
this accounts are only the minimal necessary ones, with the objective
to set the first easiest engagement to new users and tags will represent the actual information
from the document linked.
* The name of the tag is the concatenation of tag.code + tag.name, because the account.tag
model have not the code field.
Note: we will need more accounts but some of them for special operations
which are not basic at all, then it is better just propose the operational accounts
once we understand a proper closing process.
* Set the proper user-types on accounts in order to be able to use it with the official reports this CoA
for operational purpose.
* Added nature field and data in tags to allow set this value in electronic account report, and
set this value with data pre loaded, we did not use user.type for this due to the fact that the same user type can have different nature (if it grows for credit or debit), I do not know if this field brakes the stable rule we can discuse about that.
* Assign the account tags with in the Mexican CoA template installation, and with an onchange(account.code) when manually modifying/creating accounts.
Rationale: If the code of the accounts follows the pattern 111.00.00 or 111-00-00 then it will
set the tag 111.00 if the tag exists, if not then this will be ignored.
* Generate an account tag by each second level account in SAT catalog, and assign to the corresponding account.
oco-odoo