Saturday, December 7, 2024
6 changes · saas-17.4
Miscellaneous changes
…anges In previous commit [1], we made changes to handle better the invoicing address partner and the commercial partner. This broke facturx constraints. [1]: https://github.com/odoo/odoo/commit/053c6de8e48ff3fea469531cf32352d88111469e task-no Forward-Port-Of: odoo/odoo#189907
Original PR description
…anges In previous commit [1], we made changes to handle better the invoicing address partner and the commercial partner. This broke facturx constraints. [1]: https://github.com/odoo/odoo/commit/053c6de8e48ff3fea469531cf32352d88111469e task-no Forward-Port-Of: odoo/odoo#189907
The `OpenMoveWidget` was usually called from an `account.move.line`, since https://github.com/odoo/enterprise/commit/6ec55979a79a959b0a7a784ceaa5cdc0b7854182 it is called from `account.move`. With this commit, by using `this.props.record.resModel`, we allow the model to be either `account.move` or `account.move.line`, any other models would raise an error as there is no `action_open_business_doc` defined in other models. Steps: - Install 'Accounting` - Create an asset with passed depreciation
Original PR description
The `OpenMoveWidget` was usually called from an `account.move.line`, since https://github.com/odoo/enterprise/commit/6ec55979a79a959b0a7a784ceaa5cdc0b7854182 it is called from `account.move`. With this commit, by using `this.props.record.resModel`, we allow the model to be either `account.move` or `account.move.line`, any other models would raise an error as there is no `action_open_business_doc` defined in other models. Steps: - Install 'Accounting` - Create an asset with passed depreciation entries and confirm it - Go to 'Depreciation Board' tab - Click on a posted entry name -> We land on an other move (in fact, move that have the line with the same id as the depreciation move) or an error (non existing record) opw-4357468 Forward-Port-Of: odoo/odoo#189861
Description of the issue/feature this PR addresses: When there is more than one mail.activity.schedule records created in a process, the function `_compute_plan_available_ids()` will face the error Expected singleton. Current behavior before PR: This issue will not happen when launching the activity plan on WUI because users open one launch plan wizard at a time. When activity plans need to launch simultaneously, we need to create a separate wizard for each plan, this process will caus
Original PR description
Description of the issue/feature this PR addresses: When there is more than one mail.activity.schedule records created in a process, the function `_compute_plan_available_ids()` will face the error Expected singleton. Current behavior before PR: This issue will not happen when launching the activity plan on WUI because users open one launch plan wizard at a time. When activity plans need to launch simultaneously, we need to create a separate wizard for each plan, this process will cause the issue. Desired behavior after PR is merged: The function `_compute_plan_available_ids()` will work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189843
- Created a new module `l10n_mt_pos` to provide a compliance letter required by Maltese businesses for requesting an EXO number. - Automatically installs for Malta by default. - Added a menu item under "Reporting" > "Compliance Letter" to allow users to download the document. Task ID: 4373339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189868 Forward-Port-Of: odoo/odoo#189640
Original PR description
- Created a new module `l10n_mt_pos` to provide a compliance letter required by Maltese businesses for requesting an EXO number. - Automatically installs for Malta by default. - Added a menu item under "Reporting" > "Compliance Letter" to allow users to download the document. Task ID: 4373339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189868 Forward-Port-Of: odoo/odoo#189640
Steps to reproduce ================== - Open any form view - Drag and drop a new html field at the start of the form view => It goes to the bottom Cause of the issue ================== The generated xpath was `<xpath expr="//form[1]/sheet[1]" position="inside"/>` This puts the new element at the end of the sheet Solution ======== If we want to insert something at the start of the sheet, we need to put it before it's first child. If the sheet is empty, we can use inside like p
Original PR description
Steps to reproduce ================== - Open any form view - Drag and drop a new html field at the start of the form view => It goes to the bottom Cause of the issue ================== The generated xpath was `<xpath expr="//form[1]/sheet[1]" position="inside"/>` This puts the new element at the end of the sheet Solution ======== If we want to insert something at the start of the sheet, we need to put it before it's first child. If the sheet is empty, we can use inside like previously opw-4339407 Forward-Port-Of: odoo/enterprise#75276
## Steps to reproduce the issue 1. Activate Mexican Localization 2. In Mexican Company, create two Invoices with one product line: - Price Unit of 3.47, 16% Tax - Activate CFDI to Public 3. Select both Invoices and create Global Invoice ("Actions" drop menu) 4. Check the CFDI tab in one of the Invoices 5. One of those errors pops up depending on your rounding method: #### Round per line: > Code : 301 > Message : Error de validaciones adicionales [Error #CFDI40108] E
Original PR description
## Steps to reproduce the issue 1. Activate Mexican Localization 2. In Mexican Company, create two Invoices with one product line: - Price Unit of 3.47, 16% Tax - Activate CFDI to Public 3. Select…
## Steps to reproduce the issue
1. Activate Mexican Localization
2. In Mexican Company, create two Invoices with one product line:
- Price Unit of 3.47, 16% Tax
- Activate CFDI to Public
3. Select both Invoices and create Global Invoice ("Actions" drop menu)
4. Check the CFDI tab in one of the Invoices
5. One of those errors pops up depending on your rounding method:
#### Round per line:
> Code : 301
> Message : Error de validaciones adicionales [Error #CFDI40108] El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. Folio: 2. Serie: GINV/. El valor del atributo SubTotal (6.95) no coincide con la suma de los importes (3.47 + 3.47 = 6.94)
#### Round globally:
> Code : CFDI40205
> Message : El valor del campo TotalImpuestosTrasladados no es igual a la suma de los importes registrados en el elemento hijo Traslado.
## Explanation
#### Round per line:
With commit odoo/enterprise@933864a38af21a70b219d2824c64fff488acb15f, base and tax amounts were tweaked in order to satisfy some CFDI constraints. This change calculates amounts in an incorrect order: instead of calculating `tax_amount` with the formula `base_amount * tax_rate`, it calculates the base using `total / (1 + tax_rate)` then subtracts the base from the total to obtain the tax amount.
In our example, with a total of `6.94 + 1.12 = 8.06`, the base is calculated as such: `8.06 / 1.16 = 6.94827586207`, rounded to `6.95`, and the tax as such : `8.06 - 6.95 = 1.11`. The difference between the tweaked base `6.95` and the addition of the base of all invoice lines `3.47 + 3.47 = 6.94` is not accepted.
#### Round globally:
During a Global Invoice creation, we will first calculate the values of the Invoices separately. During this calculation, `total_impuestos_trasladados` is rounded with `precision_digits=2` while values in `traslados_list` are rounded with `precision_digits=6`. https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L583-L590 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L950-L961 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L963-L964 https://github.com/odoo/enterprise/blob/800378bfd3fe198647c9b418def3bd36066d9cd7/l10n_mx_edi/models/l10n_mx_edi_document.py#L1000-L1001
In the example, `3.47 * 0.16 = 0.552`, is rounded to `0.56`. The addition of every rounded value gives `1.12` or `1.110400`, which gives the difference between `total_traslados_impuestos` and `traslados_list`.
## Fix reasoning
#### Round per line:
We will add a hack in `_get_post_fix_tax_amount_map`: CFDI accepts a difference of `1e-<precision_digits>`, which means that `precision_digits=2` would allow a difference of `0.01`. If the difference is lower, we will not perform the operation and only round the values.
In our example, the obtained tax amount is `1.12` and the expected tax amount `6.94 * 0.16 = 1.1104`. The difference between the two is lower than `0.01` and is accepted by the CFDI.
#### Round globally:
We will use the calculated values in `_get_global_invoice_cfdi_values` to compute the total price and totals of taxes at the end of the method instead of using the rounded values received from `cfdi_values_list` at the start.
opw-4085403
Forward-Port-Of: odoo/enterprise#75008
Forward-Port-Of: odoo/enterprise#72341