Set the default sale and purchase taxes for the mexican CoA.

Before introducing the IEPS taxes in commit
734e18eb, the default taxes were the 16%
IVA taxes (when loading the CoA, the default is simply the first
possible match with the lowest sequence). As the IEPS taxes now have the
lowest sequence, they are incorrectly selected as the defaults. This
commit fixes this.

task-3507155

closes odoo/odoo#135810

Signed-off-by: Laurent Smet (las) <las@odoo.com>

Miscellaneous changes aiming to improve the user experience in the accounting module,
mainly in the journal model and its form view.

Also aim to improve the bank account creation wizard.

Task ID: #2250349

closes odoo/odoo#54494

Related: odoo/upgrade#1546
Related: odoo/enterprise#11862
Signed-off-by: oco-odoo <oco-odoo@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'`

Before that, the specific account tags created in l10n modules were not only assigned when the company was in the right country.

closes odoo/odoo#29030

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.

_prepare_transfer_account had been renamed _get_default_bank_journals_data instead of _prepare_transfer_account_for_direct_creation, by mistake. The original renaming was made at https://github.com/odoo/odoo/commit/87f0d2eefb77bfc6a9a0fa7f7dcd1475c7c34639#diff-ce53c5491cb2c9ab3dbbd41ecabf594f

[REF] account, account_check_printing, payment, l10n_do, l10n_de, l10n_fr, l10n_nl, l10n_mx: chart templates installation: remove old useless wizards and move everything to account.chart.template

Was task 1858974
Was PR https://github.com/odoo/odoo/pull/25243

This commit changes the mechanism to get the transfer account.
As the bank/cash accounts, the transfer account is now created automatically based on
a prefix.

-task: https://www.odoo.com/web#id=35857&action=333&active_id=967&model=project.task&view_type=form&menu_id=4720

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.

Courtesy of Vauxoo. Was PR #17055

Was PR #15893

    Hardcoded reference skips the mapping (company, template) -> account.account leading to key error.

 Some cash basis taxes were assigning the account 208.01.01 but this account was not created. Also add tax group

* 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.