Odoo Changelog — 2024-11-21

Thursday, November 21, 2024

28 changes · saas-17.2

Bug Fixes(1)

Resolved issues and error corrections

[FIX] account: ensure demo data has country set

Coresaas-17.2account

The accounting demo setup now ensures a country is defined for the company. This prevents failures in automated checks that depend on country-specific accounting configuration, improving reliability for test and demo environments.

Original PR description

Fix for 1c5cc23b5eb3b59da10926688fc350b56397b550

Generic CoA sets the country on the company. Without one many tests fail.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#demo data#accounting#tests

Other(27)

Miscellaneous changes

[FW][FIX] account_reports_cash_basis: handle move with multiple receivable accounts

PR #74272

Enterprisesaas-17.2

Original PR description

**Steps to reproduce:** - Install Accounting and Point of Sale - Open a "Point of Sale" session - Create a POS order and pay it by bank - Create another POS order and pay it by Customer Account -…

**Steps to reproduce:**
- Install Accounting and Point of Sale
- Open a "Point of Sale" session
- Create a POS order and pay it by bank
- Create another POS order and pay it by Customer Account
- Close POS session
- Go to Accounting
- Open Bank journal
- Create a statement line and reconcile it with the POS payment
- Go to "Accounting / Reporting / Audit Reports / General Ledger"
- Check the amount of the POS orders in the following journals:
  * [101300] Account Receivable (PoS)
  * [121000] Account Receivable
  * [400000] Product Sales
- Check "Cash Basis Method" in the options
- Check again the amount of the POS orders in the same journals

**Issue 1:**
The amount for "[121000] Account Receivable" is present but it shouldn't because no payment has been done for it yet.

**Extra steps:**
- Create another statement line and reconcile it with the POS customer account payment
- Check again the amount of the POS orders in the same journals

**Issue 2:**
The amount of the POS orders is double the original amount.

**Issue 3:**
If a partial payment is made for one line, the report has incorrect values.

**Cause:**
To retrieve the cash basis lines, a complex SQL query is executed.

Let's take the following entries:

- Invoice:

| account | debit | credit |
| ----------- | -------- | -------- |
| Account Receivable 1 |  100  |   0 |
| Account Receivable 2 |  200  |   0 |
| Product Sales |   0   |  300 |

- Payments:

 | account | debit | credit |
 | ---------------- | ------------ | ----------- |
 | Bank | 50 |    0 |
 | Account Receivable 1 |   0   |   50 |

 |       account        | debit | credit |
 | ------------ | ---------------- | ----------- |
 | Bank                 |  200  |   0 |
 | Account Receivable 2 |   0   |  200|

A SELECT is executed to compute and get the percentage of the paid amount of each receivable/payable account by move, generating a temporary "table" as followed:

| move_id |             matched_percentage|
| ------------------|---------------------------------|
|    1    | 0.5 (50% paid for Account Receivable 1)|
|    1    | 1.0 (100% paid for Account Receivable 2)|

This table is then joined to account_move_line table on move_id where matched_percentage is applied to the amounts.

Issues 1 and 2 are due to the fact that it was assumed that each account move would only contain 1 receivable/payable account, which is not the case here.
As account_id is not present in the temporary table, it is not possible to identify to which account a line of that table refers to.
As there is only a JOIN ON move_id when joining with account_move_line table, each aml from a move is taken into account even when it shouldn't.
In this example, they are taken into account twice because the 2 entries have the same move_id.

Issue 3 is coming from the fact that the WHOLE amount of "Product Sales" is computed with matched_percentage each time.
For example, these 2 lines are computed from the tempory table for "Product Sales":

* Product Sales = 300 * 0.5 = 150 (for Account Receivable 1)
* Product Sales = 300 * 1.0 = 300 (for Account Receivable 2)

The amount for "Product Sales" sums to 450, which is not correct.
It should be 250.

**Solution for issues 1 and 2:**
Get account_id and join account_move_line table on it.
An exception should be done for "Product Sales" when joining account_move_line table because it is not a receivable/payable account and the temporay table only contains receivable/payable accounts.

**Solution for issue 3:**
Compute a ratio for "Product Sales" for each receivable account.
Its amount is 100 for "Account Receivable 1" and 200 for "Account Receivable 2"
So its ratio should be:

* 100 / 300 = 0.33 (for Account Receivable 1)
* 100 / 300 = 0.66 (for Account Receivable 2)

