Daily updates from Odoo
Thursday, March 12, 2026
320 changes
17 changes
Resolved issues and error corrections
This update resolves a minor display issue in the account reports where the green comparison color was not consistently appearing. The fix corrects a conversion error introduced after the Dictalypse merge, ensuring the correct color is now displayed for comparison data.
Original PR description
With Dictalypse merged, there is a small mistake converting mode <=> comparison_mode since column_percent_comparison_data is now technically a column. The fix is to use comparison_mode instead of mode in the js view.
This update prevents a crash when multiple employees are selected and the 'End of Collaboration' action is initiated. The action was incorrectly designed to work with list views, leading to an error. Now, the action is only available when working with a single employee record in the form view.
Original PR description
## Steps to reproduce: - Go to Employees list view - Select multiple employees - Action menu > "End of Collaboration" - ValueError is raised: "Expected singleton: hr.employee(...)" ## Reason: - The server action `action_hr_employee_departure` had no explicit `binding_view_types`, so it defaulted to `list,form`. - When triggered from the list view with multiple records selected, it called `action_new_departure()` which enforces `ensure_one()`, causing a crash. - Multiple departures are no longer supported https://github.com/odoo/odoo/pull/245519/changes/774853c1e13a556edd61eea7f4bce65e8b7fc163 ## Fix: - Action is only surfaced in the form view, where the recordset is always a singleton. Task-3505331
This update corrects a technical issue where unused database records related to HR work entries were not being properly removed. The fix ensures the database remains clean and efficient, preventing potential performance impacts. This change is considered low impact.
Original PR description
The records `hr_work_entry.access_hr_work_entry_officer` and `hr_work_entry.access_hr_work_entry_system` no longer exist. They have been removed by https://github.com/odoo/odoo/pull/244436. runbot_build_error-240728
This update resolves an error that occurred when users attempted to generate lots without a defined sequence. The fix ensures the system handles cases where a product's lot sequence is not yet created, preventing a critical error and allowing lot generation to proceed smoothly. This improves the reliability of inventory management.
Original PR description
Currently, an error occurs when a user tries to generate lots while providing a lot number. **Steps to replicate:** - Install purchase (without demo). - Create a product `test`. - Install stock and…
Currently, an error occurs when a user tries to generate lots while providing a lot number.
**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.
**Error-1:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
self.ensure_one()
File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```
**Error-2:**
```
File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].
**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
assignment triggers only during the record creation, any records created
before stock is installed will not be assigned any value for
`lot_sequence_id`.)
- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].
**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**
**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.
**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.
[PR]: https://github.com/odoo/odoo/pull/240368
[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026
[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237
[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227
[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989
[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994
[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000
[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004
[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025
sentry-7254849206,7265844194
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248846This update resolves an issue where payments weren't automatically matched to invoices when 'Outstanding Receipts' accounts were configured in the bank journal. The fix allows for amount matching, ensuring payments are correctly reconciled with invoices, even with this account setting in place. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387 Forward-Port-Of: odoo/enterprise#109992 Forward-Port-Of: odoo/enterprise#108564
This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product prices (starting with '23'). The fix adds logic to handle these barcodes, mirroring the functionality in the Point of Sale app, ensuring accurate product recognition.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#110034 Forward-Port-Of: odoo/enterprise#109627
This update resolves a technical issue that prevented users from exporting data from the CRM forecast reports via the Kanban view. The problem occurred when the system processed empty month columns, leading to a division-by-zero error. This fix ensures data can now be reliably exported without errors.
Original PR description
Steps to reproduce: 1- Install CRM 2- Go to [CRM -> Reporting -> Forecast] 3- Export the data from Kanban view Description of issue: Traceback: ZeroDivisionError Expected behavior: Should export into excel sheet without error Why this happens: When exporting from a Kanban view, all month columns are processed even if they contain no records. In these cases: 1. `self.data` is empty, causing the logic to skip the if condition 2. Since `self.count` is 0, the final division fails with a ZeroDivisionError. opw-5962440 Forward-Port-Of: odoo/odoo#252262
A technical issue prevented the generation of customer statement reports. This fix ensures the necessary data is always provided to the report generation process, resolving an error that caused the preview and PDF generation to fail. This improves the reliability of a key reporting feature.
Original PR description
**Steps to reproduce:** * Install the **l10n_my_reports** module. * Go to `Accounting > Reporting > Partner Ledger`. * Change report to `Customer Statement`. * Add data in the report and click Send. * In the email template, set the `dynamic reports` as `statement of accounts` under the options tab. * Click Preview. **Observed behavior:** * Error: `TypeError: Domain() invalid argument type for domain: None` * Email preview fails and PDF cannot be generated. **Cause:** * The `statement_account_document` template uses `filtered_domain(domain)` but the domain variable was not being passed to the template context by the `_get_report_values` method, resulting in None being passed to `filtered_domain()`. **Fix:** * Ensure domain is always present in the report context, defaulting to an empty list when not provided. * Added safe handling for missing data and context parameters. opw-5880385 Forward-Port-Of: odoo/enterprise#107400
This update fixes a potential error in the Account PEPPOL module that could cause sync failures when a PEPPOL user isn't configured. The change simply skips the email proxy sync process in these situations, ensuring smoother and more reliable operation. This improves the overall stability of the PEPPOL integration.
Original PR description
**[FIX] account_peppol: skip contact email proxy sync when no peppol user exists.** Before this fix the sync would fail in certain scenarios when there is no proxy user preset in the database. The fix is to simply skip the proxy call if no user is present. opw-5980696 Forward-Port-Of: odoo/odoo#251719
This update fixes a display issue in the SEPA payment wizard, ensuring the warning message accurately reflects the number of payments being processed (originally showing 4 when only the first installment was being paid). Additionally, a visual bug where the 'group payment' button was incorrectly displayed has been resolved. This ensures accurate payment tracking and a better user experience.
Original PR description
[FIX] account: right number of payments skipped in send wizard Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/odoo#252870 Forward-Port-Of: odoo/odoo#247830
This update fixes an issue where the SEPA payment wizard incorrectly displayed the number of payments being skipped. The change ensures the warning message accurately reflects that only the first installment of each bill is being paid. Additionally, a visual bug related to the 'group payment' button has been resolved.
Original PR description
[FIX] account_iso20022: right number of payments skipped in send wizard adding tests to the community commit Steps to reproduce: - install modules account_sepa_direct_debit, account_iso20022 - create 2 vendor bills with payment terms so that there are 2 installments per bill, and post them - from the list view, select both bills and click pay - select SEPA as a payment method, a warning message is displayed mentionning 4 payments We want the warning to display a number of 2 payments because we're paying only the first installment of each bill This commit also fixes the visibility of the "group payment" button: when two bills from different suppliers were selected with one having installments, the button was visible task-5917803 Forward-Port-Of: odoo/enterprise#110020 Forward-Port-Of: odoo/enterprise#106894
This update fixes an issue where average daily and weekly hours weren't calculated correctly when using the 'Define Amount of Hours per Day' option in employee schedules. The fix ensures that hours are accurately computed based on duration when this option is selected, leading to more reliable time tracking data.
Original PR description
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per…
## Short functional explanation of the error When editing attendances of a schedule for which we checked the box `Define Amount of Hours per Day`, the resulting average hours per day and hours per week fields aren't computed correctly. ## Reproduction Steps 1. Go to Employee > configuration > Working Schedules. 2. Create a working schedule. Check the box Define Amount of Hours per day and in the Working Hours tab, remove all intendances. 3. Add a line for Monday, set the day period to Full Day and the duration in hours to 4. 4. Repeat the operation for tuesday and wednesday. ### Expected behavior As we have 3 days during which we work 4 hours, the average hours per day should be 4, and the total hours per week should be 12. ### Unexpected behavior The average hours per day and hours per week don't show the correct numbers. ## Origin of the issue We compute the hours per week with this method: https://github.com/odoo/odoo/blob/ae9fd7cc7d434d4b222c81aa58515c57d7426b65/addons/resource/models/resource_calendar.py#L690-L696 However, when we check the box `Define Amount of Hours per Day`, we don't set the attendances starting and ending hours. Instead, we work with duration hours. Therefore, when the box is checked, we have to compute the weekly hours with the field `duration_hours`, and not `hour_from` / `hour_to`. __ opw-5885571 Forward-Port-Of: odoo/odoo#248627
This update resolves an issue preventing remote calls to certain class methods within Odoo. Specifically, methods defined as `@classmethod` or `@staticmethod` were incorrectly accessible. This change enforces a stricter policy, ensuring only standard methods can be called remotely, improving overall system security and stability.
Original PR description
Access /doc, see that `is_transient` is listed, call it via JSON-2. Error 422 "Unprocessable Entity": too many positional arguments.
The `is_transient` method is defined as follow:
```py
@classmethod
def is_transient(cls) -> bool:
""" Return whether the model is transient.
See :class:`TransientModel`.
"""
return cls._transient
```
It is a `@classmethod` and take no argument. Only regular methods can be called remotely. The `@classmethod` and `@staticmethod` (actually, all methods that are defined on the class, and not on the instance) are now considered private.
Reported-by: Florent Xicluna <florent.xicluna@camptocamp.com>
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253066
Forward-Port-Of: odoo/odoo#252739This update corrects a calculation error in the HRA (House Rent Allowance) rules for Indian employees. The change ensures that HRA percentages are accurately applied, aligning with standard India payroll practices. This improves the consistency and reliability of employee compensation calculations.
Original PR description
… fields - compute HRAMN from categories['BASIC'] with result_rate = l10n_in_hra_percentage * 100 - add python condition to skip the rule when HRA percentage is zero - keeps ind_emp behavior consistent with regular India payroll rules task-5964270 Forward-Port-Of: odoo/enterprise#108507
This update fixes an error in how outstanding amounts are calculated when a down payment is reversed with a credit note. Previously, the system incorrectly produced negative amounts, leading to incorrect settlement calculations. Now, the system accurately reflects the remaining balance, ensuring proper financial reporting.
Original PR description
When having a down payment that is reversed by a credit note, the amount unpaid is wrongly computed. This is because we take the sum of invoice lines price total, regardless they come from invoice or credit note. Therefore we end up with negative value. Steps: - Have a SO for 500 - Make a downpayment for 300, confirm - Make a credit note for the downpayment invoice, confirm -> SO's amount unpaid is -100, it should be 500. If you now settle the SO, the amount unpaid will be -300 instead of 0. opw-5175562 Forward-Port-Of: odoo/odoo#253135 Forward-Port-Of: odoo/odoo#233248
This update corrects a validation error that occurred when sending invoices to Peppol. The system previously used an outdated UoM conversion ('QT') that is no longer compliant with UN/ECE standards. This fix ensures invoices meet current regulatory requirements for international exchange.
Original PR description
Currently, the Odoo UoM 'qt (US)' is converted to 'QT', which is not valid anymore. Based on investigation, this was originally set to QT following this link: https://unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_rev3_Annex2e.pdf But this document seems dated from 2005. Step to reproduce: - Create an invoice with a line with 'qt (US)' as UoM - Try to send the invoice to Peppol - You will get a validation error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21" Also removed the link to unece.org since the link is no longer valid. opw-5961476 Forward-Port-Of: odoo/odoo#252803 Forward-Port-Of: odoo/odoo#252174
This update resolves a technical issue within the Odoo Enterprise payroll module (l10n_be_hr_payroll) that was causing errors. The fix corrects a mistake in how the system processed data, preventing a system failure and ensuring accurate payroll calculations. This ensures the payroll system continues to function correctly.
Original PR description
Use the correct var instead of self in the loop.
This solve the raise ValueError("Expected singleton: %s" % self) raised by the orm.34 changes
Resolved issues and error corrections
This update fixes a UI bug that occurred when changing wage intervals in the employee payroll settings. The issue stemmed from extra text being inserted into the employee form, causing errors. The fix removes this extraneous text to ensure correct wage calculations.
Original PR description
Bug production steps: First, I created a new db with saas-19.1 db from runbot, from payroll->employee->Payroll tab in form view, when you change wage interval to another thing than 'month' error occurs Bug cause: There is another text like /2 months, /2 weeks are inserted from hr_employee_views in the hr_contract_salary_payroll to the XML of the employee form view. Bug solution: Removing the corresponding XML insertions. task - 5469378
This update resolves an issue where point of sale reports were incorrectly identifying orders due to date precision. The fix ensures the refund order is always prioritized during report generation, guaranteeing accurate reporting of transactions. This improves the reliability of sales data.
Original PR description
The test test_refund_multiple_products_amounts_compliance was doing a search on 'report.pos.order' and was wrongly assuming that the first order in the recordset returned was the refund one and the other one was the original order. This was because the search is ordered by date descending and the refund order is created after the original order. However, in some cases, the date of the refund order can be the same as the date of the original order cause the dates are precise to the second which can lead to a the records returned by id ascending which would give the original order first. This commit adds an explicit order by id descending as second choice to ensure that the refund order is always returned first. runbot-error: 238454 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a naming inconsistency within the HR payroll module. The template was previously identified with a longer, less clear name. This change simplifies the naming to align with standard Odoo module practices, ensuring better organization and easier identification of the module.
Original PR description
Currently in hr_payroll, the template name is set as l10n_be_hr_payroll.DropdownSelectionBadge. Generally, it should follow the module name. Therefore, in this commit, I replaced l10n_be_hr_payroll with hr_payroll
This update corrects a bug where users without HR document centralization enabled were seeing all documents, not just their own employee documents, when using the 'documents' smart button. The fix restores the intended behavior for companies without this HR setting, ensuring employees only access their own files. This resolves a previous issue impacting document access.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update reduces the visual prominence of reply text in conversations, making it easier for users to read and manage lengthy threads. By lowering the opacity and restoring it on hover, the changes enhance the overall user experience and reduce visual fatigue when reviewing conversations with many replies.
Original PR description
Before this commit, conversations that had a lot of replies were quite exhausting. This comes from the visual of "reply" text that had its text that is too visible, contributing to having a feeling that there's too much text on the screen. This commit fixes the issue by reducing the visibility of reply to part, so that it's easier to read conversations with lots of reply-to. Opacity has been reduced to keep the reply-to content recognizable enough, and this reduced visibility is canceled on mouse-hover, also making the hover effect on reply-to more apparent. Before / After <img width="604" height="520" alt="Screenshot 2026-02-27 at 19 06 03" src="https://github.com/user-attachments/assets/04a118bc-5fc0-47d6-ad62-3b7e26f835da" /> <img width="604" height="525" alt="Screenshot 2026-02-27 at 19 05 50" src="https://github.com/user-attachments/assets/37974f2c-054c-44bc-bf9a-044825908abc" /> Forward-Port-Of: odoo/odoo#251295
This update resolves a technical issue where products weren't correctly marked as 'available' in self-order tests. This prevented some products from loading properly in the self-ordering frontend, causing test failures. The fix ensures all products are correctly identified as available, improving the reliability of self-order functionality.
Original PR description
In some self order tests, available in pos was not set to true which could cause some errors in the tests as some products were not loaded in the self frontend. runbot-error: 241086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252985
This update corrects a bug that prevented users from successfully removing a company association from expense records. The fix ensures that the system handles company removal correctly, preventing a technical error that previously disrupted the process. This improves the reliability of expense record management.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
This update corrects a visual issue where the unit price wasn't shown on product pages when using the 'boxed' layout in the ecommerce section. The fix ensures all layout styles display the crucial unit price information for customers, maintaining a consistent and informative shopping experience. This resolves a prior bug introduced during a recent website update.
Original PR description
### Issue before the commit: In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed. ### Steps to reproduce the issue: - Download website and…
### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.
### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style
### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.
### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.
### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout:
```
<small t-if="combination_info.get('base_unit_price')"
class="ms-1 text-muted o_base_unit_price_wrapper d-none">
<t t-call="website_sale.base_unit_price">
<t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
</t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />
After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />
opw-5920598
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250319This update resolves an issue where Odoo invoices for Danish companies were incorrectly formatted according to Peppol standards. The change skips adding redundant PartyIdentification information, preventing a technical error and ensuring compliance with regulations. This ensures smooth invoice processing when submitting to Peppol.
Original PR description
Currently, if a Danish partner has a reference set, Odoo adds it under PartyIdentification. This violates Peppol `DK-R-013`, which mandates using schemeID when PartyIdentification is used. Adding the Danish schemeID would also trigger another error, `PEPPOL-COMMON-R042`, as the organization number (CVR) must be included in the `_text`. Including schemeID seem therefore unnecessary since it will appear in CompanyID. Steps to reproduce: - Create a Danish company and enable Peppol - Create a Danish customer with a reference - Create an invoice and submit to Peppol, `DK-R-013` error occurs opw-5921602 Forward-Port-Of: odoo/odoo#251737
This update ensures that the system accurately reflects outstanding POS amounts after an order is cancelled. Previously, cancelled orders were incorrectly included in payment calculations. This change prevents inaccurate reporting and ensures financial data integrity following order cancellations.
Original PR description
Add `pos_order_line_ids.order_id.state` to the depends of `_compute_pos_amount_unsettled` so that cancelling a POS order triggers a recompute. Also exclude cancelled order lines from `total_pos_paid` to avoid counting payments that were rolled back. opw-5997872 Forward-Port-Of: odoo/enterprise#109542
This update fixes an issue where currency exchange differences weren't correctly displayed in DATEV exports. The fix adjusts how the system calculates amounts for exchange difference entries, ensuring accurate reporting of financial transactions. This improves the reliability of data sent to DATEV.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update adjusts the order in which taxes are processed for Mexican accounting (l10n_mx). Previously, the order caused incorrect tax calculations due to how taxes are prioritized. This change ensures accurate tax calculations and avoids potential financial discrepancies for Mexican users.
Original PR description
The current layout has the IEPS first, then IVA, and finally the Withholding, this will cause calculations to be wrong because of tax hierarchy. Most users are not aware that the tax order affects the calculation, so this would help prevent incorrect results. task-5247176 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252780
This update prevents installation errors related to PostgreSQL permissions during the AI module setup. Previously, the installation process would fail if the PostgreSQL user lacked the necessary rights. Now, the system checks for the extension's presence before attempting to install it, reducing the need for extensive user permissions.
Original PR description
[FIX] ai: test if pg_vector is installed before launching the create extension command
The command `CREATE EXTENSION IF EXISTS ...` require the postgresql user to have rights to use the command `CREATE EXTENSION`.
If the extension is already installed it will fail with a stacktrace because of inssuficient rights. `psycopg2.errors.InsufficientPrivilege`
With this PR we want to be able to install the module without giving too many rights to the postgresql user.
Forward-Port-Of: odoo/enterprise#109650This update ensures that taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't directly provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, taxes are calculated using standard product tax rules, ensuring accurate tax handling for all UrbanPiper orders.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#109096 Forward-Port-Of: odoo/enterprise#106686
This update clarifies the message displayed when a live chat conversation ends, replacing ambiguous ellipses with a clear statement. This change improves the user experience by removing potential confusion and ensuring users understand the conversation has concluded. The update affects the live chat functionality within Odoo.
Original PR description
This commit updates the chatbot completion message from 'Conversation ended...' to 'Conversation has ended.' The previous version used ellipses, which typically suggest an incomplete thought. Since the message is meant to clearly indicate that the conversation has concluded, the ellipses were unnecessary and potentially confusing. Forward-Port-Of: odoo/odoo#252868 Forward-Port-Of: odoo/odoo#251166
This update fixes a stock management error that previously lacked specific details about the problematic package. By identifying the package causing the issue, users can quickly diagnose and resolve inconsistencies, especially during large product transfers. This improves efficiency and reduces downtime for our customers.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252351 Forward-Port-Of: odoo/odoo#249290
This update fixes a critical issue where AI chat failures resulted in confusing error messages for users. The changes now provide more informative messages – ‘oops’ or ‘Connection Interrupted’ – and ensure a smoother user experience when the AI chat encounters problems, preventing data loss and improving reliability.
Original PR description
Steps to reproduce: 1. Open the Website Editor 2. Select some text 3. Click the AI tool from the toolbar 4. Send a message in the chat window 5. Observe a non-standard error dialog showing 500 HTTP…
Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error
The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.
This commit improves error handling for both public and internal AI chat
by:
- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.
The following behavior will now be observed during error in the UI.
- Public AI chat:
- Initial fetch failed: shows "oops" message
- Stream interrupted:
- Server handled: shows "oops" message
- Server stopped: shows "Connection Interrupted" dialog
- Internal AI chat:
- Initial fetch failed: show RPCError dialog
- Stream interrupted:
- Server handled: shows RPCError dialog
- Server stopped: shows "Connection Interrupted" dialog
We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.
TASK-ID: 5886825This update ensures phone numbers are consistently displayed and formatted within the Odoo Enterprise system. Previously, the system would incorrectly display a phone number's country based on the selected flag, leading to inconsistencies. This fix corrects this issue by recalculating the country information based on the formatted number, ensuring accurate display and functionality.
Original PR description
When parsing a keypad number, we were formatting the phone number with a fallback country (from the currently selected flag) but still resolving the returned country/flag from the pre-format parsing context (see [1]). This could lead to inconsistencies where the number is normalized as +1... while the UI country remains the previously selected one (e.g. Belgium). This commit recomputes country information from the formatted number before returning countryId/storeData, so the softphone flag matches the normalized phone number. Also adds a controller regression test covering this behavior. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 task-5995387
This update resolves an issue where incoming emails with attachments using the 'bin/plain' MIME type would fail to process, preventing vendor bill creation. The fix normalizes these attachments to 'application/octet-stream', ensuring all emails are correctly parsed and attachments are preserved.
Original PR description
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized. As a result,…
When parsing incoming emails, mail.thread normalizes some malformed MIME types before calling part.get_content(). However, attachments using Content-Type `bin/plain` are not normalized.
As a result, Python's email content manager raises KeyError('bin/plain') during parsing, which aborts the whole message processing. This prevents the incoming email from being processed, including vendor bill creation from email aliases.
Steps to reproduce:
- build an email with an attachment using Content-Type `bin/plain`
- parse it through `mail.thread.message_parse`
Before this commit, parsing crashes with KeyError('bin/plain').
This commit treats `bin/plain` like the other unsupported attachment MIME types already handled in stable, by falling back to `application/octet-stream`, allowing the message to be parsed and the attachment to be preserved.
opw-5439156
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251440This update fixes a potential security issue by properly escaping HTML within error messages displayed in the API documentation. A clipboard button has also been added for easier copying of these error messages. This ensures a cleaner and more reliable user experience for developers.
Original PR description
Before this commit: Request errors were unescaped. After this commit: Request errors are properly escaped. A clipboard and a collapse button were added for ease of use. Forward-Port-Of: odoo/odoo#252767
This update resolves an issue where the HTML editor wasn't accurately reflecting changes made by users. Previously, multiple edits could lead to the field incorrectly showing as 'clean,' preventing users from seeing and applying updates. This fix ensures that the editor correctly tracks all changes made within the field, improving data accuracy and usability.
Original PR description
Prior to this commit, it was possible to: - make change A inside a html_field - save/commitChanges - make change B inside the html_field, before the end of the save/commitChanges - the field ends up incorrectly marked as "not dirty" (user can't use the FormStatusIndicator) even though change B was not committed yet. Solution: Give an id to the dirtiness, and associate that id with an extracted value from the editor. When the record update is done, mark the field as not dirty ONLY IF the current dirty id is the same as the id previously associated with the extracted value, else the field stays dirty. task-5976348 Forward-Port-Of: odoo/odoo#253192 Forward-Port-Of: odoo/odoo#252655
This update corrects a display issue on Arabic receipts where phone numbers were printed right-to-left instead of left-to-right. The fix ensures phone numbers are correctly formatted in Arabic language environments, improving the user experience for Arabic-speaking customers. The change involves adjusting the HTML formatting to explicitly set the direction of the phone number text.
Original PR description
# Steps to reproduce: - Open the company, change the language to Arabic - Go to POS, open the shop - Buy anything and click on receipt # Problem: When clicking on the receipt, you would find the…
# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt
# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.
# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12
# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />
There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
get phoneText() {
return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
}
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />
**Drawback:**
- The inconsistency between how the number is stored and how we view it.
# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+ get direction() {
+ return localization.direction;
+ }
```
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
<t t-if="props.data.company.phone">
- <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ <t t-if="direction == 'ltr'">
+ <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ </t>
+ <t t-elif="direction == 'rtl'">
+ <div><t t-esc="props.data.company.phone" />Tel:</div>
</t>
</t>
```
**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability
opw-5881503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#252348
Forward-Port-Of: odoo/odoo#249060This fix addresses an issue where the price calculation from a BOM wasn't accurate when the BOM was created without specifying a product variant. The update ensures the work center efficiency is correctly applied during the cost computation, leading to more precise pricing for multi-variant products.
Original PR description
**Issue** Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product. **Steps to reproduce** - Create a product with several variants - Create a BOM for that…
**Issue**
Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product.
**Steps to reproduce**
- Create a product with several variants
- Create a BOM for that product without specifying the product variant
- Define an operation restricted to a specific variant V
- Associate the operation with a workcenter with:
- Non-null cost per hour (e.g. 100)
- Time efficiency lower than 100% (e.g. 50%)
- Go to the product page > Variants > variant V
- Click on "Compute price from BOM"
-> The result will be 100 instead of 200 in this example.
Please notice that the price is correctly computed in the BOM overview
**Cause**
Accessing the BOM triggers a `web_read` including `operation_ids`,
which requires computing `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L77
During this computation, the associated product is retrieved:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L106
But since no product is given in the context and the BOM has been created without specifying the product variant
(`bom_id.product_id` is empty), then it retrieves all the product variant associated to the BOM, which leads to
arbitrary default value that ignores work center efficiency:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L107-L111
While clicking on "Compute price from BOM":
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L33
it will ultimately needs to compute the cost:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L74
which relies on `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L131
and since no context is provided, `time_total` is already in the cache, so the default value is used.
Please notice that in BOM overview, the problem does not occur because the provided context retriggers the compute method:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L806
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L835
opw-5909570
Forward-Port-Of: odoo/odoo#248758This update corrects an issue where users with limited inventory access rights were unable to save new delivery records. The fix addresses a security restriction that prevented writing to a specific field, ensuring broader user access to the l10n_uy_edi stock flow. This improves usability for all users.
Original PR description
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld…
### Step to reproduce: - Take a user with only basic inventory user access rights - Create a new delivery, add a stock move, try to save the record #### > Access error: Failed to write firld stock.move.l10n_uy_edi_addenda_ids This flow is tested by the `test_basic_stock_flow_with_minimal_access_rights` test after installing the `l10n_uy_edi_stock` module. Cause of the issue: Since [19.0](https://github.com/odoo/odoo/commit/4a822785ca850c7ae5b21039536333276b2c61af) the read access right of the comodel is checked when writing on a many2many field. However, only the `account.group_account_invoice` does have read access on the `l10n_uy_edi.addenda` model: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/security/ir.model.access.csv#L2 This is problematic as the `l10n_uy_edi_addenda_ids` field is added to the view even for users without read access rights on the comodel: https://github.com/odoo/enterprise/blob/482b4564b3a81e914d6eead9a7b85a23b7cac3dc/l10n_uy_edi/views/account_move_views.xml#L43-L53 Even if the field is invisible it is now part of the fields checked by the onchange and the values saved by the picking `web_save`. In particular, creating a new picking from the form view and saving the record will try to write an `[]` value on the `stock.picking` `l10n_uy_edi_addenda_ids` field and trigger the access error. runbot-240937 Forward-Port-Of: odoo/enterprise#109817
This update corrects a bug where generating PIX payment QR codes would fail if company names included special characters like emojis. The fix ensures company names only contain valid characters, guaranteeing QR code validity and successful payment processing. This improves the reliability of PIX payments for Brazilian businesses.
Original PR description
When generating the QR code for PIX payment, if the company name contained incorrect characters (like emojis), the generated code was invalid and the payment could not be processed. Steps to reproduce: ------------------- * Install l10n_br and PoS * Create a PIX payment method and set it on the PoS session * Change the company name to contain an emoji (e.g. "Company emoji 😇") * Open the PoS session and try to pay with PIX > Observation: If you try to verify the generated QR code, it will be invalid Why the fix: ------------ We apply the same regex as defined here: https://github.com/odoo/odoo/blob/72654c3596660e3ec4b6885c5b957739465de097/addons/l10n_br/models/res_partner_bank.py#L81 To make sure the company name only contains valid characters, and the generated QR code is correct. This also modify the other tests because it removes the `_` that is not an allowed character. opw-5907530 Forward-Port-Of: odoo/odoo#250917
This update fixes an issue where PDF thumbnails weren't generating correctly for certain invoice types, specifically XML invoices created through Peppol. The change ensures that embedded PDFs within these invoices are now properly processed, leading to accurate thumbnail generation.
Original PR description
The pdf_first_page route failed when called on non-PDF attachments that contain an embedded PDF (e.g. XML invoices generated via Peppol). This fix makes the route correctly extract and process the embedded PDF, allowing proper thumbnail generation in those cases. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236864
This update fixes a problem where XML invoices received through Peppol didn't show thumbnails. The preview page has been simplified to remove unnecessary elements, and now correctly generates thumbnails for these invoices. This ensures users can easily view the invoices received via Peppol.
Original PR description
Before this commit: - The preview page of XML invoices received via Peppol was split into two parts: one showing the PDF preview, and another showing the plain HTML of the PDF viewer page - Thumbnail were not generated for these XML invoices After the commit: - The second part of the preview (Text part) was removed. As the users won't be interested to see the raw XML content of the invoice, neither the plain HTML of the pdf preview page. - Thumbnails now are correctly generated for the XML invoices. Notes: This fix is part of the bug-fix task to ensure users can correctly open XML invoices received via Peppol. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#100137
This update fixes a server error that occurred when merging tables in the restaurant POS system. The issue was caused by a delay in syncing order data during the merge process. The fix ensures the system waits for order synchronization before completing the merge, improving stability and preventing errors.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs during table merge Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related: https://github.com/odoo/enterprise/pull/104577 Forward-Port-Of: odoo/odoo#245162
This update fixes a server error that occurred when merging tables in the Point of Sale system, specifically when a table was empty or had an incomplete order. The fix ensures the system waits for order synchronization before merging, preventing the error and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#104577
This update fixes an issue where social media posts for blog posts and events were displaying broken images. The change corrects how the system retrieves cover images, ensuring consistent and accurate image display across social media platforms. This improves the visual presentation of content on social media.
Original PR description
Scenario:
- set cover image of a blog post
- post blog post on social media (or check og:image/twitter:image tags)
Result: the social media is a dead image like:
http://site/blog/1/"/web/image/3198-3915f222/cover%20image.webp"
Cause: the code setting social image expected it to be in the
cover_properties background-image in url('{image}') or url({image})
format, but since 1b0852948c070d4d936bd00b3dd1c0e5501a1300 the format is
url("{image}") so it was gotten incorrectly.
Fix: also strip doubles quote and have the code working with
cover_properties background image with:
- no quote: for cover_properties before 18.4
- single quote: not sure in what situation this can happen
- double quote: for cover_properties since 18.4
opw-5471804
Forward-Port-Of: odoo/odoo#252028This update resolves an issue where purchase orders created with the Dropshipping route were missing the required 'Dropship Address' field, preventing order confirmation. The fix ensures that this field is automatically populated when setting the delivery type to 'Dropship', allowing users to complete the purchase process smoothly.
Original PR description
## Issue When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address*…
## Issue
When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address* (`purchase.order.dest_address_id`). It is problematic because that field is both readonly and required to confirm the order.
## Steps to reproduce
1. Install *Stock* (`stock`), *Purchase* (`purchase`) and *Sales* (`sale_management`)
2. In Settings, enable *Dropshipping* and *Replenish on Order (MTO)*
3. Create a Product P
- Set a vendor in the Purchase tab
- Enable the *Buy*, *Dropship* and *Replenish on Order (MTO)* routes
4. Create a Sales Order
- Any Customer
- Product P
- Confirm the Sales Order
5. Click on the *Purchase* smart button
6. Set the *Delivery To* (`purchase.order.picking_type_id`) field to *"Dropship"*
7. **The _Dropship Address_ (`purchase.order.dest_address_id`) field appears, but it's empty and readonly. The purchase order cannot be confirmed, as the field is required and cannot be updated.**
## Cause
When confirming a Sales Order, the created Purchase Order has a `dest_addres_id` set by `StockRule._prepare_purchase_order`:
https://github.com/odoo/odoo/blob/19.0/addons/purchase_stock/models/stock_rule.py#L350
At that point, the `picking_type_id` of the PO is set to `"Receipts"`, which `default_location_dest_id` is the user's Stock, and the `usage` of that location is set to `"internal"`. When `_compute_dest_address_id` is triggered, it starts by calling the method in `sale_purchase`:
https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/sale_purchase/models/purchase_order.py#L25-L30
Which calls the one in `purchase_stock`:
https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/purchase_stock/models/purchase_order.py#L80-L82
Which sets the `dest_address_id` to `False`. This impacts the rest of first `_compute_dest_address_id`, as the PO does not have a `dest_address_id` anymore, its value will never be updated by the `_compute_dest_address_id` methods.
## Fix
The `dest_address_id` should only be set when dropshipping. The easiest way to do so is to override the `_compute_dest_address_id` in the `stock_dropshipping` module by following a similar logic as in `sale_purchase`:
https://github.com/odoo/odoo/blob/7a39185f83d0daca207c8007512f4700537c7e88/addons/sale_purchase/models/purchase_order.py#L25-L30
opw-5426322
Forward-Port-Of: odoo/odoo#245284This update fixes a bug where the website's industry selection didn't correctly match user input due to case sensitivity. The fix adds a case-insensitive flag to the matching process and simplifies the synonym matching logic by removing unnecessary space splitting. This ensures accurate industry suggestions for users.
Original PR description
The industry highlighting to indicate what the user wrote match with the proposed industries was case sensitive, so the capital letters were not indicated as matching with lowercase letters. Fix: Added the flag "i" at the end of the regex to make it case-insensitive Also, in the case of the synonyms, the regex used was spliting on ",", "|" and space. The space spliting made matching a synonym sentence much more complicated. Fix: Deleted the space in the regex task-5066428 Forward-Port-Of: odoo/odoo#252447
This update fixes a potential error in Odoo's HTML Builder component. When asynchronous operations complete, the system now gracefully handles situations where the original context (like a user interface element) is no longer available, preventing errors and improving overall stability.
Original PR description
[FIX] html_builder: make async useDomState robust to destroyed context Option components may define an asynchronous `useDomState`. When the asynchronous part of the callback resolves, the execution context may no longer be valid. For example, the editing element, iframe, or even the component itself may have been destroyed in the meantime. This change ensures that async `useDomState` handlers safely abort when their context is no longer available, preventing unnecessary errors from being thrown. task-6003213 Forward-Port-Of: odoo/odoo#251931
This update resolves an issue preventing the activation of Point of Sale (POS) configurations when a POS session was already open. Previously, a session had to be closed before a new configuration could be applied. This change ensures smoother POS configuration management and avoids disruptions for users.
Original PR description
Before this commit, it was not possible to activate a pos.config if there was an open session linked to it. This was a problem because it is only possible to close the session when the pos.config is active, and it was not possible to activate. opw-5964181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250591
4 changes
Resolved issues and error corrections
This update resolves conflicts in transaction states related to Fiskaly processing in the German POS system. By isolating transactions to specific terminals and intelligently handling errors, the system now correctly manages transaction states, preventing data inconsistencies and ensuring accurate financial reporting. This improves the reliability of the POS system for our German customers.
Original PR description
Changes:
- cancelActiveTransactions: use the TSS-scoped endpoint
/tss/{tss_id}/tx and filter results by client_id so only orphaned
transactions from this terminal are cancelled, never those from
other POS sessions sharing the same TSS
- transactionCall: on non-retryable errors (400 revision conflict or
terminal state mismatch), call _handleTransactionStateConflict which
GETs the actual transaction state and recovers:
- Cancelling already CANCELLED → silent success
- Finishing already FINISHED → return existing tx data
- Finishing a CANCELLED tx → create a fresh transaction and finish it
- handleFiskalyCancellation: correctly reset transactionState to
inactive on the uiState after cancellation
opw-5972708
Forward-Port-Of: odoo/enterprise#109996This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product prices (starting with '23'). The fix mirrors the functionality in the Point of Sale app, ensuring accurate product recognition for these common barcode formats. This improves the reliability of inventory management.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#110034 Forward-Port-Of: odoo/enterprise#109627
A test was failing due to an issue with how the system handles time zones. The fix corrects a calculation error that resulted in an incorrect date being generated, specifically when the system's time zone is set differently from the test environment. This ensures the test consistently passes.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891 Forward-Port-Of: odoo/enterprise#110126
This update fixes an issue where bank statement reconciliation in foreign currency journals incorrectly converted amounts. When reconciling batch payments, the system now uses the correct payment currency, ensuring accurate balance calculations and reporting. This improves the reliability of financial reconciliation processes.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218 Forward-Port-Of: odoo/enterprise#108745
17 changes
Enhancements to existing features
This change optimizes the process of generating GST reports by streamlining the database query. Specifically, it removes a complex domain filter that caused performance issues with large datasets, resulting in faster report generation times. This improvement focuses on efficiency and scalability for handling substantial amounts of financial data.
Original PR description
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this ``` SELECT account_move.id FROM account_move WHERE (…
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this
```
SELECT
account_move.id
FROM
account_move
WHERE
(
account_move.l10n_in_gst_return_period_id = 23
OR (
account_move.move_type IN ('in_invoice', 'in_refund')
AND account_move.invoice_date >= '2025-11-01'
AND account_move.invoice_date <= '2025-11-30'
AND account_move.company_id IN (1)
AND account_move.state = 'posted'
AND (
account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
OR account_move.l10n_in_gst_treatment IS NULL
)
AND account_move.id IN (
SELECT
account_move_line.move_id
FROM
account_move_line
WHERE
EXISTS (
SELECT 1
FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
)
)
)
)
ORDER BY
account_move.date DESC,
account_move.name DESC,
account_move.invoice_date DESC,
account_move.id DESC
```
See this EXPLAIN for big database
```
Gather Merge (cost=165759176482.82..2983665158687.50 rows=36 width=30)
Workers Planned: 2
-> Incremental Sort (cost=165759175482.80..2983665157683.32 rows=18 width=30)
Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
Presorted Key: account_move.date
-> Parallel Index Scan Backward using account_move__date_index on account_move (cost=59.28..2983665157682.51 rows=18 width=30)
Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
SubPlan 1
-> Materialize (cost=58.84..1601427.18 rows=4994548 width=4)
-> Merge Semi Join (cost=58.84..1556944.44 rows=4994548 width=4)
Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.44..1339780.32 rows=26611459 width=8)
-> Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster
Forward-Port-Of: odoo/enterprise#109795Resolved issues and error corrections
This update ensures accurate sub-line total calculations in the stock barcode module, which now requires the 'stock.group_production_lot' setting to be active. Without this setting, the system fails to group lines correctly, leading to incorrect totals. This fix was introduced during the 18.3 forward port and resolves an issue observed in Single App and Single L10n environments.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109
This update fixes an issue where the MPS wasn't accurately reflecting demand for dependent components. Previously, the system defaulted to the oldest BoM, regardless of user-defined preferences. This change ensures that component demand is correctly calculated and updated within the MPS, improving forecasting accuracy.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738
Forward-Port-Of: odoo/enterprise#109693This update resolves conflicts in how transactions are managed for the German Point of Sale (POS) system, specifically related to Fiskaly reporting. It ensures that only transactions tied to a specific terminal are cancelled, preventing issues with shared POS systems. The changes improve reliability and accuracy of transaction state management.
Original PR description
Changes:
- cancelActiveTransactions: use the TSS-scoped endpoint
/tss/{tss_id}/tx and filter results by client_id so only orphaned
transactions from this terminal are cancelled, never those from
other POS sessions sharing the same TSS
- transactionCall: on non-retryable errors (400 revision conflict or
terminal state mismatch), call _handleTransactionStateConflict which
GETs the actual transaction state and recovers:
- Cancelling already CANCELLED → silent success
- Finishing already FINISHED → return existing tx data
- Finishing a CANCELLED tx → create a fresh transaction and finish it
- handleFiskalyCancellation: correctly reset transactionState to
inactive on the uiState after cancellation
opw-5972708
Forward-Port-Of: odoo/enterprise#109996A test was failing due to an issue with how the system handles time zones. The fix corrects a calculation error that resulted in an incorrect date being generated, specifically when the system's time zone is set differently from the test environment. This ensures the test consistently passes.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891 Forward-Port-Of: odoo/enterprise#110126
This update resolves an access error that occurred when confirming orders with gift cards in the DE company setup. The issue stemmed from a misplaced sudo() call, preventing proper access to product accounts. By correctly applying sudo() during stock valuation, the system now successfully processes gift card payments during order confirmation.
Original PR description
**Steps to reproduce:** - Install `l10n_de, website_sale and appointment` modules. - Create a website for the `DE company` and make it default. (simply place it first in the sequence.) - From…
**Steps to reproduce:** - Install `l10n_de, website_sale and appointment` modules. - Create a website for the `DE company` and make it default. (simply place it first in the sequence.) - From settings enable `Automatic Invoice` and `Discounts, Loyalty & Gift Card`. - Go to the appointment module and create a new appointment for the DE company. - In the options tab, enable `Up-front payment` and publish it. - Create a new gift card program and generate a gift card to test (should cover the entire cost of the appointment booking). - Now go to an Incognito tab, go to the appointment, and book the currently created appointment. When confirming the order, use the gift card and then confirm the order. **Issue:** - When you confirm the order, an access error occurs. **Root cause:** - Since automatic invoicing is enabled, at [1] the method `get_product_accounts` is called for the DE company. Inside this method at [2], self.sudo(False) is used, which removes the elevated access rights. As a result, the `Public product template` record rule is triggered, and because the public user cannot access the product, an AccessError is raised. - In this [commit], we can see that `sudo(False)` was added when coming from the stock flow because the stock valuation layer was being created as sudo. **Solution:** - Instead of adding `sudo(False)` in **l10n_de**, we can apply `sudo(False)` at the point where the **stock valuation layer** is created using `sudo()`. [1]https://github.com/odoo/odoo/blob/9d5d5c08f950d32bf61c2186181e8eddad9036da/addons/account/models/account_move_line.py#L603-L604 [2]https://github.com/odoo/odoo/blob/9d5d5c08f950d32bf61c2186181e8eddad9036da/addons/l10n_de/models/datev.py#L20 [commit]: https://github.com/odoo/odoo/pull/236931/changes/0919774791bb998954b870798c88843f999f2de4 opw-5483472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253131 Forward-Port-Of: odoo/odoo#246920
This update reverts a recent change that was causing unnecessary complexity in warehouse replenishment workflows. Previously, multiple pickings were automatically combined for supply chains, which now leads to a simpler process and reduces manual effort for users. This change prevents the creation of redundant pickings and streamlines operations.
Original PR description
This reverts [1]. Let's quote the commit: > - `Observation`: the next transfers for both receipts are merged into a single > transfer, even though both receipts were created manually and not generated > from any common source document like PO/SO. The above behavior was and is the expected one for years and should not suddenly change on stable. Even the tests were protecting the cases but [1] have changed the `assert`. Commit [1] quickly leads to the creation of tickets. For instance, in the mentioned OPW, where the user resupplies a warehouse from another one: he now has several pickings for the same supply chain, which lead to extra work (e.g., printing all the pickings) [1] https://github.com/odoo/odoo/commit/840b42fd2365a652e53d607f38ac78ccb8dd63dc OPW-6011532 Forward-Port-Of: odoo/odoo#253054
This change reverts a previous issue caused by a related update. It restores the initial state of quality control tests, ensuring they function correctly. This resolves a disruption to the testing process and maintains the stability of the quality control module.
Original PR description
This reverts [1]. It happens because of a revert OC side, cf linked commit. [1] a01d8f0e15de973a94c360c3911e74b768a3aebc OPW-6011532 Forward-Port-Of: odoo/enterprise#110133
This update fixes an issue where leave hours weren't being calculated correctly for time off allocations without end dates. The change adjusts the system to treat these allocations as continuous, starting from the earliest start date, ensuring accurate tracking of taken hours. This improves the reliability of leave balance reporting.
Original PR description
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after…
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after each allocation start date - Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report. ### Cause: After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery. ### Fix: Following the same approach we use in if the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date opw-5474596 Forward-Port-Of: odoo/odoo#251704 Forward-Port-Of: odoo/odoo#250432
This update fixes an issue where product availability emails were sending images at full size, resulting in large email attachments. The change ensures images are appropriately sized for these emails, improving email performance and reducing storage needs. This enhancement impacts the user experience by delivering more efficient and manageable email notifications.
Original PR description
Steps to reproduce in local: 1. Install `website_sale_stock` 2. Make a product variant with an image 3. To make it easy set field `Back in stock Notifications`'s value on this product with the help…
Steps to reproduce in local:
1. Install `website_sale_stock`
2. Make a product variant with an image
3. To make it easy set field `Back in stock Notifications`'s value on this product with the help of the studio
4. Add a person to receive notification in this field
5. Don't set Outgoing email server
6. Run cron `Product: send email regarding products availability` manually
7. To Check sent email go to `Setting > Technical > Email > Emails`
Issue:
- The image is a full-size image
<table>
<tr>
<th style="text-align: center;">Before</th>
<th style="text-align: center;">After</th>
</tr>
<tr>
<td style="text-align: center;">
<img width="1395" height="728" alt="Before"
src="https://github.com/user-attachments/assets/a3fe3b38-c4a5-4a78-a63a-552c96cfdf84" />
</td>
<td style="text-align: center;">
<img width="1383" height="662" alt="After"
src="https://github.com/user-attachments/assets/8c346302-4295-44f2-8172-6a01072b23c7" />
</td>
</tr>
</table>
opw-5915587
Forward-Port-Of: odoo/odoo#249000A bug was causing accrual leave calculations to be delayed by one month. This update corrects a logic error in the system that was incorrectly applying carry-over dates, resulting in missed accruals. This ensures employees receive the correct accrual amounts as intended.
Original PR description
steps to reproduce: ------------------- 1. Install Time Off 2. Go to Configuration > Accrual Plans 3. Create an accrual plan: * Set the accrued gain time to "At the start of the accrual period" * Set…
steps to reproduce: ------------------- 1. Install Time Off 2. Go to Configuration > Accrual Plans 3. Create an accrual plan: * Set the accrued gain time to "At the start of the accrual period" * Set the carry-over time to "At the start of the year" 4. Create a milestone: * Set the number of accrued days to 1 * Set the accrual frequency to "monthly" and the carry over to "None.Accrued time reset to 0" 5. Go to Management > Allocations 6. Create an allocation: * Set the start date to 2025-01-01 * Set the accrual plan to the one created above 7. Use future allocations to check accruals current behavior: ----------------- - On 2026-01-01 --> accrued days = 1 (correct) - On 2026-02-01 --> accrued days = 1 (should be 2) - On 2026-03-01 --> accrued days = 2 (delayed accrual, off by one month) cause of the issue: ------------------- Commit 30c7011 introduced a condition that accrues time off on the carry over date: https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/hr_holidays/models/hr_leave_allocation.py#L559 This incorrectly evaluates accruals across the carry over period instead of restricting to the current month, causing February accruals to be skipped. **Reason February accruals are skipped:** https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L559-L561 https://github.com/odoo/odoo/blob/dcb072f675c5630327d27d785b86e1ec8e2d442d/addons/hr_holidays/models/hr_leave_allocation.py#L541-L544 * After January, the last_executed_carryover_date is set to 2026-01-01. * Therefore, February uses last_executed_carryover_date = 2026-01-01. * The condition evaluates as true for February: ```python3 last_executed_carryover_date <= allocation.nextcall <= carryover_period_end 2026-01-01 <= 2026-02-01 <= 2026-02-01 ``` As a result, the February accrual is skipped. **Why it works correctly in March:** * After February, the last_executed_carryover_date is updated to 2027-01-01. * March now uses this updated date: ```python3 last_executed_carryover_date <= allocation.nextcall <= carryover_period_end 2027-01-01 <= 2026-03-01 <= 2027-02-01 ``` The condition is not satisfied, so accruals are processed correctly. solution: ---------- Add a condition to check if the loop has already run for the current carryover period. This ensures the system avoids applying the carryover twice, allowing subsequent accruals to process as expected. opw-5020834 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253153 Forward-Port-Of: odoo/odoo#227646
This update corrects a validation error that occurred when sending invoices to Peppol. The system previously incorrectly converted 'qt (US)' to 'QT', which is no longer a valid unit code according to UN/ECE standards. This fix ensures invoices comply with international regulations and avoids rejection during electronic data exchange.
Original PR description
Currently, the Odoo UoM 'qt (US)' is converted to 'QT', which is not valid anymore. Based on investigation, this was originally set to QT following this link: https://unece.org/fileadmin/DAM/cefact/recommendations/rec20/rec20_rev3_Annex2e.pdf But this document seems dated from 2005. Step to reproduce: - Create an invoice with a line with 'qt (US)' as UoM - Try to send the invoice to Peppol - You will get a validation error: "[BR-CL-23]-Unit code MUST be coded according to the UN/ECE Recommendation 20 with Rec 21" Also removed the link to unece.org since the link is no longer valid. opw-5961476 Forward-Port-Of: odoo/odoo#252803 Forward-Port-Of: odoo/odoo#252174
This update fixes an issue where customers could inadvertently set subscription start dates to 'false,' resulting in incorrect invoicing. The change prevents users from removing the start date, ensuring subscriptions are properly tracked and billed accurately. This resolves a potential revenue discrepancy.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update fixes a potential error in how Odoo fetches Instagram poll IDs. Previously, the system would sometimes receive an error from Instagram when trying to retrieve the ID before the poll was fully published. Now, Odoo waits for the poll to be published before requesting the ID, preventing errors and ensuring reliable poll functionality. This improves the overall stability of Instagram integration.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094
A bug preventing users from copying their two-factor authentication codes through the portal has been resolved. The update corrected a technical issue related to how the 'Copy' button was configured, ensuring users can now reliably access and copy their security codes. This improves the security and usability of the Odoo portal.
Original PR description
__Problem__ Since odoo/odoo@e3da5f1 the onclick listener set on `copyButton` is lost because we give the HTML of the body as argument at the dialog creation. __Steps to reproduce__ 1. Go to `/my/security` 2. Click on "Enable two-factor authentication" 3. Confirm password 4. Click on "Cannot scan it?" 5. The "Copy" button doesn't work __Fix__ - Inherit from `InputConfirmationDialog` to add a listener to the button. - At the same time, remove the remaining jQuery dependency in this part of the code Forward-Port-Of: odoo/odoo#253314 Forward-Port-Of: odoo/odoo#251429
This update fixes a bug where excessive warnings were being generated due to how Odoo uses the Werkzeug library. The fix ensures warnings are properly deduplicated, preventing continuous, unintended warning messages. This resolves a problem exacerbated by workers in the system.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252427 Forward-Port-Of: odoo/odoo#252193
This update resolves an issue where the Nemhandel XML format for Danish tax reporting was missing a crucial identifier. Specifically, the `schemeID` attribute was added to correctly identify the buyer as 'DK:CVR', ensuring compliance with OIOUBL 2.1 standards. This ensures accurate data transmission for tax purposes.
Original PR description
Nemhandel follows the OIOUBL 2.1 XML format. To specify the Buyer identifier, we use the <cac:PartyIdentification> node. But we are missing the `schemeID` attribute, which should be for DK "DK:CVR". This commit adds this attribute. opw-5232123 Forward-Port-Of: odoo/odoo#253132 Forward-Port-Of: odoo/odoo#250942
2 changes
Resolved issues and error corrections
A test was failing due to an issue with how the system handles time zones. The fix corrects a calculation error that resulted in an incorrect date being generated, ensuring the test now consistently passes. This ensures the planning module functions correctly across different time zone settings.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891 Forward-Port-Of: odoo/enterprise#110126
This update reverts a previous change that disrupted the initial state of quality control tests. The change was caused by a related fix in another part of the system. This ensures that quality control tests are functioning correctly, maintaining data integrity.
Original PR description
This reverts [1]. It happens because of a revert OC side, cf linked commit. [1] a01d8f0e15de973a94c360c3911e74b768a3aebc OPW-6011532 Forward-Port-Of: odoo/enterprise#110133
8 changes
New functionality added to Odoo
This update introduces a new report specifically designed to track outstanding payments to Micro, Small, and Medium Enterprises (MSMEs). The report includes fields for MSME type and number within partner records and company settings, allowing for more targeted debt analysis. The PDF export now also incorporates MSME information for registered companies.
Original PR description
In this PR: - Added MSME Type and Number fields to the res_partner model and displayed them in the form view. - Added related MSME fields in res_company via partner_id and displayed them in Settings under the Indian Integration section. - Added Aged Payable MSME report variant to track dues to MSME partners, with filtering by MSME Type and a default aging interval of 45 days. - PDF export of the MSME report shows company MSME info in the header if the company is MSME registered. task-4140405
Enhancements to existing features
This update adjusts the default height settings for appointment snippets. Previously, a 50% height option was offered, which users rarely utilized. The change now defaults to 75% height, providing a more intuitive and visually appealing experience for visitors while ensuring sufficient content is always visible.
Original PR description
Users rarely want to define a 50% height, either they want Auto, or 100% or something that's close enough to show the visitor there's still content below the snippet. We replace all occurrences of 50% height snippets with 3/4 height, except for the cover (e.g. Blog Cover) as I don't find replacing Half Screen Size with 75% Size useful there. task-5921163
This update enhances the search capabilities within pay runs, allowing users to filter by pay structure and employee name in addition to existing date ranges. The changes include a new user interface tour to demonstrate the improved search process, ensuring easier and more accurate pay run identification. This improves payroll efficiency and reporting.
Original PR description
Default search is extended with the month name of date_start and date_end + year of date_start and date_end. Other searches are added for structure name and employee's name task - 5925528
This pull request focuses on cleaning and streamlining the tracking code across several Odoo modules. The changes enhance code readability and maintainability, which will contribute to more reliable and efficient tracking of key business processes. This is an internal improvement to ensure long-term stability.
Original PR description
Task-
Resolved issues and error corrections
This update corrects a display issue in WhatsApp signature requests. Previously, the Certificate of Completion showed 'Email Verification' instead of the correct information for WhatsApp participants. This change ensures accurate and consistent reporting for all signature requests, regardless of the channel used.
Original PR description
When a signature request is sent via WhatsApp (`send_channel == 'whatsapp'`), the Certificate of Completion PDF currently still displays "Email Verification" in the participants table and the legal footnote.
This update resolves an issue where orders weren't generating invoices correctly due to data serialization during the tour process. The change adds a required step to ensure the invoice is selected before order validation, guaranteeing invoices are properly created. This improves order processing reliability.
Original PR description
pos*: l10n_ec_edi_pos, l10n_it_pos When invoice selection takes longer, and the order validation button is clicked immediately after, the tour may serialize data before the invoice field has settled. This can cause invoice generation to be skipped during order validation Since the delay between tour steps was removed, this commit adds an explicit step to ensure the invoice is selected before validating the order. Task-5897375 Err-237600, 238502, 238503, 238504 Related-https://github.com/odoo/odoo/pull/247770 Forward-Port-Of: odoo/enterprise#106863
This update resolves a bug where the Documents Activity view became unusable after exiting Studio, preventing users from filtering or adding new activities. The fix ensures the view correctly loads necessary data, maintaining functionality and preventing frustrating user experiences.
Original PR description
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch…
Problem: When returning to the Documents Activity view after closing Studio, the view becomes unusable with an error that `folderId` is `undefined`. Users are forced to refresh the page or switch views to fix it. Specifically: - Filters can no longer be selected. - Adding new activities throws UI errors (even if technically successful). Cause: The `getSelectedFolder` method returned undefined because the `searchPanel` logic was skipped. The Activity view does not display the `searchPanel`, so the model failed to run `_fetchSections` which retrieves the data used by `getSelectedFolder`. Under normal circumstances, the view relies on data already loaded by the Kanban or List views, but that data is unavailable here. Solution: - Force the search model to load the data explicitly, ensuring the view initializes correctly regardless of the `searchPanel` visibility. We kept the dependency upon `_fetchSections` rather than removing it, as it is required by the `search_model` to maintain other features like `breadcrumbs`. - Add a test to verify the fix and prevent regression. Co-authored-by: Pierre-Yves Dufays pydu@odoo.com Co-authored-by: Charlier Florian flch@odoo.com
This update corrects a minor CSS error that was causing incorrect styling within the timesheet grid component. The fix ensures the grid displays correctly, improving the overall user experience. This was a routine maintenance update.
Original PR description
This commit fixes the generation of the `display` CSS rules.
Before:
```scss
//...
.aw_nca_step_1 .aw_nca_d-block_from_step_1 {
display: "block";
}
//...
.aw_nca_step_1 .aw_nca_d-inline-flex_from_step_1 {
display: "inline-flex";
}
```
After:
```scss
//...
.aw_nca_step_1 .aw_nca_d-block_from_step_1 {
display: block;
}
//...
.aw_nca_step_1 .aw_nca_d-inline-flex_from_step_1 {
display: inline-flex;
}
```
Doc:
> In Sass, elements in lists can be separated by commas (Helvetica, Arial, sans-serif), spaces (10px 15px 0 0), or slashes as long as it’s consistent within the list.
https://sass-lang.com/documentation/values/lists/
Forward-Port-Of: odoo/enterprise#1102464 changes
New functionality added to Odoo
This update introduces a new report to track outstanding payments to MSME vendors, improving financial compliance. It includes an MSME-specific XLSX export and a new 'MSME Report' variant within the aged payable reports. This enhances visibility and reporting for MSME vendor relationships.
Original PR description
- Provides a report for monitoring payment dues to MSME registered vendors. - Adds MSME-related XLSX export. - Adds a new aged payable report variant 'MSME Report'. Comm PR: https://github.com/odoo/odoo/pull/226297 task-4140405
Resolved issues and error corrections
This update resolves intermittent test failures in the sign functionality by using dedicated test users instead of the default 'admin' and 'demo' accounts. This ensures consistent and reliable test results, improving the overall stability of the sign process. The change focuses on deterministic test execution.
Original PR description
Relying on the default `admin` and `demo` users caused random runbot failures, as their access rights can be altered by other modules. This commit replaces them with freshly created test users to strictly simulate the presence or absence of the `sign.group_sign_user` group, ensuring the test remains deterministic. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/241216
This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product pricing (price-embedded). The fix mirrors the functionality in the Point of Sale app, ensuring accurate product recognition for these common barcode formats. This improves the reliability of inventory management.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#110034 Forward-Port-Of: odoo/enterprise#109627
A test was failing due to an issue with how the system handles time zones. The fix corrects a calculation error that resulted in an incorrect date being generated, specifically when the system's time zone is set differently from the test environment. This ensures the test consistently passes.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891 Forward-Port-Of: odoo/enterprise#110126
10 changes
New functionality added to Odoo
This update adds support for triangular taxes to the tax reporting system. This is necessary to accurately generate the EC Sales List report, ensuring compliance with Finnish tax regulations. The changes improve the accuracy of tax reporting for Finnish businesses using Odoo.
Original PR description
The aim of this commit is adding the triangular taxes into the tax report to use it in EC Sales List report. task-4010767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update removes unnecessary code that subtracted the current production order from a list of related orders. The existing filtering logic already effectively achieved the same result, ensuring cleaner and more efficient code. This change improves code readability and maintainability without impacting functionality.
Original PR description
`- self` is redundant given there's already `.filtered(lambda p: p.origin !=self.origin)`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update refines how analytic accounts are assigned within Odoo. Specifically, the order of fields related to analytic distribution has been adjusted for better organization and usability. This change improves the clarity and efficiency of managing analytic accounting data.
Original PR description
Reordering the analytic distribution field. task-5887978 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves a technical issue that caused tracebacks when using the pivot table autofill feature. The fix corrects a misidentification of the function being called, ensuring consistent behavior with vertical autofills. While the core result isn't corrected, this resolves a reporting error.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#109620
This update corrects a warning message appearing during tax report adjustments in the French localization. The issue stemmed from an unnecessary reference to 'box_B1' within the report's calculations. Removing this element ensures the report functions correctly without displaying the misleading warning, improving the user experience for French accounting users.
Original PR description
Steps to reproduce: 1- Install Accounting and l10n_fr and switch to French company 2- Go to [Settings > Accounting] and make sure fiscal localization is set to France 3. Go to [Accounting > Reporting > Tax return] and change the Report to Tax Report (FR) 4. Make an adjustment to the B1 field Description of issue: Warning message displayed where the text does not mention B1 Expected behavior: No warning message should be displayed when editing B1 Why this happens: 'box_B1' is used in the the expression total comparison when it should not be opw-5960001
This update resolves an issue where clicking on 'reply' links within Odoo mailboxes didn't function correctly. Now, clicking on a reply link will automatically jump to the original thread of the message, improving the user experience and ensuring messages are easily accessible within conversations. This fix enhances the efficiency of email management within Odoo.
Original PR description
Before this change, clicking on a `message in reply` in mailboxes had no effect. The expected behavior is for it to jump to the message in its origin thread. To fix it, this commit ensures that `useMessageHighlight` hook receives the correct thread which in this case is the origin thread of the message in reply. task-5343804
This update resolves a technical issue that caused the bulk payments feature to crash when attempting to check the status of a batch without a linked bank account. A new user message will now alert users if the required bank journal is not connected, preventing the error and improving the user experience.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083
This update resolves an issue where tax calculations were incorrect during the reconciliation process, particularly when dealing with reverse charges. The fix ensures accurate tax amounts are applied to journal entries, improving financial reporting accuracy. This impacts users utilizing the reconciliation features within the Enterprise accounting module.
Original PR description
## ISSUE 1: **Steps to reproduce [l10n_be easier]:** - Create a journal entry: ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in…
## ISSUE 1: **Steps to reproduce [l10n_be easier]:** - Create a journal entry: ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 12% (purchase) - Validate - Check the last entry created **Issue:** There is no invert tag set on the tax line **Cause:** The tax repartition line was not propagated in the rec wizard, therefore in https://github.com/odoo/odoo/blob/a456d9c7cbdf17edb5db2c73306b62150e46a7a7/addons/account/models/account_move_line.py#L814-L815 The line was never set to properly (same of is_refund) ## ISSUE2: **Steps to reproduce:** - create a journal entry ``` 440 : supplier 0 300 False 499 : suspense account 300 0 False ``` - Accounting > Reconcile: select the entry and in the wizard > account 600 tax 21% EU M (Purchases) - Validate - Check the last entry created **Issue:** No issue in 17.0. But we added the test to cover the flow. A fix for this issue will be applied as of 18.0. opw-4976780 ## ISSUE3: **Steps to reproduce:** - Create a Statement line of 1000$ - In the Writeoff add 2.5% RC tax - Check created tax lines **Issue:** Adding a 2.5% RC tax gives 24.39 instead of 25.00 opw-5039386 Forward-Port-Of: odoo/enterprise#92556
This update fixes an issue where overtime calculations were inaccurate after a leave request was validated. Now, overtimes are automatically recalculated whenever a leave request is created, updated, or removed, ensuring accurate overtime reporting. This prevents overtimes from being miscalculated due to leave validation changes.
Original PR description
When we re-evaluate leaves we update overtimes after switching to draft but we do not update the overtimes again after the leave is switched back to validated. This causes the overtimes from attendances that overlap with the leave to be miscalculated as if the leave was not validated. To rectify this issue, we recalculate the overtimes for the affected employees after every create/write/unlink of `resource.calendar.leaves`. opw-4844447 Forward-Port-Of: odoo/odoo#229723
This update fixes an issue where returning products previously transferred to sub-locations wouldn't reserve them correctly. The fix adjusts the system's search strategy to properly account for sub-locations, ensuring returns can now be processed from any location within the stock hierarchy. This improves the efficiency of the returns process.
Original PR description
Issue ----- Returning products doesn't work if they were transferred to a sub location. Steps to reproduce ----- - Enable storage locations - Create a new sub location to WH/Stock (eg WH/Stock/Shelf) - Receive a product in WH/Stock & confirm - Transfer the product to WH/Stock/Shelf - Go to the reception transfer and return it > The return cannot reserve the product from WH/Stock/Shelf Cause ----- The problem was introduced by 13567aa. https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/stock/models/stock_move.py#L1966 The strategy used to find available quants is set as strict, so the domain contains an exact match for the location instead of `child_of` which would include sub locations. https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/stock/models/stock_quant.py#L770-L787 ----- Ticket: opw-5364331
4 changes
New functionality added to Odoo
This update enables Danish companies to automatically generate official FIK payment references on customer invoices through their sales journals. Users simply configure their bank's FIK creditor number, ensuring compliant Danish FIK payments without disrupting existing workflows. This improves financial reporting and reduces manual effort for Danish customers.
Original PR description
Before: - Danish companies had to rely on manual or non-standard payment communication on invoices. - They could not generate official FIK payment references. After: - Sales journals can now generate Danish FIK payment references automatically. - Users configure an 8-digit bank-issued FIK creditor number on sales journal. Impact: - Enables compliant Danish FIK payments without changing user workflows. Related PR: https://github.com/odoo/enterprise/pull/102612 taskID-5401553
Resolved issues and error corrections
This update ensures that changes to stock move quantities, such as adding lot names, are correctly saved and reflected in the system. Previously, this functionality was missing, leading to data inconsistencies. This fix restores a key feature for accurate stock tracking.
Original PR description
This commit make use of `_action_assign()` to populate extra stock move lines when increasing the quantity of a stock move. This feature was available in v16 but lost from https://github.com/odoo-dev/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81. Also back-port https://github.com/odoo/odoo/commit/bf4bdbe775f8f49b2aaac069fc65bc03593b95df to make sure any change on `quantity` on stock move will trigger a `save` to update the stock move line accordingly at the openning of the detailed operations Task : 4308181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures Odoo correctly includes Danish FIK references in SEPA payment XMLs, aligning with local regulations. The change improves the accuracy of payment communications and makes the system more adaptable to future country-specific requirements. This ensures compliant Danish SEPA payments.
Original PR description
Issue: - A related PR introduced Danish FIK payment references on customer invoices. - The generated SEPA payment XML did not include this reference, resulting in missing structured communication for Danish payments. IMP: - Extended the SEPA payment XML generation to include the Danish FIK reference when present. - Refactored the structured reference XML builder to use lxml elements instead of string-based XML construction, ensuring proper escaping of structured references. Impact: - Ensures compliant Danish SEPA payments with correct FIK references. - Makes SEPA XML generation future-proof for country-specific structured references containing non-numeric characters. Related PR: https://github.com/odoo/odoo/pull/240829 Task: 5401553
Documentation and clarification updates
This pull request updates the Therp company CLA to reflect current employee contributions. Previously, the CLA contained outdated information. After this change, the CLA will accurately represent all Therp company contributors, ensuring legal compliance.
Original PR description
Description of the issue/feature this PR addresses: It makes our company CLA up to date with the reality Current behavior before PR: Our company CLA had some old employees in it, and didn't have some new ones Desired behavior after PR is merged: Our company CLA is up to date --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr