Odoo Changelog — 2026-09-07

Monday, September 7, 2026

72 changes · master

New Features(1)

New functionality added to Odoo

[ADD] l10n_tr_nilvera_einvoice: invoice sequences per journal

Coremasterl10n_tr_nilvera_einvoiceMedium

Companies using Turkish Nilvera e-invoicing can now define multiple invoice series on a single journal and apply them based on customer, invoice scenario, invoice type, exports, or credit notes. This reduces unnecessary journal setup while keeping invoice numbering aligned with different business processes.

Original PR description

In Türkiye, companies commonly use a different invoice series for each business process: invoice type, branch, or customer.

A journal carries a single sequence, so getting a second series means creating a second journal purely to renumber, which inflates the configuration for no accounting reason.

This commit adds an "e-Document Sequences" list on the journal. Each line pairs a series code with the invoice characteristics it applies to: customer, GİB scenario, GİB invoice type, product export invoice and credit note. When an invoice matches every condition of a line, the series code is used instead of the journal's code.

task-6316156

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

#Türkiye#e-invoicing#invoice numbering#journals

Improvements(41)

Enhancements to existing features

[IMP] hr_payroll: improve timeoff correction flow

PR #285984

Coremasterhr_holidaysl10n_fr_hr_holidaysMedium

Employees and payroll users now see a warning on time off records that points them to the payslip needing correction. This helps payroll teams resolve time off adjustments more directly, while removing an unnecessary payslip status field from the time off view.

Original PR description

-Warning has been introduced on the timeoff form view, to redirect to the payslip to be corrected. 
-"payslip_state" has been removed from the timeoff view.

#payroll#time off#payslips#corrections

Bug Fixes(30)

Resolved issues and error corrections

[IMP] website_sale: avoid resolving the cart to render the header count

PR #285711

Coremasterwebsite_saleMedium

The website shop header now uses the already saved cart quantity when available instead of reloading the full cart each time. This avoids unintended cart resets or recovery actions while customers are browsing or completing payment, improving checkout reliability.

Original PR description

`header_cart_link` computed the badge quantity with `request.session.get('website_sale_cart_quantity', request.cart.cart_quantity)`. Python evaluates the default argument unconditionally, so every render resolved `request.cart` even when the quantity was already cached in the session. Resolving the cart runs `_get_and_cache_current_cart`, which can mutate the session (cart reset, abandoned-cart recovery) as a side effect of merely rendering the header.

Read the cached quantity directly when the session key is present, falling back to `request.cart` only when it is absent.

This is needed for https://github.com/odoo/odoo/pull/268897 to prevent the cart from being reset while waiting for the user to do the payment.

In Türkiye, companies commonly use a different invoice series for each business process: invoice type, branch, or customer. A journal carries a single sequence, so getting a second series means creating a second journal purely to renumber, which inflates the configuration for no accounting reason. This commit adds an "e-Document Sequences" list on the journal. Each line pairs a series code with the invoice characteristics it applies to: customer, GİB scenario, GİB invoice type, product export invoice and credit note. When an invoice matches every condition of a line, the series code is used instead of the journal's code. task-6316156 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

`header_cart_link` computed the badge quantity with `request.session.get('website_sale_cart_quantity', request.cart.cart_quantity)`. Python evaluates the default argument unconditionally, so every render resolved `request.cart` even when the quantity was already cached in the session. Resolving the cart runs `_get_and_cache_current_cart`, which can mutate the session (cart reset, abandoned-cart recovery) as a side effect of merely rendering the header. Read the cached quantity directly when the session key is present, falling back to `request.cart` only when it is absent. This is needed for https://github.com/odoo/odoo/pull/268897 to prevent the cart from being reset while waiting for the user to do the payment.

