Friday, February 20, 2026
28 changes · saas-19.1
Enhancements to existing features
This update allows companies to automatically receive KSeF invoices directly from the tax authority, eliminating the need for traditional paper invoices. This streamlines the invoicing process and ensures legally compliant delivery of sales records. It improves efficiency and reduces manual handling of tax documents.
Original PR description
If a company sell me something, they can send me an invoice. With KSeF, they do not have to send an invoice to me by post or mail - they can send it directly to KSeF. And it is legally delivered to me. Implement fetching bills from KSeF task-5405257 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247812
Resolved issues and error corrections
This update resolves an issue where the AI translation feature in the website builder would fail due to a 10-second timeout. The fix removes this timeout restriction, allowing translations to complete successfully even with large amounts of untranslated text. This improves the user experience for translating website content.
Original PR description
Scenario: - have lot of untranslated text in a page - in a secondary language, open translation editor - click on "Translate to [current language]" in side panel Result: the translation fails completely or partially, and there is a notification saying "A technical issue occurred in the builder, you should save or discard your changes.". Reason: since 6df83abb35c95ab42e55d9a08cf6c411efa64b3e website builder action have a default timeout of 10 seconds to prevent deadlocks. But the /html_editor/generate_text can easily take more than 10 secondes depending on latency and quantity of text to translate. Fix: prevent the timeout when using the AI translation feature. opw-5892402 Forward-Port-Of: odoo/odoo#249464
This update ensures that expense accounts are linked to the correct company when using products. Previously, expenses created for one company would incorrectly use accounts from a different company. This fix resolves a potential issue with inaccurate financial reporting and improves data consistency.
Original PR description
The aim of this commit is to ensure the account select through product is related to the correct company. (ie. the one related to the processed model) Before this commit: If a user has company_a selected as the main company in the company switcher and create an expense for company_b, the account selected from the product will be an account from company_a. (because product is shared between company but the account properties on those are company dependent) This could also happens in other places so we fixed it. After this commit: The account selected from the product will be from the company set on the model. task-4699717 Forward-Port-Of: odoo/odoo#249194 Forward-Port-Of: odoo/odoo#209144
This update resolves an issue where upgrades were failing due to delayed constraint definitions. Specifically, when modules loaded in a different order, outdated constraint definitions were causing errors. This patch ensures the latest definition is always applied, improving the stability and reliability of Odoo upgrades.
Original PR description
Current issue: Module A fails to add constraint X with definition D1 -> (X,D1) is delayed Module B loaded after A, overrides constraint X to D2 and also fails to add the constraint -> still (X,D1) are in the delayed queue, instead of (X,D2) In this patch we ensure the delayed constraint gets the latest definition (D2) This issue affects upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249495
This update fixes issues with how custom snippets are displayed in the website editor's preview. Specifically, it ensures consistent preview heights for carousel snippets and correctly shows zoom effects for parallax snippets, while also ensuring custom snippet labels are displayed. These changes improve the user experience when creating and managing website content.
Original PR description
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet…
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview height is too small. Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low. After this commit, the preview height uses the layout size so the min-height stays consistent with other slides. ---------- Steps to reproduce: - Open the website editor. - Open the snippet dialog and resize the window. => The parallax preview background shifts to the left. - Save a snippet with a parallax zoom in/out effect as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview shows a top to bottom effect instead of zoom. Before this commit, resizing the snippet dialog could offset the parallax background to the left, and zoom previews looked like top to bottom effects. After this commit, the preview keeps the background aligned and shows zoom in/out effects for custom snippets. Fixed parallax is still not previewed because it would require an oversized background in the dialog. ---------- Steps to reproduce: - Open the website editor. - Save a "Carousel" snippet as a custom snippet. - Open the snippet dialog. => The custom snippet shows no label. Before this commit, custom previews dropped the base label so the dialog showed no tag for custom snippets. After this commit, custom previews reuse the base label. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present** Forward-Port-Of: odoo/odoo#248929 Forward-Port-Of: odoo/odoo#244295
This update enables users to remove orderlines when using the LNE certified scale module in Point of Sale (PoS). Importantly, the system still prevents manual quantity adjustments beyond zero, ensuring data accuracy for scale-based transactions. This resolves a previous limitation and improves the usability of the certified scale functionality.
Original PR description
This PR allows the user to delete PoS orderline when using LNE certified scale module while still forbidding to manually set quantity to anything other than 0 Forward-Port-Of: odoo/enterprise#107413
This update ensures the 'first_contract_in_company' field always reflects the employee's earliest contract start date, regardless of when it was created or modified. Previously, this information was unreliable due to a manual process, now it's automatically calculated and updated whenever a contract version changes, improving payroll accuracy and reporting.
Original PR description
Version-19.0 **Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late. We need that information at other places too. ### What This PR Does This PR restores…
Version-19.0
**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
We need that information at other places too.
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
1. A new contract is created
2. an existing version changes it start date, or
3. an existing version is deleted for the employee.
### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
`contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
1. fetches all the active versions of employee
2. filter those having `contract_date_start`
3. Computes the earliest start date.
4. Updates `employee.first_contract_in_company` accordingly.
**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.
Forward-Port-Of: odoo/enterprise#102198This update prevents discounts applied to recurring subscription lines from being removed when an upsell is added to the order. Previously, confirming an upsell would reset the discount, leading to incorrect pricing. This change ensures accurate discount calculations for subscription orders with upsells, improving order accuracy and customer satisfaction.
Original PR description
Before this commit, the discount of recurring lines in a sub would be reset in the following case: 1) create a sub, add a discount on recurring line 2) invoice the sub 3) create an upsell, add quanitty on the recurring product, change the start date of the upsell to trigger computation 4) confirm the upsell The discount of the parent order was reset. task-5886270 Forward-Port-Of: odoo/enterprise#105750
This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to errors and inconsistencies when creating accounting records. The fix ensures invoices are processed with the correct company details, preventing data mismatches and improving data accuracy for cross-company transactions.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233 Forward-Port-Of: odoo/odoo#249409 Forward-Port-Of: odoo/odoo#249059
This update resolves an issue where changing a partner in Odoo would erase the previously set default payment term for invoices. Now, the default payment term will remain consistent, regardless of the partner being used, ensuring a smoother and more reliable invoicing process. This prevents frustration and maintains data integrity.
Original PR description
When you want to set a default payment term for an invoice, it will be there when you create the invoice. But then, when you change the partner, even if there is no default payment term defined on there, it will empty it, so setting a default does not work. This can even be annoying if you set the payment term first and then the partner. In odoo/odoo#112360 this condition was added for perf issues. opw-5387239 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#242041
This update fixes an issue where the working time assigned to tasks wasn't accurately calculated when switching between companies with and without public holidays. The fix ensures that working time is correctly computed based on the last stage change and considers company-specific holiday impacts.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883 Forward-Port-Of: odoo/odoo#246994
This update corrects a bug where high-priority applicants weren't appearing at the top of the applicant list in the Recruitment module. The fix resolves a technical issue with how applicant priority was being ordered, ensuring that the most important applications are now displayed first.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any…
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any application Very High Priority (3 star) 5. Refresh the page Observation: ---------------------------------------- Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage. Issue: ---------------------------------------- The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41 Solution: ---------------------------------------- Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first opw-5893371 Forward-Port-Of: odoo/odoo#247779
This update fixes an issue where changes made to email marketing records within the form editor were lost when switching between tabs. The fix ensures that the editor correctly saves changes when the focus is lost, improving the user experience and data integrity. This prevents data loss and ensures consistent email marketing campaigns.
Original PR description
Problem: While editing an email marketing record, switching tabs in the form view causes the last changes in the editor to be lost. Cause: The `blur` event on the iframe is not triggered when clicking outside of it. If the iframe is not fully ready when listeners are attached, the required events are not properly registered, so the latest changes are not saved before switching tabs. Solution: Attach the `blur` listener only once the iframe is fully loaded, ensuring that changes are correctly detected and saved when focus is lost. Steps to reproduce: - Create a new email marketing record. - Add a text snippet. - Change the text and save. - Modify the text again. - Switch to another tab in the form view, then return to the "Mail body" tab. - Observe that the last changes are lost. opw-5921800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248974
This update optimizes the master production schedule to significantly reduce order processing times. The previous system was pulling unnecessary data, leading to delays. This change improves efficiency and responsiveness for order fulfillment.
Original PR description
When traversing X2many fields (bom_ids, bom_line_ids) during prefetching in filtered, the _prefetch_ids data grew excessively. Prefetching bom lines pulled in IDs for lines belonging to all boms across all associated products, even though _skip_bom_line in this case only operates on the current product's context. Use prefetch() with no args to avoiding unnecessary record loading for unrelated boms. Benchmark: | |Before |After| |-----------------|-------|-----| |action_replenish |Timeout|577ms| Related ticket: opw-5928055
A recent update allowed users to confirm dialogs with CTRL+Enter, but this caused a double confirmation issue. This fix prevents the dialog from being confirmed twice, ensuring that only one floor is created when a user uses CTRL+Enter. This resolves a data inconsistency issue.
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212134
This update automatically calculates and transmits the 2050 pension contribution for employees in Switzerland using the Swissdec standard. This ensures accurate and compliant payroll processing, addressing a previous calculation error and streamlining the process for our Swiss clients.
Original PR description
task-5166226 Forward-Port-Of: odoo/enterprise#104140 Forward-Port-Of: odoo/enterprise#103453
This update fixes a potential issue in Australian payroll tax calculations by ensuring that historical data is used, not current employee settings. Previously, tax calculations relied on the employee's current information, which could lead to inaccuracies when an employee's details changed. Now, payslips correctly reference the historical configuration data for each pay period, guaranteeing accurate tax and withholding calculations.
Original PR description
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields…
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values. This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state). This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period. The following rules/fields are updated to use the version object: - Tax Treatment Category - Additional Withholding Amount - Extra Pay - TFN Declaration - Medicare (Reduction, Exemption, and Levy) - Training Loans - NAT 3093 Amount (Tax Offset) - Child Support (Garnishee and Deduction) A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates. Task-5002697 Forward-Port-Of: odoo/enterprise#107568 Forward-Port-Of: odoo/enterprise#106550
This update resolves an issue where imported vendor bills with a product price of $0.00 were incorrectly increasing the total price due to floating-point calculation errors. The fix ensures that the product price remains accurate, aligning the Odoo total with the original XML invoice total. This prevents overcharging and maintains data integrity.
Original PR description
Whenever a line with price `0.0` with `AllowanceCharge`s got imported, Odoo used to update the `price_unit` to the sum of price, allowance and charges, because of a wrong float comparison condition between this sum and the XML total. So the product price was increased, but the allowances were maintained. The total imported in Odoo became double the one in the XML. Step to reproduce: - Import vendor bill from XML with a product: - price: `0.00` - quantity: `1` - an AllowanceCharge, amount: `0.2` - an AllowanceCharge, amount: `0.1` - `0.0 + 0.2 + 0.1 (sum of price and allowances) != 0.3 (subtotal)` (but `float_compare(0.1 + 0.2, 0.3, precision_digits=4) == 0`) - `price_unit` is updated to `0.3` - Total in Odoo is `0.6` Ticket [link](https://www.odoo.com/odoo/project.task/5499525) opw-5499525 Forward-Port-Of: odoo/odoo#249357 Forward-Port-Of: odoo/odoo#248043
This update resolves an issue where printing Italian fiscal receipts was failing due to a missing currency setting in the order. The fix ensures the ticket is printed only after the order has been fully synced, guaranteeing the correct currency information is available. This prevents printing errors and ensures accurate fiscal receipts for Italian POS users.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced. 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
This update resolves a problem that prevented Italian fiscal printers from working correctly. The fix ensures the order's currency information is properly synced before printing the receipt, guaranteeing accurate and reliable printing for Italian businesses using Odoo Enterprise.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced.
This update ensures payslips accurately reflect an employee's start date with the company, regardless of internal job changes. Previously, payslips used the current contract's start date, which was inaccurate for long-term employees. This change, primarily impacting payroll in Switzerland and the UAE, provides a more reliable and accurate representation of employee tenure.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#106692
This update fixes an issue where OCR-extracted expense amounts were incorrectly converting to USD, forcing a 1:1 exchange rate. The change ensures that expenses with foreign currencies are accurately converted to the company's base currency, improving the reliability of financial reporting. This resolves a discrepancy in total amounts displayed for expenses.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#107862 Forward-Port-Of: odoo/enterprise#107534
This update resolves an issue where the delivery amount was being calculated twice during Stripe express checkout, leading to incorrect order totals. The fix focuses on excluding delivery lines from the tax calculation process, ensuring accurate pricing for customers using express payment methods like Apple Pay or Google Pay. This improves the reliability of the checkout experience.
Original PR description
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay…
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay) 2- Set fixed price on standard delivery: 10 3- Navigate to website: add a product to cart. Use express checkout. Outcome: The delivery price is calculated twice which is wrong. Cause: --- This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount. Then we add delivery carrier `minorAmount`: https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice. Fix: --- We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines. opw-5424398 Forward-Port-Of: odoo/odoo#249340 Forward-Port-Of: odoo/odoo#248415
This update corrects a technical issue where delivery and invoicing addresses weren't being displayed correctly on reports using the 'lines' layout. The fix ensures that address information is now consistently shown, improving the accuracy of reports for customers. This was part of a larger effort to refine the layout and spacing of information blocks.
Original PR description
The `information_block` is always false on the `external_layout_lines` this means that when a delivery address and invoicing address is specified they are not rendered. Reviews the spacing of the bubble layout `information_block` task-5951799 Part of task-5949213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue in how the point-of-sale system handles client payments. Previously, change amounts were always rounded for cash transactions. Now, the system correctly accounts for different payment methods (like cards) and ensures change is accurately calculated, regardless of the payment type. This improves the accuracy of financial reporting within the POS.
Original PR description
We extract the condition into a getter so we can override it elsewhere. For now, it is overriden in `pos_settle_order`. See below for explanation. `change` is the amount we return to the client, so it's in cash, and therefore, we always round it if `cash_rounding` is true. However, in pos_settle_order, when a client 'deposits money', the order `change` is what we get paid by that client, and he might choose a payment method different than cash (card for e.g.). We change the `shouldRoundChange` logic to count for such cases. opw-5222985 Forward-Port-Of: odoo/odoo#248787
This update ensures that the amount due for customer deposits is rounded correctly based on the selected payment method. Previously, rounding was applied regardless of the payment type, leading to inaccurate amounts. This change now respects cash rounding configurations for deposits, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the…
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27. 3. Close the session and reopen it, then select that customer, and click settle due 4. Select the Bank payment method, so a NON-Cash payment method. Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27. That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round. The fix ------- Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings. We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method. opw-5222985 Forward-Port-Of: odoo/enterprise#105368 Forward-Port-Of: odoo/enterprise#100278
The Time Off balance report was incorrectly calculating remaining time off days due to how allocations were aggregated. This fix reorders allocations by their start date to ensure accurate calculations, particularly when employees have multiple allocations across different periods. This ensures the report accurately reflects available time off.
Original PR description
The balance report aggregates allocations regardless of the period in which they occur resulting in wrong information when an employee has two allocations in different periods and a filter is used in the report Steps to reproduce: 1. Install Time Off app 2. Open Time Off app and go to Management > Allocations 3. Create a new allocation of 100 days for employee "Mitchell Admin" of time off type "Paid Time Off" with a validity period from 01/01/2027 to 31/12/2027 and approve it 4. Activate debug mode 5. Go to Time Off > Reporting > Balance 6. The number of days left for "Mitchell Admin" for "Paid Time Off" is 120 days even though the default filter is on the period of 2026 Solution: Refactor the entire query: we order the allocations by date_from so we can subtract taken leaves from the allocations in that order opw-5156142 Forward-Port-Of: odoo/odoo#249512 Forward-Port-Of: odoo/odoo#245860
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. The report templates have been updated to the final 20251210 NT20 taxonomy, ensuring compatibility and accurate data submission.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126