By applying this ratio, the correct amounts are computed for "Product Sales":

* Product Sales = 300 * 0.5 * 0.33 = 50 (for Account Receivable 1)
* Product Sales = 300 * 1.0 * 0.66 = 200 (for Account Receivable 2)

opw-4224136

Forward-Port-Of: odoo/enterprise#74237
Forward-Port-Of: odoo/enterprise#73593

Fix for 1c5cc23b5eb3b59da10926688fc350b56397b550 Generic CoA sets the country on the company. Without one many tests fail. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Steps to reproduce:** - Install Accounting and Point of Sale - Open a "Point of Sale" session - Create a POS order and pay it by bank - Create another POS order and pay it by Customer Account - Close POS session - Go to Accounting - Open Bank journal - Create a statement line and reconcile it with the POS payment - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Check the amount of the POS orders in the following journals: * [101300] Account Receivable (PoS) * [121000] Account Receivable * [400000] Product Sales - Check "Cash Basis Method" in the options - Check again the amount of the POS orders in the same journals **Issue 1:** The amount for "[121000] Account Receivable" is present but it shouldn't because no payment has been done for it yet. **Extra steps:** - Create another statement line and reconcile it with the POS customer account payment - Check again the amount of the POS orders in the same journals **Issue 2:** The amount of the POS orders is double the original amount. **Issue 3:** If a partial payment is made for one line, the report has incorrect values. **Cause:** To retrieve the cash basis lines, a complex SQL query is executed. Let's take the following entries: - Invoice: | account | debit | credit | | ----------- | -------- | -------- | | Account Receivable 1 | 100 | 0 | | Account Receivable 2 | 200 | 0 | | Product Sales | 0 | 300 | - Payments: | account | debit | credit | | ---------------- | ------------ | ----------- | | Bank | 50 | 0 | | Account Receivable 1 | 0 | 50 | | account | debit | credit | | ------------ | ---------------- | ----------- | | Bank | 200 | 0 | | Account Receivable 2 | 0 | 200| A SELECT is executed to compute and get the percentage of the paid amount of each receivable/payable account by move, generating a temporary "table" as followed: | move_id | matched_percentage| | ------------------|---------------------------------| | 1 | 0.5 (50% paid for Account Receivable 1)| | 1 | 1.0 (100% paid for Account Receivable 2)| This table is then joined to account_move_line table on move_id where matched_percentage is applied to the amounts. Issues 1 and 2 are due to the fact that it was assumed that each account move would only contain 1 receivable/payable account, which is not the case here. As account_id is not present in the temporary table, it is not possible to identify to which account a line of that table refers to. As there is only a JOIN ON move_id when joining with account_move_line table, each aml from a move is taken into account even when it shouldn't. In this example, they are taken into account twice because the 2 entries have the same move_id. Issue 3 is coming from the fact that the WHOLE amount of "Product Sales" is computed with matched_percentage each time. For example, these 2 lines are computed from the tempory table for "Product Sales": * Product Sales = 300 * 0.5 = 150 (for Account Receivable 1) * Product Sales = 300 * 1.0 = 300 (for Account Receivable 2) The amount for "Product Sales" sums to 450, which is not correct. It should be 250. **Solution for issues 1 and 2:** Get account_id and join account_move_line table on it. An exception should be done for "Product Sales" when joining account_move_line table because it is not a receivable/payable account and the temporay table only contains receivable/payable accounts. **Solution for issue 3:** Compute a ratio for "Product Sales" for each receivable account. Its amount is 100 for "Account Receivable 1" and 200 for "Account Receivable 2" So its ratio should be: * 100 / 300 = 0.33 (for Account Receivable 1) * 100 / 300 = 0.66 (for Account Receivable 2) By applying this ratio, the correct amounts are computed for "Product Sales": * Product Sales = 300 * 0.5 * 0.33 = 50 (for Account Receivable 1) * Product Sales = 300 * 1.0 * 0.66 = 200 (for Account Receivable 2) opw-4224136 Forward-Port-Of: odoo/enterprise#74237 Forward-Port-Of: odoo/enterprise#73593