This PR redesigns the gift card template by improving the space utilization and adding a white background to enhance readability on dark mode. It also - slightly modifies the layout of the related PDF - increases the minimum width to provide more space for the mail preview in the chatter. task-6246180 | Before | After | |--------|--------| | <img width="616" height="779" alt="Screenshot 2026-06-25 at 10 53 22" src="https://github.com/user-attachments/assets/b7f05c43-aaaa-4f4f-ba5b-fa93f4aaaad2" /> | <img width="504" height="595" alt="Screenshot 2026-06-25 at 10 25 22" src="https://github.com/user-attachments/assets/19bca54b-923a-44d7-9c08-3901ff08a532" /> | |--------|--------| | <img width="448" height="720" alt="Screenshot 2026-06-02 at 10 43 53" src="https://github.com/user-attachments/assets/d5fed6d0-1d05-44a2-9bc8-090259a10291" /> | <img width="555" height="721" alt="Screenshot 2026-06-25 at 10 26 34" src="https://github.com/user-attachments/assets/8e26db94-d654-4d18-8e34-8bee277a9f44" /> | |--------|--------| | <img width="798" height="884" alt="Screenshot 2026-06-25 at 10 54 39" src="https://github.com/user-attachments/assets/54bf2940-988c-4754-8677-19bc980a6684" /> | <img width="790" height="856" alt="Screenshot 2026-06-25 at 10 26 52" src="https://github.com/user-attachments/assets/f2ca78d5-97f8-456d-9416-fbd2f680b013" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Time Credit Work Entries :-** . LEAVE300 (Credit Time) . LEAVE301 (Parental Time Off) . LEAVE281 (Partial Incapacity) ### Regular Pay :- **1. Wage proration for time credit** The `wage proration` applies only to the payslip calculation, not to the employee's contractual wage, the employee's full-time contractual wage remains unchanged. The wage displayed on the employee's version remains the original amount agreed in the contract, where **The proration is applied only when calculating the worked days and corresponding amounts on the payslip**. This ensures that the payslip reflects the employee's actual working time while preserving the contractual wage as the reference amount. The used range to calculate the proration ratio depends on the schedule type :- _. Fixed Calendars:_ The proration ratio is computed using a standard 1-week period (Monday to Sunday) from the attendance schedule, as fixed schedules repeat weekly. > Fixed Calendar Example (1-Week): > Schedule: 4 working days (30.4h) + 1 time credit day (7.6h) = 38h total schedule > Calculation range: 1 week > Proration ratio: $\frac{30.4\text{ actual working hours}}{38.0\text{ total schedule hours}} = 0.80$. > Contractual Wage: €5,000 (Unchanged). > Prorated Payslip Amount: $€5,000 \times 0.80 = €4,000$. _. Variable Calendars:_ The proration ratio is computed over the entire target evaluation period to accurately capture work entries, taking the full month for a monthly payslip or the full 3-quarter/3-month period for DMFA reporting. > Schedule: Alternating shifts across a monthly payslip period totaling 152 total scheduled calendar hours, of which 38 hours are marked as time credit and 114 hours are actual working hours. > Calculation range: Full calendar month (e.g., 1st to 30th/31st). > Proration ratio: $\frac{114\text{ actual working hours}}{152\text{ total schedule hours}} = 0.75$. > Contractual Wage: €5,000 (Unchanged). > Prorated Payslip Amount: $€5,000 \times 0.75 = €3,750$. Ex: If an employee has a contractual wage of €5,000 and their schedule includes time credit: Employee/contract wage: €5,000 → remains unchanged Basic wage used as the contractual reference: €5,000 → remains unchanged Payslip worked-days amount: prorated according to the actual working time This distinction is important because time credit changes the amount paid for the payroll period, but it does not change the employee's underlying contractual full-time wage. **2. Version Work Time Rate** The `work_time_rate` is computed at the employee version level, where the time-credit situation belongs to the employee's version. The existing behavior for flexible/variable calendars is preserved, **where currently the work_time_rate not computed for variable calendars and the user is expected to enter the appropriate work_time_rate manually for the variable calendars, So the overidden work_rime_rate computation deals with the `credit_time_fixed_calendars`** For fixed calendars with time credit, the computation is handled specifically for the employee version: . Only versions flagged with l10n_be_time_credit and using a fixed calendar are handled by the custom computation. . The employee's reference calendar is used to determine the full-time weekly hours. . The calculation considers both, regular working attendances & attendances marked as time credit. The time-credit hours are therefore included when determining the employee's work_time_rate, **But Importantly, the actual working hours of the resource calendar are not changed.**, where The time-credit attendances are included only for the purpose of calculating work_time_rate. They are not treated as actual working hours, and hours_per_week continues to represent the employee's effective working hours without the time-credit period. Ex: For a full-time reference calendar of 38 hours: Actual working hours: 30.4h/week Time-credit hours: 7.6h/week Hours considered for work_time_rate: 30.4 + 7.6 = 38h work_time_rate: 100% Actual working hours remain: 30.4h/week ----- ### Double Holiday :- The Double Holiday Pay calculation requires special handling for time-credit periods because two different rates need to be considered: . The **computed work_time_rate** that used to normalize the wage "include credit_entries" . The **effective/real work_time_rate** used to determine the assimilated months "not include credit_entries"" The used wage is the version wage itself that's not prorated. The calculation first uses the full contractual wage **(so no need to change the wage on the tests)** and divides it by the version's current computed work_time_rate. This is important for time-credit versions because their computed work_time_rate can include the time-credit attendances. However, when calculating the _double_holiday_assimilated_months, the time-credit periods are treated differently. The calculation uses the effective working-time rate, where regular time-credit entries are not considered as working time. The exception is `LEAVE281 (Partial Incapacity),` which is considered in the assimilated-month calculation and therefore contributes with its corresponding rate. Ex: An Employee works with wage €2,500 . January → June with Normal Schedule . July → September with 4/5 Partial Incapacity (LEAVE281) . October → December with 4/5 Credit Time (LEAVE300) The employee's version wage remains €2,500 throughout the calculation and the used work_time_rate for the wage will be the current computed work_time_rate which will be 1.0 The Double Holiday Pay calculation can therefore be represented as: €2,500 / 1.00 × [(6 × 1.0 / 12) + (3 × 1.0 / 12) + (3 × 0.8 / 12)] . For the wage normalization: the computed work_time_rate of the relevant version is used. This rate can include time-credit attendances. . For _double_holiday_assimilated_months: the calculation uses the effective/real working-time rate for each period. Regular time-credit (LEAVE300) is therefore reflected as 80%, while LEAVE281 (Partial Incapacity) is treated as an assimilated period and remains at 100% in this example. check:- ``` def _l10n_be_get_paid_double_holiday() def _compute_double_holiday_assimilated_months() ``` ----- ### Eco Voucher :- The Eco-voucher calculation depends directly on the employee version's work_time_rate. The voucher amount is therefore automatically updated when the work_time_rate changes. This is particularly important for time-credit versions, because the work_time_rate now correctly represents the employee's contractual occupation rate, including the relevant time-credit periods. This means that a time-credit version does not necessarily result in a reduced Eco-voucher entitlement. In particular, when the employee is on a reduced working schedule but the reduction is entirely due to time credit, the computed work_time_rate can remain at 100%, because the time-credit periods are included when calculating the rate. Ex: An employee is entitled to a maximum of €250 in Eco-vouchers and has the following situation during the reference period: 01/06/2020 → 31/10/2020: Full-time schedule → work_time_rate = 100% 01/11/2020 → 31/05/2021: 3/5 schedule with Tuesday and Wednesday represented as credit-time entries. Although the employee only has 22.8 actual working hours per week, the two non-working days are explicitly represented as time credit. Therefore, for the purpose of the employee version's work_time_rate, the time-credit hours are included and the rate remains 100%. The Eco-voucher calculation consequently uses: €250 × 100% = €250 110 valid working days during the full-time period, out of 261 scheduled days. 82 valid working days during the 3/5 time-credit period, out of 157 scheduled days, after excluding 9 unpaid-time-off days. Therefore: €250 × 110 / 261 + €250 × 82 / 157 = €235.94 This confirms that time credit does not incorrectly reduce the Eco-voucher amount simply because the resource calendar contains fewer actual working hours. The employee's work_time_rate correctly remains 100% when the missing hours are accounted for as time credit. check:- `def _get_eco_vouchers_amount(self, get_explanation=False): ` ----- ### Representation Fees :- The REP.FEES calculation depends directly on the employee version's work_time_rate. Therefore, for time-credit versions, the newly computed work_time_rate is automatically taken into account when determining the amount. For time-credit versions, the computed rate includes the time-credit hours. Therefore, a 4/5 schedule with one full day of time credit has a work_time_rate of 100% (the 4/5 worked hours + the 1/5 time-credit hours represent the full reference schedule). As a result, the existing representation-fee proration logic is not triggered, and the full representation-fee amount is maintained. check :- `def _get_representation_fees(self, localdict): ` ----- ### DMFA :- The DMFA declaration requires two separate considerations for time credit: **. Working days,** where the employee's days_per_week is preserved and the time-credit attendances are not considered as actual working days. This is important because the time-credit hours may be included when determining the employee's work_time_rate, but they must not be reported as worked days in the DMFA declaration, So the time credit can affect work_time_rate, but it does not create additional working days for DMFA. **. Termination contribution type,** The contribution type is determined based on the employee's yearly salary, which is accumulated from the amounts reported on the payslip worked-days lines, The resulting yearly salary is compared against the configured salary thresholds to determine the appropriate contribution type. Because the yearly salary is based on the actual amounts coming from the payslip worked-days lines, a time-credit period can reduce the yearly salary used for this calculation. As a result, the employee's contribution type can legitimately move to a lower category. check:- ``` DMFAWorkerContribution() __init__ class yearly_salary = payslips[0]._l10n_be_get_termination_yearly_salary() ``` ----- task-5126195

