Friday, February 27, 2026
23 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where the tax report export button wouldn't work correctly when companies had different VAT numbers and branches. The fix ensures the button recognizes and processes all companies within the branch hierarchy, allowing users to export reports accurately. This improves the functionality of the tax reporting feature.
Original PR description
To reproduce the issue: - Create a company with a branch - Give the company and its branch different VAT numbers - Make both companies active in the company selector - Open the tax report - Click on gear icon - Click on the XML(l10n_lu_reports)/Export SAWT & QAP(l10n_ph_reports) button ===> The following error is raised: "Please select the main company and its branches in the company selector to proceed." This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierarchy are in the options => they're not => error. We can fix this by simply making the buttons branch_allowed. Followup on: https://github.com/odoo/enterprise/commit/34ba0609e984496f0dcc862f0d7a46c6721beab9 task-5416330 Forward-Port-Of: odoo/enterprise#105961
This update resolves a bug where image sizes were being unintentionally reduced during rotation within the HTML editor. The fix ensures that padding around images is correctly accounted for, maintaining the intended image size and appearance. This improves the user experience when working with images in website content.
Original PR description
**Current behavior before PR:** Steps to reproduce: - In website, drag and drop a `text - image` snippet. - Click on image, click on Transform button. - Try to rotate the image. - You will notice that the size of the image is reduced a bit. This issue happens because in `image_transformation.js`, `convertPixelWidthToPercentage` converts image width from `px` to percentage. In this case image's parentElement has padding, causing reduction in image's size. **Desired behavior after PR is merged:** This PR ensures that `paddingLeft` and `paddingRight` of image's parentElement is ignored from calculation so that image size doesn't get changed. task-5884679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246508
This update resolves a potential issue during Odoo database upgrades. Previously, removing a payroll rule could cause upgrade scripts to fail. This change ensures upgrade scripts continue to function correctly even if a referenced rule has been deleted, improving the reliability of database updates.
Original PR description
This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script. If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value. This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted. Forward-Port-Of: odoo/enterprise#102964
This update fixes a critical error in the calculation of employer costs for Swiss payroll. Previously, employer costs were incorrectly displayed as zero due to a missing flag. The update now accurately computes and displays these costs, ensuring accurate financial reporting and compliance for Swiss businesses using Odoo Enterprise.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103 Forward-Port-Of: odoo/enterprise#106839
This update fixes an error in the UAE Payroll localization module that incorrectly calculated pay rates for employees on attendance-based contracts. Previously, rates were based on actual work hours, but now they accurately reflect the planned working schedule, ensuring correct payroll processing for this contract type.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry…
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#108637 Forward-Port-Of: odoo/enterprise#103282
This update fixes an issue where deleting a partially signed offer would incorrectly delete the associated employee. The fix ensures the employee record remains intact unless the offer is fully archived and the employee has no other active offers. This prevents data loss and maintains accurate employee records.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the…
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109 Forward-Port-Of: odoo/enterprise#108634 Forward-Port-Of: odoo/enterprise#100991
This update ensures overtime calculations are correct when creating or modifying time off requests. Specifically, the system now automatically recomputes overtime when a time off record is created or changed, even if an existing attendance record exists, improving the accuracy of payroll processing.
Original PR description
If you don't have time off app, the option Timing - when Employee is off, should not be available. Creating a time off on a day when there is already an attendance record should automatically recompute the overtime if this rule is on the employee. Forward-Port-Of: odoo/odoo#240940
This update fixes an issue where dependent salary rules weren't appearing in the employee input selection. The change ensures that all relevant rules, including dependent ones, are displayed when adding inputs, streamlining payroll configuration for users. This prevents errors and ensures accurate payroll calculations.
Original PR description
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the…
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display. Navigation: 1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save 2. Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save 3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save 4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available Objective ---------------------- Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet. Solution --------------------------- Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed. Task: 5942461 Forward-Port-Of: odoo/enterprise#107719
This update optimizes how Odoo's Point of Sale system synchronizes data using IndexedDB. Previously, large datasets like loyalty cards could cause slow synchronization, leading to delays when adding items to a customer's cart. This change significantly improves the speed and responsiveness of the Point of Sale experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250799 Forward-Port-Of: odoo/odoo#241373
This update resolves an issue where the correct currency wasn't consistently applied when transferring CODA transactions between multiple journals with the same IBAN but different currencies. The fix ensures that transactions are accurately routed to the appropriate journal based on its currency, improving financial reporting accuracy. This was a critical fix impacting multi-currency accounting.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108677
This update resolves an issue preventing the SAF-T report from correctly displaying supplier names for fixed assets. The fix ensures that the report accurately identifies suppliers by incorporating depreciation lines alongside journal entries, addressing a discrepancy caused by bills being posted in a previous month.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#108734 Forward-Port-Of: odoo/enterprise#105987
This update resolves an issue where AVCO valuations were incorrectly defaulting to a product's initial price when stock move dates were earlier than the product's creation date. The fix ensures that actual stock movements always take precedence in AVCO calculations, providing more accurate inventory valuation.
Original PR description
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps…
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps to reproduce**: - Create a new product with a standard price of 0 and AVCO cost method - Create a PO for that product with a unit cost of 1,000,000, confirm it and validate the receipt - Go to Accounting > Review > Inventory > Inventory Valuation -> Observe that the valuation correctly takes the purchase into account - Go back to the receipt, unlock it and change the effective date to one week in the past - Go back to Inventory Valuation -> Observe that the valuation no longer takes the purchase into account - Change the valuation date to yesterday -> Observe that the valuation takes it into account again **Cause**: When a product is created, a `product.value` record is instantiated with today’s date: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L174 https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L202 In the AVCO computation, a manually set product value (`product.value`) takes precedence over move values when it is anterior, either here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L309-L312 or here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L334-L338 Since the stock move date is set one week in the past, the initial product value (0.0) takes precedence over the move valuation. When the valuation date is moved forward to yesterday, this initial product value is ignored and the move value is correctly applied again. **Solution**: Setting the initial `product.value` date to the product creation date is arbitrary, as it makes inventory valuation depend on when the product was encoded rather than on real stock history. Instead, set the date of the first `product.value` to the earliest possible epoch, ensuring that any real stock move always takes precedence in AVCO valuation. opw-5882080 Forward-Port-Of: odoo/odoo#247407
This update fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the calculation used a default 38-hour week, leading to inaccurate deductions. The fix now uses the employee's actual weekly hours, ensuring correct holiday pay recovery amounts are applied.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#108784 Forward-Port-Of: odoo/enterprise#106205
This update enhances the accuracy of payment reference validation by checking against the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system prioritizes country-specific rules, falling back to a standard check only when a country isn't supported, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/odoo#249380 Forward-Port-Of: odoo/odoo#248194
This update enhances the accuracy of payment reference checks by tailoring validation rules to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validation. Now, the system verifies the reference format against the specific country of the bank account, with a fallback to a standard check for unsupported countries.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#107870 Forward-Port-Of: odoo/enterprise#107116
This update fixes an issue where a POS order could incorrectly apply a pricelist even if it wasn't the customer's standard price list. Previously, loading a pricelist from a paid order would override the correct selection. This change ensures that only available pricelists are applied, improving order accuracy and preventing pricing errors.
Original PR description
When changing the customer on a POS order, if the customer's pricelist is not in the list of available pricelists for the POS, but the pricelist was loaded due to loading a paid order, the POS would still set that pricelist on the order. opw-5461556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248904 Forward-Port-Of: odoo/odoo#247029
This update fixes an issue where invoicing POS orders from closed sessions incorrectly duplicated stock valuation reversals, leading to accounting errors. The change ensures that stock valuation reversals accurately neutralize invoices, maintaining correct inventory tracking. This resolves a bug related to changes in how stock valuation is handled.
Original PR description
When invoicing a pos order from a closed session, we create a reversal move to "neutralize" the invoice. If the order contained storable products, the part of the reversal move that should neutralize the stock valuation was wrong. It would instead debit the same account two times. Steps to reproduce: ------------------- * Create a storable product with a cost price different than 0 and a category with automated inventory valuation * Create a pos order with that product, validate it and close the session * Invoice the order from the backend > Observation: The reversal move lines that should neutralize the stock valuation credit and debit the same account as the invoice. Why the fix: ------------ After the `stock.valuation.layer` was removed, the value of the stock move are now directly stored on the `stock.move`. But they are not signed so we need to rely on `is_out` to determine if we should inverse the value or not. opw-5359646 Forward-Port-Of: odoo/odoo#247863
This update resolves an issue preventing child companies from utilizing the parent proxy user for EDI invoicing. The problem stemmed from a missed update during a recent software update, causing errors when attempting to send invoices from the child company. This ensures seamless integration for clients using the account proxy feature.
Original PR description
This fix implements the same change made in PR #209120 to allow a child company to use the parent proxy user. It seems the record rules modification was missed during the FW, causing issues for clients using this feature in 18.2+ Steps to reproduce: - Create company A and a child company B sharing the same fiscal and VAT information - Register company A in the SDI (creating a proxy user) - Go to company B and try to send an invoice. You will get an error because Odoo will try to create a new proxy user as the parent proxy is currently inaccessible due to record rule constraints. Ticket [link](https://www.odoo.com/odoo/project.task/5927104) opw-5927104 Forward-Port-Of: odoo/odoo#250780 Forward-Port-Of: odoo/odoo#249821
This update fixes a calculation error in the Swiss tax report (l10n_ch) that was introduced during a recent tax revamp. Previously, the ‘Supplies provided abroad’ line incorrectly displayed a negative value. The fix involves a simple formula change from ‘221’ to ‘-221’, ensuring accurate tax reporting for Swiss businesses.
Original PR description
**Steps to Reproduce:** 1. Create a database in version 19 and install the `l10n_ch` module. 2. Create a journal entry using tax grid `221`. 3. Open the Tax Report and check the line `Supplies…
**Steps to Reproduce:** 1. Create a database in version 19 and install the `l10n_ch` module. 2. Create a journal entry using tax grid `221`. 3. Open the Tax Report and check the line `Supplies provided abroad`. 4. The value appears negative instead of positive. - This issue occurred due to the major tax revamp introduced in version 19 [commit](https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c) - To resolve this issue, the formula has been modified from `221` to `-221`. **Before fix:** <img width="1919" height="963" alt="image" src="https://github.com/user-attachments/assets/cea87440-9e7b-4d5e-80d9-6a3d745e5d71" /> **After fix:** <img width="1919" height="963" alt="image" src="https://github.com/user-attachments/assets/f69e3a62-ec6a-4a24-a0cc-b44fab16eefa" /> OPW: 5945876 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#250568
This update fixes an issue where generated QR codes for point-of-sale invoices were incorrectly referencing the local development server instead of the customer's company website. The change ensures that QR codes accurately reflect the correct website domain, improving the customer experience and invoice accuracy. This was caused by a shift in how the base URL is determined within the system.
Original PR description
Steps to reproduce ------------------ 1. Make a website, associated with company 'A' 2. Add a `domain` on that website, e.g. 'test.domain.com' 3. Select company 'A', and create a PoS shop for it 4.…
Steps to reproduce ------------------ 1. Make a website, associated with company 'A' 2. Add a `domain` on that website, e.g. 'test.domain.com' 3. Select company 'A', and create a PoS shop for it 4. Enable 'Self-service invoicing' for that PoS shop, select 'QR code' 5. Open the shop, select a client and make an order -> The generated QR code point to the domain 'localhost:8069' and not to the company's website domain 'test.domain.com'. Why the issue ------------- In 1ee02f8a47d42d3ba3fd11ffcf8d9768ea17678e, we moved the `_base_url` from the session to the config. So now we call `self.get_base_url` on the config and not on the session anymore. However, `self` is an empty config created on the fly, and it's not the `session.config_id` config object used by that shop. The fix ------- In `_load_pos_data_read` of the config model, we call `get_base_url` on the `config` instance, which is garanteed to be the valid config of that shop. opw-5942057 Forward-Port-Of: odoo/odoo#249858
This update corrects a previous issue where NSSF Tier 2 and Pension Contribution details were missing from payslips, even when correctly calculated and reported. The fix ensures that all relevant deductions are accurately displayed on the payslip, providing greater transparency and compliance for Kenyan payroll users.
Original PR description
Issue: - NSSF Tier 2 and Pension Contribution salary rules only appeared on the payslip and salary computation when remitted to NSSF. - When Tier 2 was remitted to insurance, NSSF Tier 2 deductions were missing from the payslip display, even though reporting was correct. - Similarly, Pension Contribution was missing from the payslip when pension was remitted to insurance instead of the pension authority. Fix: - Updated the NSSF Tier 2 salary rule condition to ensure it always appears in salary computation and payslip. - Updated the Pension Contribution salary rule to ensure it is always displayed on the payslip even when remitted to insurance. - Adapted the NSSF Report as well. task-5896380 Forward-Port-Of: odoo/enterprise#106173
This update improves the handling of HSN codes for Indian Point of Sale (POS) transactions. Now, the system checks for missing HSN codes during the POS closing process and prompts the user to complete them before generating the final report. This prevents inaccurate GST reporting and ensures compliance with Indian regulations.
Original PR description
Before this PR: - POS order validation did not enforce the presence of HSN/SAC codes on products. Products without HSN could be sold via POS, and missing HSN values were only detected downstream during GST reporting, after the POS closing entry was generated. After this PR: - HSN/SAC validation is deferred to POS session closing. During the close flow, POS order lines with GST taxes and missing HSN/SAC codes are detected, and the user is required to complete the missing values before the closing journal entry is generated. POS order validation remains unblocked. Why: For Indian localization, POS closing entries are reported in GSTR-1, Table 12 (B2C HSN Summary). Missing HSN/SAC values on POS order lines result in incomplete or incorrect GST reporting. Deferring validation to session closing ensures all required HSN values are captured and propagated into the closing entry, while preserving the POS sales workflow. Task Id: 5404786 Forward-Port-Of: odoo/odoo#241986
This update fixes an issue where invoices using BCE numbers weren't correctly recognized in the PEPPOL system. Previously, the system didn't verify that company registry information matched the expected BCE number, leading to invoice errors. This change ensures PEPPOL invoices are processed accurately.
Original PR description
We expect people to put BCE number in the company registry. But it is not enforced client-side, resulting in invoices in error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251272 Forward-Port-Of: odoo/odoo#251168