Daily updates from Odoo
Friday, September 20, 2024
12 changes · 17.0
Resolved issues and error corrections
This fixes when the Viettel e-invoice XML section is shown on invoice forms. Users should now see the correct page when working with replacement invoice information, avoiding confusion or missing details.
Original PR description
* PROPBLEM: In form view we try to use m2o.field_name which is 'l10n_vn_edi_replacement_origin_id.l10n_vn_edi_invoice_number', odoo doesn't support that so it will not work at least in form view * SOLUTION: this commit make the invisible condition more simpler and create a non-store field to fix the issue Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a SendCloud contract has no available rates, adding it to a sales order no longer triggers a disruptive popup. Users now see the same message in a red banner, keeping the workflow clearer and less interruptive.
Original PR description
In this PR ================== Some contracts in SendCloud do not have rates. This caused an annoying popup when adding it to the Sales Order. After this PR, the red banner is displayed with the same message instead of the annoying popup when adding it to the Sales Order. Enterprise PR: https://github.com/odoo/enterprise/pull/66976 TaskId: 4012182
This fix corrects how tax tags are calculated when invoices have early payment discounts and multiple line items with different analytic accounts. Previously, the system would incorrectly mark some tax tags as inverted, causing accounting records to be misclassified. The fix ensures tax tags are consistently and correctly assigned regardless of how invoice lines are structured.
Original PR description
### Steps to reproduce the issue: 1. Create a Customer Invoice with two product lines 2. Give a negative price to one of those lines, the total must remain positive 3. Add distinct analytic accounts…
### Steps to reproduce the issue: 1. Create a Customer Invoice with two product lines 2. Give a negative price to one of those lines, the total must remain positive 3. Add distinct analytic accounts to each line's analytic_distribution 4. Add a payment term with applicable early discount 5. Confirm and Register Payment 6. Go to the Journal Entry related to the Invoice 7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case ### Explanation: In the current situation, `_compute_is_refund` and `_compute_tax_tag_invert` will assign a value to `tax_tag_invert` depending on the `account.move.line.balance`. Because of the distinct analytic accounts, the negative line is separated from the others and because of the logic behind the computes, `tax_tag_invert` is set to the opposite value. ### Fix reasoning: While `account.payment` are restricted to `account.move` with the same direction, `account.bank.statement.line` are not. In the current case, the affected lines all have `tax_ids` values. Thanks to this, we can use `account.tax.type_tax_use` independently of the line's balance to differentiate in and out transactions and assign `tax_tag_invert` consistently. We must also consider the case where `account.bank.statement.line`. To target the Early Payment Discount lines, we will separate them from the other values using `display_type`. opw-3989174 Forward-Port-Of: odoo/enterprise#69835
The Intrastat Report was displaying very large decimal numbers when exporting to PDF or XML due to unrounded calculations. This fix ensures that supplementary unit quantities are properly rounded, making the report output clean and readable for EU trade reporting.
Original PR description
With an EU company (i.e. BE) Open a product [PROD], in Accounting Tab set: - Commodity Code: 84716070 - Supplementary units: 0.56 Create an invoice to an EU partner (i.e. IT) with 5 units of [PROD] Confirm invoice Accounting > Reporting > Intrastat Report Export pdf or xml Issue: Report will show a very large decimal number This occurs because the number is computed via SL query that is not rounded opw-4160104 Forward-Port-Of: odoo/enterprise#70181
This fix ensures that when users expand a report line to view detailed sub-lines, the system properly synchronizes pending data changes before retrieving the details. Previously, unsaved changes could cause the displayed details to be inaccurate or inconsistent with the actual data.
Original PR description
Unfolding a report line calls an expand function which is responsible to run an SQL query in order to compute the sub-lines (typically the result of a groupby, but it can be something else on custom report). Not flushing was a mistake and could lead to inconsitencies. Forward-Port-Of: odoo/enterprise#70187
This fix resolves an error that occurred when users tried to open the Profit and Loss report after deleting the Balance Sheet report. The system was looking for a Balance Sheet report that no longer existed and crashing instead of gracefully handling the missing report. Now the system will simply skip the missing Balance Sheet reference and allow users to view their Profit and Loss report without interruption.
Original PR description
Currently, An error is generated while a user is trying to open the 'Profit and Loss' report when balance sheet report is not available Steps to reproduce: - Install an ```account_reports``` module.…
Currently, An error is generated while a user is trying to open the 'Profit and Loss' report when balance sheet report is not available Steps to reproduce: - Install an ```account_reports``` module. - Turn on debugger mode (from SAAS-17.2 no need this). - Navigate to Accounting / Configuration / Management / Accounting Reports, Delete the 'Balance Sheet' report - And Open 'Profit and Loss' report(In Accounting Reports). ```ValueError: External ID not found in the system: account_reports.balance_sheet``` An error occurs when the system tries to retrieve an external id of balance sheet report 'account_reports.balance_sheet' at [1], but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/9d185d78813f776249a4de0469d659723a94d026/account_reports/models/account_report.py#L5401 To handle this issue, add 'raise_if_not_found=False' in ref() so that when balance sheet report is not available it will return a None value instead of traceback. Sentry-5836075163
This fix corrects a display issue in Mexican invoices where the usage description was showing an incorrect mix of two different codes. When generating invoices for Mexican customers, the system now properly displays the correct usage description that matches the selected usage code, ensuring accurate invoice documentation for compliance purposes.
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Usage: General expenses * CFDI to public: [checked] - Confirm the invoice - Generate CFDI and the invoice via "Send & Print" button **Issue:** On the invoice, "Usage" has an incorrect value: "S01 - General expenses" which is a mix of "S01 - Without fiscal effects" and "G03 - General expenses". The description should be the one linked to the code. opw-4118647
This update adds a missing validation rule to the batch payment system to prevent payment method changes that could violate business constraints. While the standard interface already prevents this issue, the fix ensures the constraint is enforced even when records are created or modified through custom views or direct code, protecting data integrity.
Original PR description
payment_method_id is readonly in account.batch.payment's form view when there is at least one payment on the batch. So, it cannot easily be changed in standard in order to break the constraint. It could however happen in custom views or when generating records directly from the code. Forward-Port-Of: odoo/enterprise#70230
Fixed an issue where partner addresses were not shown when assigning a customer to a Field Service task until after saving. The fix restores the address display functionality so users can see the complete partner information right away when selecting a customer, improving the user experience and reducing confusion.
Original PR description
Steps to reproduce: ------- - install field service app - Go to the Field Service app and create a new task. - Assign a partner (customer) to the task. - Notice that the address of the assigned…
Steps to reproduce: ------- - install field service app - Go to the Field Service app and create a new task. - Assign a partner (customer) to the task. - Notice that the address of the assigned partner is not displayed immediately. - The address only appears after the record is saved. cause: -------- - context 'show_address' was not passed to _compute_display_name Technical: --------- In a previous [pull request](https://github.com/odoo/enterprise/pull/56179/commits/676e6c34a9901d4fe7f68859e1b526dfc2090413), the show_address context was removed. As a result, the _compute_display_name method was not able to correctly display the partner's address when a partner was assigned to a task.The address would only appear after the task was saved. Solution: The show_address context should be reintroduced and passed to the `_compute_display_name` method during the task creation or update process. This will allow the address to be displayed immediately when the partner is selected. task-4038335
Fixed a bug where changes to accounting accounts in the asset modification wizard were not being saved. When users modified an asset's depreciation and changed the associated accounts, those changes were lost. This fix ensures all account modifications are properly saved when the wizard is completed.
Original PR description
Issue: ===== Changes of asset are not saved. Steps to reproduce the issue: ============================= - Create a new asset - Add some accounts in the accounting section - Confirm it - Click on modify depreciation - Select re-evaluate - Change the accounts and click modify - The changes are not applied Origin of the issue: ==================== We are not including the values of accounts in the `asset_vals` dict that we use to update the asset. Solution: ========= Added the fields of the accounts to `asset_vals` dict. opw-4100185
This fix prevents users from accidentally changing the Electronic Invoice Type for already-confirmed invoices by restricting modifications to the "Nota de Débito" (Debit Note) setting in journal configuration. Previously, changing this setting would affect all invoices in that journal, including posted ones, causing invoice types to become out of sync. Now, the setting can only be modified for journals that don't have any confirmed or posted invoices.
Original PR description
### Steps to reproduce the issue: 1. Activate Colombian localization 2. Create an Invoice and Confirm 3. Go to _Accounting > Configuration > Journals_ 4. Select Customer Invoices, set Nota de Débito…
### Steps to reproduce the issue: 1. Activate Colombian localization 2. Create an Invoice and Confirm 3. Go to _Accounting > Configuration > Journals_ 4. Select Customer Invoices, set Nota de Débito to True and Save 5. Go back to your Invoice, its Electronic Invoice Type is now "Nota Débito" 6. Set Nota de Débito to False in the Customer Invoices Journal 7. Return once again to you Invoice, its Electronic Invoice Type did not change ### Explanation: When the user changes `l10n_co_edi_debit_note` in an `account.journal`, it changes this value for all entries in said `account.journal`, not only the ones in draft state. https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L65 `_compute_l10n_co_edi_type` depending on `l10n_co_edi_debit_note`, it is called and, if the change is from False to True, `l10n_co_edi_type` is changed to a specific value. https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L72-L81 If `l10n_co_edi_debit_note` is set back to False, `l10n_co_edi_type` is not reverted to its previous value and the user can not manually change this field for posted or cancelled entries. ### Fix reasoning: To avoid such situation from happening, the field will be restricted for journals with entries in a non draft state. opw-4174980 Forward-Port-Of: odoo/enterprise#70133
Fixed an issue where shipping labels could not be created when SendCloud contracts lacked rate information. The system now gracefully handles missing rates, allowing label generation to proceed smoothly without errors. This improves the reliability of the shipping workflow for users with certain SendCloud contract types.
Original PR description
Before this commit ================== Some contracts in SendCloud do not have rates. When trying to generate a label, an error occurs because of the missing rate, preventing the label from being created. After this commit ================= This commit ensures no error is returned when a rate can't be fetched from SendCloud. Label creation can proceed without issues. Community PR: https://github.com/odoo/odoo/pull/173791 TaskId: 4012182