**Description :-** This PR adds support for declaring ONSS/DMFA quarterly CO₂ contributions for pool vehicles (vehicles owned by the employer that are not assigned to am employee on a contract, but are used during the period). According to Belgian social security (ONSS) regulations, CO₂ fees must be paid for all company vehicles used during the quarter: . Assigned Company Cars: CO₂ fees are calculated and declared directly via employee monthly payslips. . Pool Cars: Must be declared at the employer level for any month in which they had active assignment/driver logs (fleet.vehicle.assignation.log) and were not already declared on an employee payslip. **Implementation :-** . Vehicles declaration on the DMFA (_compute_vehicle_ids) Retains all active vehicles with valid license plates that have driver assignment logs during the DMFA quarter. Ensures eco-friendly and pool vehicles appear under the XML <CompanyVehicle> declaration block. . Month-by-Month Vehicles Contribution (_get_vehicles_contribution) Evaluates the DMFA quarter on a per-month basis rather than applying a static quarterly multiplier. Prevents double-counting by excluding vehicles already charged via an employee payslip for a specific month (covered_vehicle_ids). Dynamically checks driver log date overlaps (date_start and date_end) per month to properly handle mid-quarter acquisitions or transitions. Evaluates CO₂ indexation parameters historically per month by passing co2_fee_date in the context (vehicle.with_context(co2_fee_date=current_month)._get_co2_fee(...)). **Example :-** > CAR-001 (Diesel, CO₂=120): ((120 * 9 - 600) / 12) * (181.93 / 114.08) * 2.75 = 175.42 > CAR-002 (Gasoline, CO₂=100): ((100 * 9 - 768) / 12) * (181.93 / 114.08) * 2.75 = 48.24 > CAR-003 (Diesel, CO₂=110): ((110 * 9 - 600) / 12) * (181.93 / 114.08) * 2.75 = 142.53 > TEST (Class Default Car): = 33.22 > Payslips CO₂ Fees: > CAR-002 on Employee Payslips (Jan & Feb): 48.24 * 2 = 96.48 > Pool Cars Monthly CO₂ Fees (Iterating Jan, Feb, Mar): > > January: > CAR-001: 175.42 > TEST: 33.22 > Subtotal Jan: 208.64 > > February: > CAR-003: 142.53 > CAR-001: 175.42 > TEST: 33.22 > Subtotal Feb: 351.17 (Cumulative pool fees: 559.82) > > March: > CAR-003: 142.53 > CAR-001: 175.42 > CAR-002: 48.24 > TEST: 33.22 > Subtotal Mar: 399.41 (Cumulative pool fees: 959.23) > > Therefore, Total Vehicles Contribution: 96.48 (payslips) + 959.23 (pool) = 1055.71 task-6147532

