Set `include_base_amount` to True for the IEPS taxes.
task-3100679
closesodoo/odoo#137940
X-original-commit: ceacccdc34f80ed5969b1d49bbcdf9adbd2ce76c
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
To avoid having to many IEPS taxes, set the sales one as inactive.
task-3100679
X-original-commit: d134258f18c8569f1684e7681cfc905d974444f5
Part-of: odoo/odoo#137940
Add a selection field `l10n_mx_tax_type` on account.tax. This field is
used in the CFDI attachment. This allows to avoid relying on the name of
the repartition line tags to export and import a CFDI.
task-3388347
closesodoo/odoo#135215
Related: odoo/enterprise#47321
Related: odoo/upgrade#5136
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Add IEPS taxes and tax groups. Make sure the IEPS taxes are
`include_base_amount` and have a lower sequence than the IVA taxes.
Unify the names of the taxes and their labels on invoice.
Resequence the taxes to group them by nature.
task-3100679
closesodoo/odoo#135795
X-original-commit: d4785e5895c9befaeb1ff7d77b02f5ed7b250790
Related: odoo/enterprise#47545
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Problem
---------
Some Unit of Measures need to be configured when using the Mexican
Localisation to be used in their electronic invoicing system. As of now
they are not installed by default but many businesses will need to add
and configure them manually. Let's make those included in the l10n_mx
localisation.
Objective
---------
Addition of the Service UoM category and the 3 UoMs in the UoM data file:
- Service Unit
- Activity
- Job
Solution
---------
UOM category and units were added in an XML file in the data folder.
Translation added to the uom.pot file to be translated later;
translation already added in es_MX since the task is targeted at Mexican
localisation.
task-3392056
closesodoo/odoo#129672
X-original-commit: 0f88914a4618aa1abd250b6cf701a5f7b381f41e
Related: odoo/enterprise#44590
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
In the translation PR (odoo#108725), we translated the tax group and invoice label
but for the invoice label we didn't added to translation it needed to have.
This commit fix that.
Task: 3369579
Part-of: odoo/odoo#125017
Two issues solved in 1 commit; as their solutions depend on one another.
** ISSUE 1 **
To reproduce the issue, on a l10n with a tax report:
- Create a misc operation with a tax on it in the same form as a sales invoice ; post it.
- Reverse that move, and post the reverse.
=> Open the tax report: the amounts of the original move (for both tax lines and base lines) are doubled.
That's not what we want ; instead, the reverse should have entirely canceled the original move.
This is due to the fact the is_refund field of account.move.line is badly computed on the reverse: both tax and base lines are considered refund. Because of that, tax_tag_invert gets inverted, and ends up doubling the amount in the report instead of cancelling it. While made on a reverse move, those lines should not be considered as refunds, since they must both use the original repartition of the reversed move , unlike invoices, which would make use of the refund repartition in this case.
** ISSUE 2 **
To reproduce, on a l10n with a tax report:
- Create a cash basis tax, and set tags on its repartition lines so that it should be taken into account by the report. Make sure the refund repartition cancels the invoice repartition.
- Create an invoice using that tax, post it
- Click the "Add Credit Note" button, select "partial refund", and post the generated refund (which will cover the full amount of the original invoice)
- Reconcile the refund with the invoice
=> Because it's a partial refund, cash basis entries will still be generated. Open the tax report to ensure they sum up to 0... And the tax lines don't !
This happens because the computation of tax_tag_invert field inverts the sign of tag on cash basis entry tax lines when they have a negative tax_base_amount. In our case, when going through the "reverse" button and making a partial refund, we actually do get a negative amount in the credit note's tax_base_amount. This is inconsistent with what a refund generated from scratch does (then, you'll get a positive tax_base_amount in our case), and should only be legit when the document contains a negative line explicitly (so, a line with a negative quantity, hence inverting the meaning of debit/credit).
The root of the issue is that the tax_base_amount of the tax line uses the tax_tag_invert of the base line to define its sign. And tax_tag_invert was omitting to set copy=False. When reversing a move, the first step is to copy it. Because of the missing copy=False, tax_tag_invert was copied, and never recomputed (since it's a computed editable field) on the base line, giving it an inconsistent value, and ending up inverting the sign of tax_base_amount on the tax line. In turn, the tax line got a wrong tax_tag_invert because of that, and would propagate that to the cash basis entry when generating it.
This commit adds the missing copy=False to tax_tag_invert, but also fixes the computation of tax_tag_invert so that in does not rely on tax_base_amount anymore. This way, existing data will also benefit from the fix without having to recompute the field. Additionnally, there are currently plans to remove tax_base_amount in master, so this would have had to be done eventually anyway.
======
Forward-port note:
In 16.2, https://github.com/odoo/odoo/commit/84d7aab94e2984a81923f0546e24caf54cd53033 actually wrongly inverted the sign of the Mexican withholding tag in repartition lines. Those taxes are negative, so a tag needing to get the retention amount in positive must be negative itself. The bugs fixed in this commit shadowed the problem, and this fix reveals it. A fix of the tags's signs was added into this forward-port.
OPW 3255511
closesodoo/odoo#123187
X-original-commit: 688ab4d6688ccd2377ea9702c00b1ec16f99527a
Related: odoo/enterprise#41748
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
We want to invigorate a Tax Name Taxonomy so that tax names are as codified as possible. This allow for a better display on Invoice Description, and allowed us to implement a smart name_search.
In this PR, we change the taxes names so that it's more clear for users
closesodoo/odoo#114571
Task-id: 3052677
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
# Steps to reproduce
- install l10n_mx_reports
- switch to a mexican company
- create a Vendor Bill, confirm it and register a payment for it
- create a Credit Note for that bill, confirm it and register a payment
too
- go to the DIOT report (called `Transactions with third parties
[ DIOT ]` in the menu )
The amount in the column "Refunds" should be the tax amount, and not the
base amount.
opw-3107102
Enterprise PR: odoo/enterprise#39628closesodoo/odoo#118887
X-original-commit: 8c9cde34ac1fb74a42997b0a1d847ae1c9bb1312
Related: odoo/enterprise#39929
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Taxes have a `description` field that has been hijacked to
represent tax label on invoices. We want the description field
to be used for its original purpose, thus created a dedicated field
`invoice_label` in which we transferred `description` content.
We also make description translatable.
This is part of the Tax Taxonomy 2 rework.
Task: 3052677
Part-of: odoo/odoo#113236
1/ The mexican DIOT report is now a tax report.
This in order to enjoy more Reportalypse' features (less menuitems,
tax_tags engine). The export functinality will remain in enterprise
version.
2/ Add missing tax "RET IVA RESICO 1.25%" tax.
3/ Add migration script for taxes.
As a new tax (RET 1.25%) has been added and the DIOT refactoring updated
many invoice_repartition_line_ids and refund_repartition_line_ids with
tags, the migration script will be run on module update.
task-id: 2925736
[community](https://github.com/odoo/odoo/pull/109300)
[enterprise](https://github.com/odoo/enterprise/pull/35515)
closesodoo/odoo#109300
Related: odoo/upgrade#4224
Related: odoo/enterprise#35515
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Install MX CoA
"Cash" and "Bank Suspense Account" are missing the tag
"Transferencias bancarias moneda extranjera" account is using the wrong
tag
opw-3033611
closesodoo/odoo#111273
X-original-commit: 4860a77a51f72bbb51b435766733b3c0a74c9a32
Related: odoo/enterprise#36422
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Since the account.tags names have been converted from Spanish to English
(see
https://github.com/odoo/odoo/commit/84be7372de41ba8bf9075f34cbd0b812eadbc2b3),
the function `get_tax_cfdi_name` is no longer able to deduce the tax
code (the 'Impuesto' field with possible values: 001, 002 or 003)
Revert the 3 important account.tags names in Spanish.
closesodoo/odoo#110322
X-original-commit: 1705f785091e8b80ea57da439befce4a041744e4
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
All the localisation should be written in english and then translated to the native language of the country. In this case, the mexican localisation was written is spanish, this PR translate all the module in english and add the corresponding PO file in spanish.
closesodoo/odoo#108725
Task-id: 3089239
Related: odoo/enterprise#35247
Signed-off-by: Laurent Smet <las@odoo.com>
The early payment cash discount functionality was merged in 16.0.
This PR allows for the behavior to be as localization specific as possible.
This concerns :
The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour)
The account in which the cash difference resulting of the cash discount should be put.
task- 2983913
related to #99572closesodoo/odoo#102032
X-original-commit: 591757902dcdf1e3609d9c5ae23e2b134ee8e4da
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <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>
The account used in the Repartition for Credit Notes is wrong for taxes
`IVA(8%) COMPRAS`, `IVA(16%) COMPRAS`, `IVA(8%) VENTAS`, `RETENCION IVA
ARRENDAMIENTO 10.67%`, `RETENCION IVA HONORARIOS 10.67%` and `IVA(0%)
COMPRAS`
Steps to reproduce:
1. Install Accounting app and l10n_mx module
2. Go to Accounting > Configuration > Invoicing > Taxes
3. Open any one of the taxes mentioned above
4. The account in Repartition for Invoices should be the same as the
account in Repartition for Credit Notes
Solution:
Change the default account used in Repartion for Credit Notes
opw-2806228
closesodoo/odoo#88359
X-original-commit: e8dbd07f160dee59117b855ff54d6fb428bf9778
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
"account_tax_group.xml" and "account_data.xml" data files
have been renamed to "account_tax_group_data.xml"
when containing only tax groups, for compliance with the standard.
AE, AR, AT, BE, BO, BR, CA, CN, CR, CZ,
DE SKR03, DE SKR04, DO, ES, FI, FR, GR,
GT, HN, IL, IN, LT, MA, MX, NL, NO, PA,
PL, PT, RO, SG, SY, TH, TR, UA, UY, VE,
VN.
Part-of: odoo/odoo#77295
In order to not show unnecessary tax groups when configuring a tax,
we'll now filter them to only shows the tax groups that are either
linked to no country, or that are linked to the same country as the tax.
Task id #2206280
Since record creation is faster when done from a CSV file,
hence, we move account tags definitions into CSV file.
Also, there was a tag with XMLid 'account_tag_174' defined
twice in XML file, which has been removed.
Total 1082 records of account.account.tag will be created
after removing one duplicated tag.
closesodoo/odoo#56153
Task: 2150637
X-original-commit: 5eef487f194b10ec2a1c0eb452eb22eac6098fc7
Signed-off-by: Josse Colpaert <jco@openerp.com>
This commits refactors the code of the reconciliation, in order to facilitate the process of complex use cases, namely multi-currencies or cash-basis-taxes related (see details below). It also prepares the code for a second refactoring where we will save on each journal items the amount_currency and currency_id field (even in case of operation made in company currency), also in the sake of simplification.
1) Multi-currencies:
- the account.partial.reconcile model now will have dedicated columns to specify the amount of the partial reconciliation in the debit_line_id currency and the credit_line_id currency. That comes in handy when dealing with journal items having different secondary currencies, but also allows some simplification.
- residual_amount_currency computation changed accordingly
- moved models account.full.reconcile and account.partial.reconcile in their dedicated .py file
2) Cash basis taxes
- cash basis entries now handle correctly rounding errors to make sure the exact amount of gets reported when the reconciliation becomes full.
- the account for the base amount of cash basis entries has to be set, now, on the company instead of on each cash basis tax.
- that new 'property' field can be set at the CoA installation via the field property_cash_basis_base_account_id of account.chart.template, or going through the accounting settings.
Was task task: 2243420
Was PR #50308
Related: odoo/upgrade#1121
Related: odoo/enterprise#10252
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In a general manner,
the chart templates should not be set to noupdate,
that way, if a new company starts in an existing database,
it starts with an up-to-date chart of accounts.
For instance,
if the chart of template is not updated from
12.0 to 13.0, the `default_pos_receivable_account_id`
is not added in the chart template,
and when a new company is created,
the default pos receivable account is not set on the company.
Besides, the field `res.company``account_default_pos_receivable_account_id`
is not displayed on any form view,
whether or not the full accounting is installed,
so we must especially pay attention this default account is well set
from start, as the user as no opportunity to correct this by himself.
In addition,
in upgrade scripts,
the default pos receivable account on the chart template
is used to correctly set the pos receivable account on the company
and on the pos payment methods,
so it must be well set for the upgrade script to do its job correctly.
Technically, it means, without this revision, the fields:
- `account.chart.template``default_pos_receivable_account_id`,
- `res.company``account_default_pos_receivable_account_id`,
- `pos.payment.method``receivable_account_id`
were not filled properly on upgrade,
causing critical issues in the accounting entries on pos session closing.
Related to #52786
Related to odoo/upgrade@ccfd2371efclosesodoo/odoo#52870
X-original-commit: 3258ba015ff75b7c176d83a44261d24ebfcc26de
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Fix account type on 108.01.01 & 108.02.01
According to the SAT catalog must be an account of Current Assets
Fix the account type and the tag on 811.01.01
According to the SAT catalog must be an account of Expenses, and the tag
must be 811.01
The correct account for unaffected earnings in the SAT catalog is 305.01,
then, was added the account and assigned the correct type.
closesodoo/odoo#46046
X-original-commit: 632cc5417796ff375d47767fd7cdb358a5d4ce94
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This issue is relevant for MX Localization because Cash Basis is created
with the rate of the payment, and not with the rate of the invoice as is
done for odoo core.
closesodoo/odoo#38399
X-original-commit: 10bb81c837c0d88ac4ec396442bd86a654c78646
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this commit when installing l10n_mx chart of accounts taxes for
0% and 4% were the ones assigned by default in products or in invoices
for sales and purchase, respectively.
Reason was wrong sequence in the Template of Taxes, combined with order
of creation, ids.
now the two ones with lowest sequence are the 16% Taxes.
closesodoo/odoo#37642
X-original-commit: 357943e9440683f2bff01dc2f1ef074e5104769a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The domain for the tags in the taxes indicates that the country must be
the same that the tax country:
domain="[('applicability', '=', 'taxes'), ('country_id', '=', country_id)]"
For this reason is necessary assign the country in the tags, to allow
register new taxes or change the tag in the records created.
closesodoo/odoo#37482
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The tags in the tax are created for the Mexican taxes (IVA, ISR & IEPS)
This was assigned in the taxes on 3efefd2171,
but in the commit 333c22edd9
was removed from the tax 0%.
Now was returned that data, to be consistent with the tax for 16%
closesodoo/odoo#36206
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When is used the option to get the CoA reports based on groups, is
necessary set the tag in each group, then, is necessary load the tags
for second level in the SAT catalog for accounts.
This module provide you a data from Mexican Bank data extracted
from `SAT Bank catalog
<http://www.sat.gob.mx/fichas_tematicas/buzon_tributario/Documents/catalogo_bancos.pdf>`_.
Additionally was added the following fields:
- ASM code in Banks: to identify banking institutions by ASM standard
- CLABE code in Bank Accounts: required to the sending and receiving
of domestic inter-bank electronic funds transfer.
closesodoo/odoo#35742
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before, we only had a public method that installed
the CoA for the current active company.
With the multi-company changes, it was not
possible anymore to install a module with a
demo company and then have the CoA installed
in that demo company correctly.
We changed that public method to be able to
put an extra optional parameter and shortened
its name to try_loading instead of
try_loading_for_current_company. The method that
it calls when there is no chart installed
is made private and renamed to _load.
closesodoo/odoo#35703
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[IMP] l10n_*: don't define accounts or tags on tax repartition line templates anymore for 0% taxes
[FIX] account: remove old function used to migrate the former tax model, incompatible with the new one
A new feature[*] in point_of_sale (PoS) which minimizes the
creation of account.move records in closing a pos.session relies
on a receivable account made specifically for PoS.
This commit addresses this feature's requirement by adding a
new receivable account to each localization.
[*] point_of_sale: single AE for a pos.session
TASK-ID: 1862388
Running the following 12.0 tests: https://github.com/odoo/enterprise/blob/b7768337d88990e403338c39e461ecb1796413ab/l10n_mx_edi_landing/tests/test_landing.py#L126
raise the following error using anglo-saxon:
```bash
File stock_account/models/account_invoice.py, line 60, in invoice_validate
File stock_account/models/account_invoice.py, line 89, in _anglo_saxon_reconcile_valuation
File 10n_mx_edi/models/account_move.py, line 12, in reconcile
File account/models/account_move.py, line 957, in reconcile
File account/models/account_move.py, line 948, in _check_reconcile_validity
odoo.exceptions.UserError: ('Account Mercancías en tránsito (115.05.01) does not allow reconciliation. First change the configuration of this account to allow it.', '')
```
closesodoo/odoo#34463
Signed-off-by: Josse Colpaert <jco@openerp.com>
Julien Van Roy