Friday, September 20, 2024
12 changes
2 changes
Resolved issues and error corrections
The Point of Sale product information popup now reads the cashier role from the correct place after a page refresh. This prevents an error for employee logins with administrator PoS access, allowing staff to continue viewing product details normally.
Original PR description
Problem: The `role` attribute is being retrieved from the `raw` field, but when the page is refreshed, all attributes (including `role`) are set in the `cashier` object, not in `raw`. Steps to reproduce: - Set up a PoS session with the "Log in with Employees" setting enabled. - Use a User/Employee with Administrator PoS access (e.g., Mitchell Admin). - Start a PoS session. - Refresh the page. - Click the "i" icon to see more information about a product. - A traceback occurs. opw-4120414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new Argentine company now keeps the AFIP responsibility type selected by the user instead of reverting it to the default Monotributo option. This ensures the correct chart of accounts is loaded from the start, reducing setup errors for Argentine accounting.
Original PR description
Create a company: - Name: Any - Country: Argentina - AFIP Responsibility Type: IVA Responsable Inscripto Save Issue: Company AFIP Type will be set back to Responsable Monotributo This occurs because when company is created the system will try to load the coa. The COA to load is currently determined only by the country of the new company, and the default for new Argentina companies is 'Responsable Monotributo' Then, the AFIP Type is changed to match the CoA In order to take into account the company settings when loading the CoA we check via context if we are operating on a company and load the template matching the AFIP Type opw-4175351
1 change
Resolved issues and error corrections
Fixed an issue where shared public Knowledge articles could appear blank on desktop devices. The page structure was adjusted so article content uses the available screen space correctly, and semantic page sections were restored to support better indexing.
Original PR description
Currently, the article content appears empty on desktop devices because the main container (`.o_knowledge_public_view`) no longer occupies the full vertical space of the page. That issue was…
9 changes
Resolved issues and error corrections
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.
Currently, the article content appears empty on desktop devices because the main container (`.o_knowledge_public_view`) no longer occupies the full vertical space of the page. That issue was introduced in [this pr](https://github.com/odoo/odoo/pull/98429). To resolve this issue, we will remove the wrapper elements: `div#wrapwrap` and the `main` element from the generated pages. This will simplify the DOM structure and allow the main container to take up all the available vertical space without needing to set the height for all containers. Since the body of the frontend_layout is completely overridden for website_knowledge, the `<header>` and `<main>` tags are reintroduced at appropriate places for a Knowledge article. Steps to reproduce the issue: 1. Open Knowledge 2. Publish an article using the share panel (click on the "Share" button) 3. Copy the share link (`/knowledge/article/<article_id>`) 4. Open an incognito tab and access the link copied at step 3 => The article content is hidden on desktop. TO BE: The article content should be visible. task-4193478
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
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