**Description :-** The payroll system currently applies a minimum legal yearly BIK/ATN for company cars. So even if the employee’s theoretical calculated car benefit is lower than the legal minimum, payroll still taxes the employee on the legal minimum. That is correct as long as the employee keeps that same car all year, But if later in the same year the employee changes to a another car, with a lower or a bigger BIK, In that case, the employee may already have paid too much earlier in the year because the minimum was applied month-by-month indirectly. So, in December, or in the Month that the contract ends, must: 1. recompute the true yearly ATN 2. compare it with what was already paid 3. refund/deduct the excess if too much ATN was charged. . Add a salary rule to calculate the regularization amount in case of employee have paid too much for the car bik, which applied in December, or in the Month that the contract ends, **Implementation :-** . Min legal car ATN: this's minimum yearly ATN that need to be paid. . Yearly Theoretical ATN: This's the sum of the real BIK calculated from the car formula without applying the min legal car atn per month . Yearly ATN paid: this's the sum of ATN paid on the payslips during the year ∴ Yearly ATN to pay = MAX( Min legal car ATN, Yearly Theoretical ATN) ∴ Regularization amount = Yearly ATN to pay - Yearly ATN paid If +ve ,then employee paid less and owes more ATN **(not our case)** If -ve ,then employee paid too much and need to refund **Example :-** min_car_atn = 1,690€ / year _(in 2026)_ car1 (Volkswagen/Golf 8) from January to June: car_value = 38,000 € yearly_theoretical_atn = 1,938 €/year yearly_paid_atn = 1,938 €/year car2 (Nissan) July to December:: car_value = 20,000 € yearly_theoretical_atn = 1,371.43 €/year yearly_paid_atn = 1,690 €/year Calculations: ∵ monthly_car_atn is calculated based on the month calendar days so need to get the car covered assignment on days ∵ car1 covered_days = 181 days ∵ car2 covered_days = 184 days ∴ Yearly Theoretical ATN = 1,938 * (181 / 365) + 1,371.43 * (184 / 365) = 1,652.39 € ∴ Yearly ATN to pay = Max(min_legal_car_atn, yearly_theoretical_atn) , where it's the final ATN that should have been paid after applying the legal minimum. = Max(1,690, 1,652.37) = 1,690 € ∵ Yearly ATN paid _(payslips)_ = car1 -> (1,938/365) * (31 + 28 + 31 + 30 + 31 + 30) = 961.035616438 € car2 -> (1,690/365) * (31 + 31 + 30 + 31 + 30 + 31) = 851.945205479 € = 1,812.98 € ∴ Regularization amount = yearly_atn_to_pay - yearly_atn_paid = 1,690 - 1,812.97 = -122.97 € **∴ Need to refund 122.97 € to the employee** **Example :-** min_car_atn = 1,690€ / year _(in 2026)_ Car 1 (Corolla) Jan-Jun: Yearly Theoretical ATN = 1,748.57€ Yearly Paid ATN = 1,748.57€ Car 2 (Clio) Jul-Nov: Yearly Theoretical ATN = 1,371.43€ Yearly Paid ATN = 1,690€ >>The contract end at 30th November Calculations: ∵ monthly_car_atn is calculated based on the month calendar days so need to get the car covered assignment on days ∵ car1 covered_days = 181 days ∵ car2 covered_days = 152 days ∴ Yearly Theoretical ATN = 1,748.57 * (181 / 365) + 1,371.43 * (152 / 365) = 1,438.215 € ∵ The regularization will be applied till the contract end not the full year, so the min_legal_car_atn will be prorated ∴ min_atn_prorated = 1,690 * ((181 + 152) / 365) = 1,541.8356 € ∴ Yearly ATN to pay = Max(1,541.8356, 1,438.215) = 1,541.8356 € ∵ Yearly ATN paid (payslips) = car1 -> (1,748.57/365) * (31 + 28 + 31 + 30 + 31 + 30) = 867.11 € car2 -> (1,690/365) * (31 + 31 + 30 + 31 + 30 + 29) = 571.12 € = 1,570.87 € ∴ Regularization amount = 1,541.8356 - 1,570.87 = -29.03 € ∴ Need to refund 29.03 € back to the employee **Tests :-** . Payslip Simulation for December & Termination Tests: Updated all test cases covering December payslip computations and mid-year contract terminations (e.g., test_274_declaration_december, test_end_of_contract, test_simple_n_holiday_pay_recovery_higher_salary) to ensure that fully validated payslips exist for all preceding months of the active fiscal year, where The `ATNCARREGUL` salary rule computes regularization by inspecting historical payslips (_get_line_values / cumulative paid BIK from January up to the current month), so December or exit payslips in isolation without prior validated payslips skews the total paid BIK (atn_paid_before_current_payslip), which does not accurately reflect a real-world payroll state. check:- `def _get_holiday_pay_recovery() ` . Updated Assertions (M.ONSS): Adjusted expectations for year-to-date-dependent lines, for special ONSS contributions (M.ONSS) across these specific tests. **Because previous months' payslips are now added, processed and validated sequentially, which reflect exact real-life behavior.** check:- `def _l10n_be_get_special_social_contribution() ` . Updated 274_xx december declarations Make sure that the payslips are computed and validated **sequentially**, where all payslips from January through November is computed first then December payslips, Before M.ONSS computed for December first which leads to Zero values, that makes taxable_amount_10 & pp_amount_10 not correct, **But now payslips are now processed and validated sequentially, which reflect exact real-life behavior.** check:- `def _compute_line_ids(self): "l10n_be_274.xx" ` `def _l10n_be_get_special_social_contribution() ` ----- task-6197625

