Daily updates from Odoo
Saturday, July 12, 2025
11 changes · master
Resolved issues and error corrections
The Italian point of sale flow now makes sure the invoice option is selected before an order is validated, avoiding a validation error that blocked completion. A small duplicate line was also removed from the UrbanPiper POS integration cleanup.
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#90018 Forward-Port-Of: odoo/enterprise#89486
Companies using separate email alias domains can now send attachments to accounting journal email aliases without triggering a multi-company error. This ensures vendor bills and other accounting documents are created and parsed correctly in the right company folder.
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
The Spanish Model 349 BOE report no longer includes correction lines for bills that were created and fully cancelled within the same reporting period. This prevents unnecessary or misleading entries in official tax report exports while preserving expected corrections for older-period bills.
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
Barcode scanning for product packaging now correctly updates the existing receipt line instead of creating a duplicate line. This helps warehouse teams keep receipts accurate when scanning packs that represent multiple units.
Original PR description
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable…
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable "Units of Measure & Packagings" - Create a product using the base Unit as uom and allowing pack of 6 aspackaging (optional) - Inventory > Configuration > Product > Units & Pacakagings - Click on pack of 6 > Packaging Barcodes > New - Create a new one for your product - Create and confirma receipt for 6 units of your product - Go to the barcode app and scan a pack of 6 #### > A new line 1 pack of 6 was created rather than updating the already existing one. ### Cause of the issue: When the packaging is scanned, we will call the `findLine` of the `BarcodeModel` in order to determine if there is already an existing line that could absorb the scanned qty. However, this call currently requires the uom of the barcodeData to coincide either with the line uom or its referred packaging to be a valid candidate: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1748-L1753 ### Note: This additional check was added in a9a20f8ec5a7883a08eb4bea15dbf3c4cc97caac when the uom and packagings were refactored and merged together. However, it is really unecessary since the system can handle different uoms via these lines: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1450-L1466 ### opw-4866981 Forward-Port-Of: odoo/enterprise#89583 Forward-Port-Of: odoo/enterprise#88494
This update corrects an automated test used to verify rental product comparisons in the webshop. It helps keep quality checks reliable so future changes are less likely to be blocked or incorrectly flagged by a test issue.
Original PR description
See https://runbot.odoo.com/odoo/error/229766
This fix restores missing parts from a previous AI tools refactoring that were lost during rebasing. It helps ensure AI responses and error messages are posted correctly, reducing the risk of failed or confusing AI interactions for users.
Original PR description
The ai tools declaration and usage is refactored here: d37b87a8f270fc72f1c77c25aa11f40db19e866a However, some parts of the code were missing because of rebase errors. This commit corrects the errors.
Subscription pricing or availability rules that depend on a minimum product quantity are now only applied once that quantity is reached. This prevents customers or sales teams from seeing rules intended for larger orders too early, improving quote and checkout accuracy.
Original PR description
Rules applicable above a specific product quantity should not be considered unless the minimal quantity is reached. Forward-Port-Of: odoo/enterprise#89637
When an employee offer starts in the future, the related payslip is now created starting on that same contract date instead of the current month. This prevents payroll documents from being generated for a period where the contract is not yet active, reducing errors in salary package workflows.
Original PR description
When creating an offer with a contract date start in the future, the payslip created is still set at the current month, so the contract is outside the payslip. This is fixed by creating a payslip with date_from equal to the contract_date_start. Task: 4903936 Forward-Port-Of: odoo/enterprise#88910
The Belgian payroll double holiday pay report now uses a more accurate document name instead of referring to the 13th month. This helps payroll teams and employees identify the correct report more easily and avoids confusion between different payment types.
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]" . Forward-Port-Of: odoo/enterprise#88732
This fixes an issue where automated bank statement processing could use the wrong company context in multi-currency setups. It helps prevent incorrect currency calculations that could create unbalanced accounting entries.
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 Forward-Port-Of: odoo/enterprise#89244
Appointment request notifications now include CC contacts when manual confirmation is enabled. This ensures relevant people are informed as soon as a booking request is submitted, especially for resource-based appointments where no staff member may otherwise receive a confirmation email.
Original PR description
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go…
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go to the appointement website (/appointement) - Create an appointement and submit it - Nothing is sent to CC contact when the request is made **Issue:** Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation. This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester). The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment. **Fix:** Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity. related: cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98 opw-4658521 Forward-Port-Of: odoo/enterprise#88042 Forward-Port-Of: odoo/enterprise#86710