Saturday, July 20, 2024
6 changes · master
Resolved issues and error corrections
This fixes incorrect unit values in the project subscription demo data. It helps ensure sample subscription records display more accurately for testing, demos, and onboarding without affecting live customer data.
Miscellaneous changes
This homogenizes the address format we send for each location and adds the terms and conditions and delivery date. This makes the customer invoice PDF that Avatax generates more complete and less confusing for users and their customers. task-3894745 Forward-Port-Of: odoo/enterprise#66929 Forward-Port-Of: odoo/enterprise#66868
Original PR description
This homogenizes the address format we send for each location and adds the terms and conditions and delivery date. This makes the customer invoice PDF that Avatax generates more complete and less confusing for users and their customers. task-3894745 Forward-Port-Of: odoo/enterprise#66929 Forward-Port-Of: odoo/enterprise#66868
…roup when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553 Forward-Port-Of: odoo/enterprise#66990
Original PR description
…roup when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553 Forward-Port-Of: odoo/enterprise#66990
This [commit](https://github.com/odoo/odoo/commit/12477a5401c4d0eaf39c87c17afc7f82d9018986) changed the way the French tax report computes its value to make sure they are rounded to the unit. It also unintentionally broke the auditing of the tax lines since tax tags are no longer used. The fix consists in adjusting the `expression_label` in the action in order to target the expression that uses the `tax_tags` engine, allowing to display the expected journal items. opw-3999520 Forward-P
Original PR description
This [commit](https://github.com/odoo/odoo/commit/12477a5401c4d0eaf39c87c17afc7f82d9018986) changed the way the French tax report computes its value to make sure they are rounded to the unit. It also unintentionally broke the auditing of the tax lines since tax tags are no longer used. The fix consists in adjusting the `expression_label` in the action in order to target the expression that uses the `tax_tags` engine, allowing to display the expected journal items. opw-3999520 Forward-Port-Of: odoo/enterprise#66909
The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1
Original PR description
The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1]: https://github.com/odoo/enterprise/commit/25ec0ba479372126f84fd1ece6f34aea7b1eb829 Forward-Port-Of: odoo/enterprise#65408
**Steps to reproduce:** - Install Accounting, Sales, l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Order Lines: Product | Quantity | Unit Price | Taxes ---------------|----------------|----------------|---------- Product A | 1.00 | 1000.00 | 16% Product B | 1.00 | 1500.00 | 16% Product C | 1.00 |
Original PR description
**Steps to reproduce:** - Install Accounting, Sales, l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) *…
**Steps to reproduce:**
- Install Accounting, Sales, l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create a SO:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Order Lines:
Product | Quantity | Unit Price | Taxes
---------------|----------------|----------------|----------
Product A | 1.00 | 1000.00 | 16%
Product B | 1.00 | 1500.00 | 16%
Product C | 1.00 | 3000.00 | 16%
- Confirm the SO
- Create a 90% down payment
- Confirm down payment and generate CFDI via "Send & Print" button
- Create a regular invoice for the remaining amount
- Confirm the invoice and generate CFDI
**Issue:**
The verification of the CDFI fails because there is one line with a negative base amount.
**Cause:**
The down payment line has a negative amount.
This negative amount is dispatched between the other lines and the "base" and "importe" values of these other lines are recomputed depending on the amount that is deducted from it.
However, the computation is based on a ratio computed from the price subtotal of the negative line, but the ratio is then applied to the remaining "base" amount of the negative line, which decreases for each deducted line.
This generates incorrect values in "transferred_values_list" field for the the second line and the following ones on which some amount is dispatched.
The issue only happens on the last line on which some amount has been dispatched because it receives the remaining amount that is too high due to the values deducted by the other lines being lower than what it should has been.
**Solution:**
The ratio should be computed from the remaining "base" amount of the negative line.
opw-4033979
Forward-Port-Of: odoo/enterprise#66715