### Description: Predicting fields can be slow when the database has a large amount of move lines (AML). This is caused by the fact that `_predicted_field` will search on all these AMLs to find the ones related to the searched fields. It can be an issue when using Peppol since it is used a lot in most localizations to match each line to its product/account/tax. To speed up the queries, the move IDs have been inlined in `_build_predictive_query` to avoid suboptimal execution plans caused by LIMIT and ORDER BY clauses. Additionally, materialization of the `account_move_line` CTE has been removed so the planner can inline filters and stream rows directly, which improves performance in most use cases. ### Benchmark: **For a `history.limit`[^1] of 100:** | Nb of invoice line | Before | After | AMLs scanned | |--------------------|-----------|---------|--------------| | 33 | 7s | 4s | 232 | | 172 | 11.39min | 5min | 99859 | | 1934 | 3h+ [^2] | 1h40min | 102503 | **For a `history.limit`[^1] of 50:** | Nb of invoice line | Before | After | AMLs scanned | |--------------------|---------|---------|--------------| | 33 | 6s | 4s | 187 | | 172 | 2.52min | 1.27min | 21002 | | 1934 | 40min | 20min | 21002 | [^1]: System parameter `account.bill.predict.history.limit` [^2]: Stopped manually after 3h; full runtime not measured ### Reference: opw-5937519 Forward-Port-Of: odoo/enterprise#130242 Forward-Port-Of: odoo/enterprise#128172

