Daily updates from Odoo
Navigate
Branch
Saturday, February 21, 2026
46 changes
12 changes
Resolved issues and error corrections
This update grants the Invoicing & Banks group within the Enterprise version of Odoo access to basic financial reports, specifically 'Statement Reports'. This enhancement improves reporting capabilities for this key user group, allowing them to better monitor their financial data.
Original PR description
In enterprise, we are allowing the Invoicing & Banks group to have access to basic reports, including 'Statement Reports' task-5925567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249709 Forward-Port-Of: odoo/odoo#249006
This update resolves an issue where Invoicing and Banks users were unable to access certain standard financial reports. The change restores previous access rights, allowing these users to view essential reports without encountering errors. This improves usability and reporting capabilities for key business groups.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#108054 Forward-Port-Of: odoo/enterprise#107654
This update resolves a bug where the search bar in the Odoo iOS app incorrectly cleared input when using a Korean keyboard (IME). The fix prevents the search value from being processed prematurely during IME composition, ensuring accurate search results. This improvement specifically targets iOS devices.
Original PR description
Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in progress. Interestingly, the issue could not be reproduced with the Japanese keyboard, which appeared to behave correctly. See [1]. This commit adds an early return while composing to prevent interpreting the value prematurely. Since this is a targeted fix, it is applied only on iOS. Steps to reproduce: - Configure a Korean keyboard on an iPhone - Open a Sale Order - Focus the search bar - Type a character, then type a second one to combine them - The search input value gets reset [1] https://github.com/odoo/odoo/pull/222151 opw-5448385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249473
This update fixes an issue where CABA taxes were incorrectly included in tax reports when part of a tax group. The change ensures that CABA taxes are properly excluded from reports, preventing duplicate amounts and improving the accuracy of financial reporting. This resolves a problem that impacted invoice reconciliation.
Original PR description
How to reproduce: - Create one CABA tax and one normal tax. - Create a tax group containing both taxes. - Create an invoice using this tax group. - In the tax report, the CABA tax appears even when the invoice is unpaid. - After reconciliation, the CABA tax amount is duplicated in the report. When the CABA tax is part of a tax group, it is selected in _read_generic_tax_report_amounts_no_tax_details. Since the tax group has tax_exigibility = 'on_invoice', the CABA tax inside the group is incorrectly included by the query. opw-5468074 Forward-Port-Of: odoo/enterprise#105888
This update corrects an issue where pick-up point names and days of the week were inconsistently capitalized, particularly in Dutch. The fix ensures all pick-up point details are displayed with correct capitalization regardless of the selected language, improving the user experience and data consistency.
Original PR description
Issue: --- In pick-up point list, the case formatting should be: 1- Pick-up point's `name`, `street` and `city` should not be auto-capitalized. 2- Weekdays should must be always capitalized regardless of language. Steps to reproduce: --- 1- Create a second Company named `store`. 2- Create a wh for the created company and add the wh to click-and-collect pick-up points. (There should be more than 1 pick-up points) 3- In the website, add Dutch lang. 4- In website, open a product and, open the `Click and Collect`. Outcome: --- Name is capitalized to `Store` and the days are not capitalized if you switch to dutch lang. Cause: --- Due to CLDR, luxon doesn't capitalize weekdays in some languages. opw-5941830 Forward-Port-Of: odoo/odoo#249600 Forward-Port-Of: odoo/odoo#249078
This update resolves a previous issue where automation flows involving moving documents and triggering subsequent actions frequently failed due to security restrictions. Now, users can reliably create multi-action sequences (Move -> Action) without encountering errors, streamlining automation processes. The change simplifies the system's security rules and enhances overall usability.
Original PR description
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security…
Prior to this commit, creating a multi-action that moved a document to a new folder and immediately triggered another action (e.g., "Create Invoice") often failed. This occurred because the security check required the sub-action to be explicitly embedded (pinned) on the *destination* folder. Since the record was moved during the process, the subsequent action failed the security check on the new folder where it wasn't pinned. This limitation caused confusion for users setting up automation flows, as the intent of the sequence (Move -> Action) was clear and initiated from a valid context (the source folder), but strict per-action security rules blocked execution. This commit improves the `ir.actions.server` execution logic to support this pattern by introducing a context-based security sentinel: 1. Entry Point Validation: When a Documents action (root) is triggered, the system enforces strict security: the action must be explicitly embedded on the record's current folder. 2. Context Inheritance: Once the root action is authorized and begins execution, it sets a secure sentinel in the context. 3. Trusted Execution: Any subsequent sub-actions (children) detect this sentinel and are allowed to run, regardless of the record's current folder location. This ensures that if a user has the right to start the process (the root action), they have the right to complete the defined sequence, even if intermediate steps move the record to a folder where the sub-actions are not explicitly pinned. As a result, the `_can_execute_action_on_records` override in `documents_account` is no longer necessary and has been removed. Tests have been extended in the `documents` and `documents_account` modules to cover these scenarios (using Tags in the `documents` module instead of Accounting-specific models to make the tests generic). A new test file `test_documents_ir_actions_server.py` was created to maintain a clean testing environment, covering nesting, move sequences, and RPC spoofing attempts. Task-5916630 Forward-Port-Of: odoo/enterprise#106702
This update fixes an issue preventing the Hungarian VAT integration from correctly communicating with the NAV system. A recent change shortened the software ID, causing authentication to fail. The fix adds padding to ensure the ID is always 18 characters long, meeting NAV's requirements and allowing the integration to function properly.
Original PR description
**Steps to reproduce:** * Create a **Hungarian** database with **Accounting** or **Invoicing**. * Set a valid **VAT number** on the company. * Configure **NAV credentials** in **production mode**.…
**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.
**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.
**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.
**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.
opw-5902414
Forward-Port-Of: odoo/odoo#247737This update ensures that Peppol invoices always include the attached PDF document. Previously, sending invoices via Peppol bypassed a process that added the PDF to the XML data, causing recipients to only receive the XML. This fix guarantees consistent invoice delivery with the expected PDF attachment.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `accounting_peppol` modules. * Create Belgium company. * Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`. * Create…
**Steps to reproduce:** * Install `Accounting` and `accounting_peppol` modules. * Create Belgium company. * Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`. * Create and post a customer invoice. * Click **Send & Print**. * Select only **Email** and click **Send** to generate the PDF. * Click **Send & Print** again. * Select only **Peppol** (partner configured for Peppol). * Click **Send**. **Observed behavior:** * The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF. * The receiver gets the XML data without the PDF representation. **Cause:** * When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it. * The PDF embedding into the UBL XML relies on this post-processing step. * Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic. **Fix:** * When sending via **Peppol**, detect if a PDF already exists on the invoice. * If so, explicitly post-process the UBL XML to embed the existing PDF before sending. * Ensures the PDF is always included in Peppol messages, regardless of when it was generated. opw-5495465 Forward-Port-Of: odoo/odoo#245901
This update fixes an issue where payment beneficiary accounts were incorrectly assigned after merging inbound and outbound payments. Specifically, when a refund is merged, the system now correctly identifies the appropriate bank account for outbound payments. This ensures accurate payment processing and avoids potential financial discrepancies.
Original PR description
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same…
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account. Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient. The `partner_bank_id` can be assigned through different processes: - If the wizard has only one batch: The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`. - If there are multiple batches: Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id']. The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly. I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are. -Previous PR : [242863](https://github.com/odoo/odoo/pull/242863) However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here. Ticket: opw-5401372 Forward-Port-Of: odoo/odoo#249537 Forward-Port-Of: odoo/odoo#246558
This update fixes a bug where users could enter excessively large negative hours on timesheets without an error. The change ensures that all timesheet entries, regardless of sign, adhere to a six-digit limit, preventing data inconsistencies and improving data accuracy. This ensures timesheet data is reliable.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and…
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#108182 Forward-Port-Of: odoo/enterprise#106781
This update corrects inaccuracies in the fiscal position data for key markets (UAE, Oman, and Bahrain), ensuring accurate tax calculations for both local and international customers. The changes include removing a duplicate data column and cleaning up obsolete records, resulting in a more reliable and consistent tax configuration.
Original PR description
After the changes from 5261836336799076fd8133be943a037f1124b905, several fiscal positions for UAE, Bahrain and Oman were either missing or not fully mapped. So with this PR: - We adapts the fiscal positions and restructures them with a clear country-based split, ensuring taxes are applied correctly for local and non-local customers. - Removes a duplicate sequence column from UAE fiscal position data to avoid confusion and keep the structure consistent. - Cleans up obsolete data in Oman by removing an empty fiscal position row that was previously used for tax source/destination mappings. task-5359829 Forward-Port-Of: odoo/odoo#245383
This update resolves an issue where vendor bills received via Peppol as XML lacked a PDF attachment. Now, Odoo automatically generates and attaches a PDF when one isn't present, allowing users to easily preview and verify the bill data. This improves the user experience and ensures accurate data validation.
Original PR description
Some vendor bills received via Peppol as XML do not include an attached PDF, preventing users from previewing the document and verifying the values parsed by Odoo. This commit generates and attaches a PDF when the XML does not provide one. task-5500236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245577
1 change
Resolved issues and error corrections
This update ensures shift start and end times correctly reflect the selected shift template, even when employees have fixed schedules. Previously, shifts were incorrectly calculating hours based on employee schedules, leading to inaccurate time tracking. This change resolves a discrepancy and provides more reliable shift scheduling.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#107018
5 changes
Resolved issues and error corrections
This update ensures shift start and end times automatically align with the selected shift template, even when employees have fixed schedules. Previously, shifts incorrectly used employee schedules, leading to inaccurate time calculations. This change corrects a critical issue for accurate shift planning.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#107018
This update resolves an issue preventing the Hungarian VAT integration from correctly communicating with the NAV system. A recent change shortened the software ID string, failing to meet the required 18-character length. The fix adds padding to ensure the ID conforms to NAV's specifications, allowing for successful data transmission.
Original PR description
**Steps to reproduce:** * Create a **Hungarian** database with **Accounting** or **Invoicing**. * Set a valid **VAT number** on the company. * Configure **NAV credentials** in **production mode**.…
**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.
**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.
**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.
**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.
opw-5902414
Forward-Port-Of: odoo/odoo#247737This update ensures that PDF invoices are always included when sending invoices via Peppol. Previously, the system skipped a necessary step for embedding the PDF, causing invoices to be sent without the visual representation. This fix guarantees compliance with Peppol standards and improves invoice delivery for our business partners.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `accounting_peppol` modules. * Create Belgium company. * Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`. * Create…
**Steps to reproduce:** * Install `Accounting` and `accounting_peppol` modules. * Create Belgium company. * Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`. * Create and post a customer invoice. * Click **Send & Print**. * Select only **Email** and click **Send** to generate the PDF. * Click **Send & Print** again. * Select only **Peppol** (partner configured for Peppol). * Click **Send**. **Observed behavior:** * The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF. * The receiver gets the XML data without the PDF representation. **Cause:** * When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it. * The PDF embedding into the UBL XML relies on this post-processing step. * Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic. **Fix:** * When sending via **Peppol**, detect if a PDF already exists on the invoice. * If so, explicitly post-process the UBL XML to embed the existing PDF before sending. * Ensures the PDF is always included in Peppol messages, regardless of when it was generated. opw-5495465 Forward-Port-Of: odoo/odoo#245901
This update fixes an issue where payment beneficiary accounts were sometimes incorrect after merging inbound and outbound payments. The fix ensures the correct bank account is assigned, particularly when refunds are merged into outbound payments, maintaining accurate financial records. This improves payment processing reliability.
Original PR description
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same…
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account. Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient. The `partner_bank_id` can be assigned through different processes: - If the wizard has only one batch: The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`. - If there are multiple batches: Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id']. The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly. I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are. -Previous PR : [242863](https://github.com/odoo/odoo/pull/242863) However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here. Ticket: opw-5401372 Forward-Port-Of: odoo/odoo#249537 Forward-Port-Of: odoo/odoo#246558
This update resolves an issue where vendor bills received via Peppol as XML lacked a PDF attachment. Now, Odoo automatically generates and attaches a PDF when the XML is missing this file, allowing users to easily preview and verify the bill data. This improves the user experience and ensures accurate data validation.
Original PR description
Some vendor bills received via Peppol as XML do not include an attached PDF, preventing users from previewing the document and verifying the values parsed by Odoo. This commit generates and attaches a PDF when the XML does not provide one. task-5500236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245577
6 changes
Enhancements to existing features
This update streamlines the creation of global invoices in the Mexican tax reporting module. By changing how the wizard is stored, we prevent unnecessary data from being saved to the database, improving performance and reducing storage needs. This change ensures a smoother and more efficient user experience.
Original PR description
Change to TransientModel so a wizard is not permanently stored in db when creating a global invoice. Forward-Port-Of: odoo/enterprise#107244
Resolved issues and error corrections
This update resolves an issue where scanning packaging barcodes didn't correctly link to associated lots, leading to incorrect inventory tracking. The fix ensures that packaging barcodes accurately identify and link to lots during scanning, improving inventory accuracy and usability.
Original PR description
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with…
When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Go to barcode > Operations > eg. internal transfer > New * Scan packaging barcode * Scan one of the lots -> Issue, the lot create a new line, and will not find the packaging ### Observation: When scanning a barcode, it will first try to find a match with existing lines, In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501 It will erase the line, to avoid to overfill a completed line: https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460 and since, it decided to ignore that line, it will not find another lines, and will create a new one : https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535 Additional Issues ----------------- Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots. Issue 2 : When having sublines with different uoms, it will add the quantity without considering the differences in uoms ### Steps to reproduce: * In the settings enable packagings * Create a storable product P with Units as uom, a barcode and tracked by lots * Create new lots with barcode for Product P * Inventory > Configuration > Product > Units & Packagings * Click on pack of 6 > Packaging Barcodes > New * Create one for your product with a different barcode * Create a packaging 2 with barcode for product A * Go to barcode > Operations > eg. internal transfer > New * Scan packaging 1 barcode * Scan one of the lot 1 * Scan packaging 1 * Scan lot 2 -> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot. * Scan packaging 2 -> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms ### Observation: Issue one : When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460 and since, it found a line, it will just add it's self to the line Issue Two: When creating the group lines it will first calculate the sum of all the quantities: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254 And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity: https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461 opw-5189492 opw-5408372
This update corrects a discrepancy in payslip calculations for the private car allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves the accuracy and transparency of employee compensation.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107576 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. The templates have been updated to the final 20251210 NT20 taxonomy, ensuring compatibility and accurate reporting.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update ensures that timesheet entries with excessively large negative hours (more than six digits) are no longer accepted. Previously, users could add these entries without any error message, leading to potential data inconsistencies. This fix corrects a validation issue to maintain accurate time tracking data.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781
This update fixes an issue where shift start and end times weren't correctly reflecting the assigned shift template, even when employees had fixed schedules. Now, shifts automatically align with the template's hours, ensuring accurate scheduling and time tracking.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#107018
5 changes
Resolved issues and error corrections
This update removes redundant steps in how taxes are applied to invoices, streamlining the process and reducing unnecessary activity. The change prevents excessive logging entries on previously posted invoices, improving system performance. This was identified and corrected by ANDG.
Original PR description
_set_external_taxes() was clearing tax_ids on every line before setting them again in the next loop. This is unnecessary because the write() already uses Command.set() which replaces all existing values. It causes [additional, unnecessary chatter entries on invoices that have been posted before](https://github.com/odoo/odoo/blob/b6d6d129bf284c7cf5f48fa130a7b4522f639401/addons/account/models/account_move_line.py#L1871-L1872). Thanks to ANDG for spotting this.
This update resolves an issue where Odoo was incorrectly including an UETR tag in ISO 20022 XML files for SEPA Credit Transfers. This caused rejection by strict banks, preventing successful payment processing. The fix ensures compliance with EPC rules and avoids errors during file transmission.
Original PR description
In Odoo 18.0, when a user selects the pain.001.001.09 format (ISO 20022), Odoo systematically includes the <UETR> (Unique End-to-end Transaction Reference) tag for every transaction. While valid under the general ISO 20022 XML schema, the <UETR> tag is not authorized by the EPC (European Payments Council) within the standard SEPA Credit Transfer (SCT) Rulebook. Strict banks (e.g., UBS, German banks) reject the entire file with errors such as: "No child element is expected at this point" when an UETR is detected in a domestic or intra-SEPA flow. Task: 5871528 Forward-Port-Of: odoo/enterprise#107869 Forward-Port-Of: odoo/enterprise#105518
This update fixes a calculation error related to the 13th month payment in the Swiss payroll reporting (LPP). The change ensures that the 13th month is correctly included in the base amount used for tax calculations, aligning with current Swiss tax regulations. This improves the accuracy of payroll reports submitted to the tax authorities.
Original PR description
Forward-Port-Of: odoo/enterprise#107908
This update resolves an issue where payroll warnings weren't easily changeable, leading to potential inaccuracies in tax calculations. The change allows for more flexible updates to payroll warning data, ensuring accurate reporting and compliance with Swiss tax regulations. This improves the reliability of the HR payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#107792
This update corrects a technical issue where the timesheet approval reminder email was referencing a deleted action. The change reflects a recent update to the Odoo Enterprise system that consolidated previous week/month timesheet actions. This ensures the approval reminder email functions correctly.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385
3 changes
Resolved issues and error corrections
This update ensures shift start and end times correctly reflect the selected shift template, even when employees have fixed schedules. Previously, shifts were incorrectly calculating hours based on employee schedules, leading to inaccurate shift durations. This change aligns shift times with the intended template, improving scheduling accuracy.
Original PR description
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a…
__ ## Short functional explanation of the error Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours. As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours. ## Reproduction Steps 1. Go to Planning. Click on Configuration tab > roles. 2. Create a role and add an employee as a resource This employee has to have a fixed working schedule. 3. Click on Configuration tab > Shift Templates. 4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created. 5. Click on Schedule tab > By resource and click on New. 6. Select the role you just created. ### Expected behavior The start and end hours should align with the shift template start and end hours. ### Unexpected behavior The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36. ## Origin of the issue We kept computing the working intervals of employees, even if a shift template was set: https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule. __ opw-5898509 Forward-Port-Of: odoo/enterprise#107018
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. The report templates have been updated to the final 20251210 NT20 taxonomy, ensuring compatibility and accurate data submission.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update corrects a bug where users could enter excessively large negative hours in timesheets without an error. The fix ensures that all timesheet entries, regardless of sign, adhere to a six-digit limit, preventing data inconsistencies and improving data accuracy. This ensures timesheet data is reliable.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781
12 changes
Resolved issues and error corrections
This update fixes a bug where multiple physical gift cards added to a single Point of Sale (PoS) order were not being created in the backend system. The issue stemmed from a misinterpretation of data keys, leading to incorrect gift card tracking. This ensures all gift cards are properly recorded, improving order accuracy and reporting.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320
This update fixes a bug that prevented users from adding columns within list items in the HTML editor. The issue stemmed from incorrectly restoring selections after list items were removed. The fix ensures stable column insertion functionality within lists, improving the editor's usability.
Original PR description
Problem: When trying to add a column under a list item, a traceback occurs. Cause: The list item is removed during the operation, but the selection that is restored still references the removed list item. As a result, the selection is restored on a disconnected element, causing a traceback. Solution: Handle column insertion inside lists separately. In this case, according to the specifications, we split the list and insert the columns between the resulting lists (or after the list if the cursor is in the last list item). This avoids restoring the selection on a removed node. Steps to reproduce: - Add any list. - Run `/column` while the cursor is inside a list item. - Observe the traceback. task-5916246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that opening notes are consistently saved to the system, regardless of whether the cash payment method is used. Previously, this data was lost when the cash method wasn't configured, leading to potential data inconsistencies. This change improves the reliability of POS note information.
Original PR description
Before this commit: -------------- - When the cash method was not available for config, opening notes values were not being stored in session data. After this commit: -------------- - Opening notes values will be stored in session data even when the cash method is not available for config. task-5474822
This update improves the handling of invoice generation when using BIS3 files, particularly for Business-to-Consumer (B2C) transactions. Previously, checks for R010/R020 were always performed, even when the EndpointId wasn't required. This change optimizes the process by only performing these checks when PEPPOL is enabled, ensuring efficiency for B2C scenarios.
Original PR description
…peppol checked Some people are using BIS3 files even for B2C. They give the xml files to the accountant for him/her to import the file and generate the invoice in the accounting software. In that case, since it's a B2C transaction, the EndpointId might not be set but that's ok since it's only used to generate the invoice. opw-5952109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a rounding issue that occasionally occurred in Point of Sale invoices. The change prevents unnecessary rounding, ensuring more accurate and reliable invoice totals for our customers. This improves the overall transaction process and reduces potential discrepancies.
Original PR description
Backport of https://github.com/odoo/odoo/pull/247223. opw-5890586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where payment beneficiary accounts were incorrectly assigned after merging inbound and outbound payments. Specifically, when a refund is merged, the system now correctly identifies the payment as an outbound transaction, ensuring the correct bank account is used. This improves payment accuracy and reduces potential accounting errors.
Original PR description
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same…
When we create new payments for bills and refunds, we offer the possibility to merge inbound and outbound payments together if they are from the same provider and the bills all reference the same recipient account. Depending on the balance of the resulting payment, we assign an adequate inbound or outbound bank account as the recipient. The `partner_bank_id` can be assigned through different processes: - If the wizard has only one batch: The wizard is editable and the user can select a bank account from the computed `available_partner_bank_ids`. - If there are multiple batches: Odoo assigns a `partner_bank_id` in `_create_payment_vals_from_batch()`. For an outbound payment, it uses the batch['payment_values']['partner_bank_id']. The problem is that this value is not updated after a merge of payments. If the base line being merged on is a refund, but the result is an outbound payment, then the `partner_bank_id` should be changed accordingly. I decided to include the changes of my previous PR targeting v18 and fixing the grouping of payments, even though it was deemed unnecessary for v17, because it felt weird not to considering how close these fixes are. -Previous PR : [242863](https://github.com/odoo/odoo/pull/242863) However, I can remove these changes or re-target this PR to v18. I am not sure what would be best here. Ticket: opw-5401372 Forward-Port-Of: odoo/odoo#246558
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. It replaces outdated taxonomy data with the final 20251210 NT20 taxonomy, ensuring compliance and accurate reporting.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126
This update ensures that timesheet entries with excessively large negative hour values (over six digits) are now properly flagged as errors. Previously, these entries could be added without warning, leading to potential data inaccuracies. This fix improves data integrity and prevents incorrect time tracking.
Original PR description
Currently, a user can add a timesheet entry with a negative Hours Spent value `exceeding six digits`. **Steps to reproduce:** - Install the `timesheet_grid` module. - Open the `Timesheets` app and click `Add a line`. - Set Hours Spent to a `negative` value with more than six digits (e.g., -1000000). **Observation:** The line is added without any warning, whereas entering a positive value with more than six digits correctly raises an `error`. **Root cause:** At [1], the constraint validates only positive values exceeding six digits. As a result, negative values with more than six digits are not checked and bypass the `UserError validation`. **Fix:** This commit updates the constraint to ensure the six-digit limit applies to both positive and negative values. [1]: https://github.com/odoo/enterprise/blob/660905872909405c0a07a8317b4eb0a42e5854ca/timesheet_grid/models/analytic.py#L46-L49 opw-5909417 Forward-Port-Of: odoo/enterprise#106781
This update fixes an issue where invoices weren't correctly using product category accounts. Now, Odoo automatically checks the entire category hierarchy (parent to child) to find an appropriate account, ensuring invoices accurately reflect the intended income or expense. This improves financial reporting accuracy.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Create a product category hierarchy (grandparent → parent → child). * Set an **income account** on the grandparent category. * Set an…
**Steps to reproduce:** * Install the **Accounting** module. * Create a product category hierarchy (grandparent → parent → child). * Set an **income account** on the grandparent category. * Set an **expense account** on the child category. * Leave the parent category without any accounts. * Create a product assigned to the child category. * Create a customer invoice using this product. **Observed behavior:** * The invoice line uses the **default income account** from settings instead of the grandparent category’s income account. * The category hierarchy is not checked to retrieve parent accounts. **Expected behavior:** * If no account is defined on a category, Odoo should traverse the **parent categories** to find one. * Only if no account exists in the hierarchy should it fall back to journal or default accounts. **Cause:** * Account lookup only checked the **immediate category**. * Parent categories were not considered. **Fix:** * Traverse the product category hierarchy when searching for accounts. * Use the first account found in the parent chain. opw-5869592 Forward-Port-Of: odoo/odoo#248389
This update resolves an issue where expense reports generated with encrypted PDFs would fail to process due to a missing library dependency. The change ensures that the system gracefully handles PDFs without requiring the PyCryptodome library, improving the reliability of expense report generation. This prevents errors and ensures users can continue to accurately track their expenses.
Original PR description
**Issue:** This is a complement to the previous commit: https://github.com/odoo/odoo/commit/2eb12ba5e8055c5a0aa3ab86d0e173b3ca3ff2f0 When using version 2.12.1 of PyPDF2 as required if python version > 3.10, if PyCryptodome library is not installed, a DependencyError will be raised when trying to decrypt the file: "PyCryptodome is required for AES algorithm". opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249737
This update fixes an issue preventing the Hungarian VAT integration from correctly communicating with the NAV system. A change in how the software ID was generated resulted in a shortened string, failing validation. The fix adds padding to ensure the ID is exactly 18 characters, resolving the error and enabling proper functionality.
Original PR description
**Steps to reproduce:** * Create a **Hungarian** database with **Accounting** or **Invoicing**. * Set a valid **VAT number** on the company. * Configure **NAV credentials** in **production mode**.…
**Steps to reproduce:**
* Create a **Hungarian** database with **Accounting** or **Invoicing**.
* Set a valid **VAT number** on the company.
* Configure **NAV credentials** in **production mode**. (use credentials from ticket)
* Try to save the Settings.
**Observed behavior:**
* Authentication fails with error: `INVALID_REQUEST: Helytelen kérés!`
* NAV returns schema violation: `Value 'BE477472701-19110' is not facet-valid with respect to pattern '[0-9A-Z\-]{18}' for type 'SoftwareIdType'.`
* The softwareId is only 17 characters instead of required 18.
**Cause:**
* The `version` parameter was removed from the module manifest by this [commit](https://github.com/odoo/odoo/commit/717619571d1297d6b299b7c47b728841bcd81e69#diff-d96ba04bb478d9dcbade7b9bf9f07305d42a38ce7a906f3387879271cde35fecL7)
* This change shortened the module version string used to build the `softwareId`.
* Truncating the value to 18 characters therefore produced a string shorter than required.
* The NAV API requires the `softwareId` to be **exactly 18 characters**.
**Fix:**
* Pad the generated `softwareId` to **18 characters** using `ljust(18, '0')`.
* Ensures the value always complies with NAV schema validation rules.
opw-5902414
Forward-Port-Of: odoo/odoo#247737This update addresses an issue where vendor bills received via Peppol as XML lacked a PDF attachment, hindering users' ability to preview and verify the data Odoo parsed. The commit now automatically generates and attaches a PDF when one isn't present, ensuring a complete and verifiable vendor bill experience.
Original PR description
Some vendor bills received via Peppol as XML do not include an attached PDF, preventing users from previewing the document and verifying the values parsed by Odoo. This commit generates and attaches a PDF when the XML does not provide one. task-5500236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
New functionality added to Odoo
This update allows users to export General Ledger reports directly to CSV files. This provides greater flexibility for analyzing financial data and integrating it with other business systems. This enhancement simplifies reporting and improves data accessibility for finance teams.
Original PR description
task-5734354
Resolved issues and error corrections
This update addresses a recurring issue preventing the lunch tour from completing successfully. The team increased the timeout duration, allowing the tour to finish without errors. This ensures a smoother user experience for new users.
Original PR description
Trying to increase the timeout runbot-233159