### Steps to reproduce: - Create a new project and set it to be billable. - Set an analytic account on it - On the analytic account, set a plan that is not the default plan - Create a sale order for a subscription product with this analytic account and confirm it. - Create an invoice and confirm it. - Go to the project and click on Status Updates - Notice that the revenues show 0 in “Invoiced” even though we have invoiced the product - If we change the plan on the analytic account, we will be able to see the invoiced amount on the profitability report ### Current behavior before PR: When setting analytic account with different analytic plan than the default one the analytic account value will be stored in x_plan{plan_id}_id field when creating the analytic account line record. https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/account/models/account_move_line.py#L3092 https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L106:L122 So when fetching the profitability data for a project we are just checking the account_id field. https://github.com/odoo/enterprise/blob/17.0/project_sale_subscription/models/project.py#L111:L115 ### Desired behavior after PR is merged: We are now using the same method of _column_name() to know which field should we use in the domain whether it is 'account_id' or 'x_plan{plan_id}_id' opw-4137931 Forward-Port-Of: odoo/enterprise#70508

### Steps to reproduce the issue: 1. Activate Mexican Localization 2. With a Mexican Company, create an Invoice and add a Product with a valid UNSPSC code 3. On the Invoice Line, set Price to 1030.17 and add a 3% Discount 4. Confirm then Send & Print (with CFDI checked) 5. In the generated XML, the following values are off: - In node "Comprobante, SubTotal="1030.16" Descuento="30.90" - In node "Concepto", ValorUnitario="1030.16" Importe="1030.16" Descuento="30.90" - Expected are 1030.17 and 30.91 ### Explanation: During the calculation of the values for the CFDI, `gross_price_subtotal_before_discount` is calculated using `price_subtotal` in every case where `discount` is not 100%. This is due to other values affecting `price_subtotal` (e.g.: taxes with `price_include=True`), in which case calculating a value related to `price_subtotal` with `price_unit` would give the wrong result. This calculation method causes rounding issues such as above because `price_subtotal` is rounded before calculating `gross_price_subtotal_before_discount`. ### Fix reasoning: We need to account for any value that could affect `price_subtotal` and make it different from `price_unit * quantity` except for `discount`, which will be included when comparing both values. The case `discount == 100.0` is covered by this new condition as well, since `discount_factor` would equal to 0 and `price_subtotal` too. opw-4183556 Forward-Port-Of: odoo/enterprise#72593

Bug Fixes(1)

[FIX] account: ensure demo data has country set

Other(27)

[FW][FIX] account_reports_cash_basis: handle move with multiple receivable accounts

Bug Fixes(1)

[FIX] account: ensure demo data has country set

Other(27)

[FW][FIX] account_reports_cash_basis: handle move with multiple receivable accounts

[FW][FIX] partner_commission: handle when not all inv. lines have start/end dates

[FW][IMP] sale_amazon: make the Odoo Amazon connector inheritable

[FW][IMP] account_reports: new function to add some new column to the aml query account partner ledger

[FW][FIX] project_sale_subscription : Fetch profit data even if using different analytic plan than default

[FW][FIX] spreadsheet_edition: reduce thumbnail size

[FW][FIX] web_studio: insert p inside empty div

[FW][I18N] l10n_ar_{edi,reports}: update translations

[FW][FIX] delivery_ups{_rest} : extend shipping data

[FW][FIX] l10n_mx_edi: give price_unit priority for gross price_subtotal

[FW][ADD] delivery_fedex_rest: FedEx integration using new REST API

[FW][FIX] sale_subscription: manage duplicate shortcut for different actions

[FW][FIX] iap_extract: change logger error to warning

[FW][ADD] delivery_fedex_rest: FedEx integration using new REST API

[FW][FIX] base: check also related stored fields

[FW][FIX] web_editor: copy paste within blockquote and pre testcases

[FW][FIX] web_editor: text added back after validating a command

[FW][FIX] account: match accounts and groups in branch companies

[FW][FIX] stock: fix arrows direction in stock rule report in case of rtl

[FW][FIX] discuss: release microphone if no longer needed by the recorder

[FW][I18N] l10n_ar{_website_sale}: update translations

[FW][FIX] web: adapt `FormStatusIndicator` alignment

[FW][FIX] web_editor, *: fix traceback when adding section background video

[FW][FIX] web_editor: insert p inside empty div

[FW][FIX] mail: add one-letter domain support for links

[FW][FIX] point_of_sale: Fix wireless_ap.sh waiting for IP

[FW][FIX] mail: correct push notif title in group chat with guests