Issue: Internal users assigned to a task in an "Invited internal users" project can read the task but may receive an access error when opening it. Adding them as project followers avoids the error but also exposes the project's other tasks. Steps to reproduce: - Set a project's visibility to "Invited internal users". - Assign an internal Project user to one of its tasks. - Keep the user out of the project's followers. - Open the assigned task through its access link. Cause: The task form loads feature flags whose computations read their values from the parent project. These computations run as the assignee, who can read the assigned task but not the invited-only project, causing a project access error. Additionally, the project many2one widget declares `is_template` as a related field. This makes web_read request `project_id.is_template` even though the widget uses the task's own `is_template` value. https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L277 https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/models/project_task.py#L295 https://github.com/odoo/odoo/blob/8c1e139a8ffca9e9a82e90eb4a8a03a56b4aa660/addons/project/static/src/components/project_many2one_field/project_many2one_field.js#L36-L39 Solution: We need to compute the inherited task feature flags with elevated access so their values do not depend on the assignee's access to the parent project. declare `is_template` as a dependency of the current task instead of a related field of `project_id`. The task form therefore no longer reads the inaccessible project while its access restrictions remain intact. opw-6475880 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284196

### Issue before this commit: When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal. ### Steps to reproduce the issue: 1. Download Accounting 2. Go to Currencies and activate another currency like EUR 3. Go to Journals and create a new one with bank type and curency EUR 4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal 5. Go to test bank journal and create a new bank matching 6. After the line is created click the 3 dots and go to Manage Models 7. See that the new model Tester created does not appear ### Cause of the issue: Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added. https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100 ### Reason to introduce the fix: The filter is not working correctly. In this case it's better to change it to a domain instead of a default filter. opw-6481970 Forward-Port-Of: odoo/enterprise#129992

