Friday, July 11, 2025
12 changes · saas-18.3
Enhancements to existing features
Odoo now supports the updated mobile-first finance connection flow where users can create a bank account directly from the embedded bank search screen. This helps customers continue setup when their financial institution is not available in Odoo Finance, reducing onboarding friction.
Original PR description
The aim of this commit is making sure that the odoo database code is handling properly the new feature introduced with the iframe revamp in mobile-first. This feature allows user to create a bank account from the iframe directly if Odoo Finance doesn't have the searched institution. task-4481880 Forward-Port-Of: odoo/enterprise#89932 Forward-Port-Of: odoo/enterprise#81894
Expense receipt scanning now identifies the actual merchant or place name, such as a restaurant or fuel station, instead of returning broad categories like food or gasoline. This makes automatically created expense records clearer and more useful for employees and approvers.
Original PR description
The detection of the description has been improved in the latest version of the expense OCR API. It now actually detects a description (restaurant name, fuel station name, etc) instead of predicting a category ('food', 'parking', 'gasoline', etc).
Task [link](https://www.odoo.com/odoo/project/2068/tasks/4623180)
task-4623180
Forward-Port-Of: odoo/enterprise#89898
Forward-Port-Of: odoo/enterprise#89448Resolved issues and error corrections
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
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 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
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
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