Daily updates from Odoo
Friday, July 11, 2025
15 changes · saas-18.3
Resolved issues and error corrections
This fix corrects translation data generated by a recent refactoring across several localization reporting modules. It helps ensure country-specific reports and labels display the right translated text for users in affected regions.
Original PR description
Forward-Port-Of: odoo/enterprise#84682
This fix prevents errors when companies use different email alias domains and route accounting attachments into separate Documents folders. Emails with attachments sent to accounting journal aliases now create and process the related accounting document correctly for the intended company.
Original PR description
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with…
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias. The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question. steps to reproduce: 1. clean DB with documents_account installed 2. create a 2nd company "company 2" 3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com" 4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2 5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company 6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com) 7. send an email with attachment to that alias -> you will get a multi-company error After this commit ------------------ Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected. opw-4727873 opw-4655559 opw-4746321 opw-4766895 Forward-Port-Of: odoo/enterprise#89411 Forward-Port-Of: odoo/enterprise#84997
Users can now share shortcut folders directly from the cog menu next to the breadcrumbs in Documents. This restores a missing sharing option and makes folder sharing more consistent, while also cleaning up unused code.
Original PR description
Before this commit, the share action in the cog menu (next to the breadcrumbs) wasn't available for shortcut folders. This commit fix this issue. This commit also removes some dead code. Task-4897840 Forward-Port-Of: odoo/enterprise#89161 Forward-Port-Of: odoo/enterprise#88512
This fix prevents Belgian 281.50 tax form data linked to shared contacts from causing company consistency errors when installing Inventory. Businesses using Belgian accounting reports can now generate the required tax forms and later enable Inventory without running into an installation crash.
Original PR description
### Steps to reproduce: - Install l10n_be_reports & account_accountant. - Switch to "BE Company CoA" company. - Add "281.50" tag to "YourCompany" contact. - Accounting > Configuration > Accounting >…
### Steps to reproduce: - Install l10n_be_reports & account_accountant. - Switch to "BE Company CoA" company. - Add "281.50" tag to "YourCompany" contact. - Accounting > Configuration > Accounting > Chart of Accounts > Add "281.50 - Commissions" tag to 600000 account in CoA. - Create a Vendor Bill for partner "YourCompany" selling "[E-COM11]". Date it sometime in 2024 and confirm. - Go to Accounting > Reporting > Open 325 Forms. - Create a new form for 2024. - Verify that there is a line for "YourCompany" in the form and generate the XML. - Try to install Inventory. #### > Traceback due to a company inconsistencies. ### Cause of the issue: When creating the new `l10n_be.form.281.50` form for 2024, we create a record for "BE Company CoA" and which `partner_id` is the `res.partner` "YourCompany" which does not belong to any company (and hence is accessible from any). However, on the `forms_281_50` related field of the `res.partner` model is `check_company=True`: https://github.com/odoo/enterprise/blob/bc36a68b68c3d0296ee18c3a121b029dd418f430/l10n_be_reports/models/res_partner.py#L15-L23 Currently, this did not matter because we did no call of the `_check_company`. But if we where to launch a call of the `_check_company` on "YourCompany" `res.partner` we would raise a company error. Now, when you install stock 2 things happen and provoke this call: 1) The `res.partner` model becomes `_check_company_auto`: https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/res_partner.py#L8-L10 2) We create a warehouse for "Your company and update the `partner_data` https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/stock_warehouse.py#L143-L145 https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/stock_warehouse.py#L315 However, the `property_stock_customer` and `property_stock_supplier` are `check_company` related fields: https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/res_partner.py#L12-L17 Therefore, writing on them for a `_check_company_auto` record will launch a call of the `check_company` for all the fields of the record (including the already inconsistent `forms_281_50`): https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/odoo/models.py#L3780-L3781 https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/odoo/models.py#L3867-L3868 ### Fix: We loosen the company check on the `forms_281_50` to not rely on the `_check_company` since the current workflow lead functionally to valid record data's that will always be considered invalid by this method. opw-4845434 Forward-Port-Of: odoo/enterprise#89590
This fix ensures automated bank statement processing uses the correct company context when handling multi-currency transactions. It prevents incorrect suspense amounts and unbalanced accounting entries when scheduled processing runs under a different company.
Original PR description
Before this commit when the cron was triggered in a multi currency environment, the self.env.company could be a different one from the one of the statement line that would cause problem when computing the suspense amount since the currency_rate would be different. In this example: - 2 companies one in EUR, one in USD - On the USD company do a transaction - the cron is trigger with the self.env.company as the EUR one - It will do a partial reconcile with an invoice in EUR - The amount currency of the suspense will be computed by doing the balance * the currency rate. Since the company is the EUR one, the rate is not one and the open currency amount is wrongly computed - This leads to an error of unbalanced move no task id
This fixes an error that could stop Peruvian companies from generating Stock Move PLE valuation reports after validating inventory receipts. The report now uses the correct product category reference, helping users access required stock reporting without interruption.
Original PR description
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to…
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to `Peru`, and switch to this company. - Go to `Receipts` in `Inventory`, create a `new receipt`, and `validate` it. - Go to `Valuation` and click on `PLE Reports`. - Select the `start date` as the day after today, and click on `PLE 13.1`. `KeyError: 'category'` This error occurs during the valuation of the Stock Move PLE reports. In the query, we retrieve product_template.categ_id as category_id [1], but later category [2] is used to access category_id. Since the category key is not present in the line, this causes the error. [1] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L241 [2] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L303 This commit ensures that category_id is used in place of category for safe evaluation. sentry-6723761615 Forward-Port-Of: odoo/enterprise#89379
The point of sale flow now makes sure the invoice option is selected before validating an order, avoiding a validation error that could block sales. A small duplicate line was also removed in the Urban Piper POS integration to keep the code cleaner without changing business behavior.
Original PR description
## After this commit: - It ensure invoice checkbox is selected before validation, preventing the error and allowing the order to validate correctly. - Removed repeated line in `pos_urban_piper`. Runbot [link](https://runbot.odoo.com/odoo/runbot.build.error/159985) Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4916349) runbot-159985 task-4916349 Forward-Port-Of: odoo/enterprise#89486
Shipping connector settings no longer show install checkboxes that pointed to older connector versions. Users are now directed to the Apps menu to choose the correct shipping connector, with clearer labels for newer REST API versions and older connectors hidden by default.
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. Forward-Port-Of: odoo/enterprise#89810 Forward-Port-Of: odoo/enterprise#81354
The India reporting module now uses the official state name "Odisha" instead of the outdated "Orissa" in GSTR-3B report records. This keeps reports aligned with Government of India naming guidelines and avoids presenting outdated regional information.
Original PR description
Issue: As per Government of India guidelines, the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in report. Solution: Updated the records from "Orissa" to "Odisha". opw-4935633 Forward-Port-Of: odoo/enterprise#89947
The Spanish tax report now excludes credit notes from the current reporting period when generating BOE 349 rectification lines. This prevents fully cancelled current-period bills from being reported incorrectly, while still reporting valid corrections for previous periods.
Original PR description
# How to reproduce the issue On a **l10n_es** fiscal position: - Create a bill for the current period and then create a credit note for this bill. - In the tax report, under model 349, download the BOE report. Since the bill has been fully canceled within the same period, no rectification line should appear in the BOE report (correct behavior). - Create a bill from a previous period. - Create a credit note for this bill in the current period. - Download the BOE report from model 349. A rectification line appears for the previous period bill, which is expected. However, a rectification line also appears for the current period bill, which is incorrect, as the bill was canceled within the same period. This commit prevents moves from the current period from being included as rectification lines in the BOE report. opw-4895636 Forward-Port-Of: odoo/enterprise#89624 Forward-Port-Of: odoo/enterprise#89382
This fix prevents employees with minimal access rights from setting negative quantities during refunds from the point-of-sale ticket screen when UrbanPiper is installed. It helps ensure refund controls are applied consistently and reduces the risk of incorrect or unauthorized refund entries.
Original PR description
Fix issue where when `pos_urban_piper` was installed, minimal right employee were able to set negative orderline qty with a refund through the ticket screen. task-id: 4922318 community PR: https://github.com/odoo/odoo/pull/217774 Forward-Port-Of: odoo/enterprise#89669
The Belgian payroll report for double holiday pay now uses the correct label instead of referring to the 13th month. This makes payroll documents easier to identify and reduces confusion for HR teams and employees.
Original PR description
Originally, the name structure for double holiday follows "13th Month -[Legal Name] -[year]". It has been renamed to "[Payslip name]- [Legal Name] -[year]" .
This fix ensures Colombian electronic invoices correctly include cash rounding adjustments when calculating tax totals and generating UBL documents. Businesses using Colombian localization get more accurate compliant invoice files and fewer rounding-related validation issues.
Original PR description
#### [FIX] l10n_co_dian: UBL related cash rounding issues In the community PR the UBL XML generation was adjusted to support cash rounding. (See there for more details) This commit adjusts the code in `l10n_co_dian` to be compatible. #### [FIX] l10_co_edi: tax_amls include rounding lines Currently rounding lines (with taxes) are not included in the tax lines. This is fixed in this commit. See the community PR / commits for motivation. #### info task-4854592 Forward-Port-Of: odoo/enterprise#89439
Shipping labels now include the required print identifier when sent to IoT printers. This prevents unnecessary error messages while keeping label printing behavior unchanged for users.
Original PR description
Before this commit, the shipping label printing would send documents to the printer without using a print_id, which would cause an error (but the document would still print). After this commit, we send a print_id using a UUID just like for report printing, ensuring no error occurs on the IoT. opw-4829908 Forward-Port-Of: odoo/enterprise#89962 Forward-Port-Of: odoo/enterprise#89930
This fix corrects how monthly payroll summary data is grouped during Swiss ELM transmission preparation. It helps ensure payroll reporting totals are aggregated accurately, reducing the risk of incorrect monthly submissions.
Original PR description
Forward-Port-Of: odoo/enterprise#89839