Steps to reproduce: 1. Install Documents 2. In the Documents list view, select a document to display the inspector. 3. Edit a field such as Owner or Customer which uses a Many2one widget. 4. In the field dropdown, click "Search More..." to open a modal dialog. 5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers). Issue: - The modal dialog immediately closes, and the contact cannot be selected. Root cause: - When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack. Solution: - Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer. Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear the main selection and destroy the inspector field. opw-6253360 Forward-Port-Of: odoo/enterprise#128812 Forward-Port-Of: odoo/enterprise#119262

Version: -------- - 19.0+ Steps to reproduce: ------------------- - Install `quality_control` module - Create a picking order with a product - From the gear menu, create an on-demand Quality Check - Set the check to *Control per Quantity* and back to the picking - Set the done quantity to 10 - Open the Quality Check wizard - Try to fail 3 units Issue: ------ Validating the partial failure raises a `ValidationError`: - Missing required value for the field 'Team' (team_id) The quality check split is not performed and the picking cannot be processed. Cause: -------- Quality checks created on-demand from the picking (via the gear menu) have no associated `quality.point` or `stock.move.line` — only `picking_id` is set at creation time. https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L457 In `_move_to_failure_location()`, the `move_line` branch assumes `check.move_line_id` is populated. Since it is empty for on-demand checks, the split logic operates on an empty recordset. The new quality check for the split is then created via: https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L493 At this point both `failed_move_line` (a copy of the empty move line) and `check.point_id` are empty. `_get_check_values(False)` cannot derive fields normally sourced from the quality point (`team_id`, `company_id`, `measure_on`, `test_type_id`, etc.), causing the `ValidationError` on record creation. Fix: ---- - If the quality check is not linked to a move line, find the matching move line from the picking before splitting the failed quantity. https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/stock_move_line.py#L94-L97 - `_get_check_values()` normally takes values from a Quality Point. Since on-demand quality checks do not have one, fill the missing values (`team_id`, `measure_on`) from the original quality check instead. This allows manually created quantity-based quality checks to be split correctly after a partial failure. --- opw-6428749 Forward-Port-Of: odoo/enterprise#130275 Forward-Port-Of: odoo/enterprise#126505

New Features(1)

[ADD] l10n_tr_nilvera_einvoice: invoice sequences per journal

Improvements(41)

[IMP] hr_payroll: improve timeoff correction flow

Bug Fixes(30)

[IMP] website_sale: avoid resolving the cart to render the header count

New Features(1)

[ADD] l10n_tr_nilvera_einvoice: invoice sequences per journal

Improvements(41)

[IMP] hr_payroll: improve timeoff correction flow

Bug Fixes(30)

[IMP] website_sale: avoid resolving the cart to render the header count

[IMP] hr_payroll: improve timeoff correction flow

[IMP] mrp, stock: improve manufacturing UX and Transfer filter

[IMP] mrp_{plm, workorder}*: improve ECO stage and planning view UX

[IMP] mrp: add To Replenish filter to MO overview

[IMP] l10n_be_hr_payroll, l10n_be_hr_contract_salary: rename job categories to salary scales

[IMP] discuss: allow custom SFU clients

IMP] mail: messaging menu plugin filters and non app wide tabs

[IMP] project: time by stage report

[IMP] planning_field_service_stock: delivery date on serial numbers

[IMP] website_sale(_stock): Out of stock improvements

[IMP] spreadsheet: update o_spreadsheet to latest version

[IMP] l10n_ch: Allow invoice QR without addresses

[IMP] hr : Onboarding UX Improvement

[IMP] account_reports: add unreconciled filter

[IMP] hr_employee_departure: update termination for workers

[IMP] orm: Char.size constraint

[IMP] loyalty: redesign gift card template

[IMP] im_livechat, *: keep active session when visitor logs in

[IMP] l10n_be_hr_payroll: Time Credit Proration

[IMP] planning_field_service: add new priority level

[IMP] sale_subscription: allow productless subscription lines

[IMP] l10n_be_hr_payroll: Pool Cars DMFA

[IMP] l10n_be_hr_payroll: extra hours exemption in 274.XX report

[IMP] l10n_es: Add abbreviated accounting plan

[FIX] account_reports: Use the new Equity Retained account type

[IMP] account_reports: CTA for equity retained account

[IMP] orm: non-blocking connection pool for gevent

[IMP] l10n_tr_nilvera_edispatch: support invoice serves as e-Dispatch workflow

[IMP] l10n_be_hr_payroll: Car BIK regularization

[IMP] l10n_be_hr_payroll_contract_salary: Private vs Company car

[IMP] hr_payroll: Improve salary adjustments (V4)

[IMP] core: fields.Char(size) only for UI

[IMP] spreadsheet: update o_spreadsheet to latest version

[PERF] base: faster attachment copy

[IMP] l10n_sa: enforce global tax rounding

[IMP] *: drop the percentage price method usages

[IMP] l10n_be_hr_payroll: shorten DMFA worker code names

[PERF] l10n_it_edi: Reduce import line overhead

[PERF] account_accountant: Improve field prediction

[IMP] mass_mailing: Promen-Adductor

[FIX] l10n_fr_pdp: validate Flow 10 report values

[FIX] project: avoid inaccessible projects in assigned task links

[FIX] ai: agent dropdown filter pagination

[FIX] web: allow adding extra media to products

[FIX] l10n_es_edi_tbai_pos: take refund sign of order

[FIX] web_enterprise: fix dark mode colors

[FIX] mail: notify every active user of a mentioned partner

[FIX] mail: notify every active user of a mentioned partner

[FIX] account_journal: search reconcile model foreign currency journals

[FIX] documents(_account): fix embedded actions gc

[FIX] delivery_fedex_rest: take phone from parent or child contact

[FIX] planning_field_service: finished shift appears as to plan from SO

[FIX] hr_work_entry: export time entries with multiple contract versions

[FIX] l10n_be_codabox: use last SODA import date to filter the fetch

[FIX] stock: allocation report follow ups

[FIX] stock_barcode: print allocated labels

[FIX] l10n_tr_nilvera_einvoice{,_extended}: validate lines before send

[FIX] im_livechat: show chatbot answers after restarting session

[FIX] l10n_tr: use the journal return account on credit notes

[FIX] account_edi_ubl_cii: Never import or export deffered dates.

[FIX] payment_razorpay: fix crash on redirect with missing amount

[REV] payment_stripe: remove payment reference from SEPA statement_descriptor

[FIX] l10n_co_reports: Fixing retention reports tax basis

[FIX] account_edi_ubl_cii: Never import or export deffered dates.

[FIX] account_peppol: prevent error when changing Peppol Reception Mode

[FIX] documents: ignore modal clicks in list global click handler

[FIX] quality_control: handle partial failures for on-demand quantity checks

[FIX] l10n_be_soda: duplicate lines