Daily updates from Odoo
Wednesday, April 29, 2026
260 changes
25 changes
Enhancements to existing features
This update simplifies the URLs used to access spreadsheets within Odoo. The previous URLs included a lengthy `sheet_id` parameter, which has been replaced with the shorter `sid` parameter. This change improves URL readability and maintainability.
Original PR description
Current behavior before PR: - The URL used the `sheet_id` parameter, which was unnecessarily long. Desired behavior after PR is merged: - Replace `sheet_id` with `sid` to make the URL more concise and readable. Task: [6171969](https://www.odoo.com/odoo/project.task/6171969) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the URLs used to access spreadsheets within the Odoo Enterprise platform. The previous URLs included a lengthy `sheet_id` parameter, which has been replaced with the shorter `sid` parameter. This change improves URL readability and maintainability.
Original PR description
Current behavior before PR: - The URL used the `sheet_id` parameter, which was unnecessarily long. Desired behavior after PR is merged: - Replace `sheet_id` with `sid` to make the URL more concise and readable. Task: [6171969](https://www.odoo.com/odoo/project.task/6171969)
This update enhances the bank reconciliation process by displaying the analytic distribution of each reconciliation line. This provides users with clearer insight into where funds are allocated, simplifying the reconciliation process and reducing potential errors. The changes were based on existing bank reconciliation components and improved usability.
Original PR description
For automated reco models, we didn't take the amount into account. That means that some lines could have a suggestion of reco model that makes no sense. This commit will allow to show the analytic distribution of a line in the line to reconcile so that it's clear for the user. (Most of the code is taken from the analytic distribution widget and adapted) Also make the popover works on hover task-5733382 Forward-Port-Of: odoo/enterprise#106118
Resolved issues and error corrections
This update enhances the accuracy of French tax reports sent to authorities by completing XML data and fixing minor bugs. Specifically, it adds necessary fields and tags to ensure compliance and improves data validation for company information, ultimately streamlining the reporting process.
Original PR description
This commit aims to make the xml that we send to aspone for the liasse fiscale is the more complete as possible and to correct some small bugs. - Add missing fields in the reports - Add missing tags in the xml - Add a data validation on company data before exporting the reports - Correct errors in the reports - Add country fields in the reports as many2one task-6128878
This update corrects a bug in the payroll system's calculation of full-time equivalent (FTE) hours. Previously, if an employee worked 0 hours, the FTE calculation was incorrect. This change ensures accurate FTE reporting for all employees, regardless of their worked hours.
Original PR description
Before this commit, the full-time equivalent compute was not taking into account the fact that the total worked hours could be 0.
This update resolves a bug preventing users from correctly setting up Worldline and Axepta payment terminals through the quick setup process. The issue stemmed from an incorrect value being used, which is now corrected to ensure both providers function properly. The update also streamlines the logo images for better consistency.
Original PR description
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal…
In odoo/odoo#230817, the Ingenico protocol was removed and merged with worldline (since the terminals support the same protocol). However, one issue from this merge is that in the payment terminal provider cards, which allow quickly setting up a payment terminal by selecting the brand, the Worldline and Axepta options were both not working. The reason for this is that the `use_payment_terminal` field would be set to `axepta_bnpp`, which isn't a valid value and is only used for the name of the logo image. This commit changes the following: - The Worldline and Axepta BNPP cards now both correctly set `worldline` as the payment provider. - The name of the payment method is now set to either 'Worldine' or 'Axepta BNP Paribas' depending on which card is selected. - The logos for Worldline and BNP Paribas have been combined into one image, reflecting the fact that they are a single selection. The alternative would be to add new logic with a separate image path for these providers, which seemed like overkill for this edge case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261709
A recent update caused newly added overtime lines on attendance records to disappear. This fix disables the ability to add new overtime lines, resolving the synchronization problem and preventing data loss. This ensures accurate work entry tracking.
Original PR description
Steps to reproduce: - On an attendance with overtime, click the "Add a line" button and add a new overtime line - Refresh the page - The newly added line has disappeared and navigating to work entries causes a traceback How it was fixed: Disabled the ability to add a new overtime line. Task ID: 5899657 Forward-Port-Of: odoo/odoo#261540 Forward-Port-Of: odoo/odoo#248431
This update corrects a bug that was incorrectly generating overtime entries on previous days. The fix adjusts how work entries are regenerated to accurately account for employee timezones, preventing incorrect date calculations and ensuring accurate overtime reporting.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate…
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#115289 Forward-Port-Of: odoo/enterprise#107266
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the system. The fix corrects a technical error related to how the button's functionality was triggered, ensuring it now functions as expected. This improves the user experience when initiating new payroll processes.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#114101 Forward-Port-Of: odoo/enterprise#111735
This update resolves an issue where commission calculations were failing for recurring subscription orders due to an empty currency rate table. The fix adds a fallback rate, ensuring commissions are correctly applied when currency rates are not populated, leading to accurate commission payouts for subscription-based sales. This improves the reliability of our commission tracking.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The change ensures accurate tax return calculations by isolating company-specific rounding data.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This update corrects a technical issue preventing correct export of HK payroll XML files to the IRD platform. The fix includes adding a required file header encoding and a Byte Order Mark (BOM) to ensure the files are properly formatted and accepted by the IRD system. This ensures accurate reporting for Hong Kong payroll.
Original PR description
Following recent tests, we noticed that the encoding used when exporting our XML files doesn't follow the required format. We noticed two issues during testing: - The IRD platform expects the file to have BOM included. - The encoding in the header must be capitalized. We solve this in this commit by prepending the BOM bytes to the xml bytes; and making sure to capitalize the URF-8 in the header. task-6150470 --- Note: There will be a lot to do during forward ports, as these have changed quite a bit. (XML support for the other file types, and a proper testing file, at least) Forward-Port-Of: odoo/enterprise#115530 Forward-Port-Of: odoo/enterprise#115227
This update corrects a technical issue where styling applied to list views was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list views, improving the consistency and appearance of reports. This resolves a minor visual inconsistency.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685 Forward-Port-Of: odoo/enterprise#114903
This update fixes an issue where the product description text area on iOS devices (specifically with Safari) would jump unexpectedly when typing. The root cause was a miscalculation of scroll height within the application's design. This change ensures a smoother and more reliable experience for users adding product descriptions in invoices.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
This update fixes an issue where refund orders weren't correctly included when calculating outstanding balances. Now, the system accurately reflects all payments and refunds, ensuring accurate due amounts are displayed and settled, particularly when using 'pay-later' payment methods. This improves the reliability of our POS accounting.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#114143 Forward-Port-Of: odoo/enterprise#107883
Previously, changes to a customer's activity (like notes or tasks) weren't consistently reflected across all views within Odoo. This update corrects a technical error that prevented this synchronization, ensuring all users see the most up-to-date activity information. This improves collaboration and data accuracy.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 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#259810 Forward-Port-Of: odoo/odoo#255785
This update resolves a problem where unit prices were not being rounded correctly in Peppol transactions, leading to inaccurate invoice data. This change reverts a previous commit and ensures proper price calculations for Peppol-compliant invoices. It improves the accuracy of financial data for international trade.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870 Forward-Port-Of: odoo/odoo#261941
This pull request addresses an issue with tests related to Mexican electronic invoicing (l10n_mx_edi). It reverts a previous change that introduced errors in how rounding was being tested, ensuring accurate calculations for invoices. This fix improves the reliability of the l10n_mx_edi module.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115611
This update corrects a bug in the employee leave calculation process. Previously, leave time-offs were incorrectly recomputed whenever an employee's version changed, leading to inaccurate data. The fix ensures leave time-offs are calculated based on the correct date range, resolving this issue.
Original PR description
The employee_type_id, job_id and structure_type_id fields on hr.leave were stored related fields pointing to current_version_id. This caused all time offs to be recomputed whenever the employee's current version changed, and stored the current version's values instead of those active at the time of the leave. Replace the related fields with a compute based on date_from, resolving the version active at the leave's start date. task-6175086
This update corrects typos and standardizes wording within the French reporting module (l10n_fr_reports). These changes ensure greater accuracy and consistency in French-language reports, improving the overall user experience for French-speaking customers and internal teams.
Original PR description
Fixes typos and ensures wording consistency No task ID
This update allows accountants to retain important XML files received from KSEF (a Polish tax authority) when processing invoices. Previously, these files were automatically discarded after being used. Now, the XML files are attached to the corresponding invoice, providing a permanent record for compliance and auditing purposes.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update corrects a bug in the salary configuration process. Previously, payslips were calculated using outdated salary rules if generated on the contract start date, leading to inaccurate net pay figures. Now, payslips are always generated based on the current date, ensuring correct calculations.
Original PR description
When the salary configurator is used, it generate a simulation payslip to know get a net value based on the gross. It should be done at the current date, because if it is at contract_start day, maybe years ago, it'll use wrong salary rules values to compute it Forward-Port-Of: odoo/enterprise#115319
This update fixes a visual issue in the invoice report by adding spacing between the Source Invoice and Reference fields. Previously, long invoice names would overlap, making the report difficult to read. This change ensures a cleaner, more professional presentation of invoice data.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
This update resolves an issue where selling a main asset with a closed child asset resulted in incorrect accounting entries. The fix ensures that only active, non-closed assets are considered during the sale process, preventing double-entry errors and maintaining accurate fixed asset and depreciation calculations. A new test case confirms the resolution.
Original PR description
This commit fixes the double entries created when selling the main asset after disposing the child asset. Previously, the sale of the main asset with a closed child asset created 2 entries which resulted in wrong values in fixed asset, depreciation, and gain accounts. This commit filters the non-closed/non-cancelled assets, while previously it would try to close/sell all assets even if it was already closed/cancelled. Test case added to verify fix. opw-6018649 Forward-Port-Of: odoo/enterprise#115452 Forward-Port-Of: odoo/enterprise#115115
This update fixes an issue where Single Touch Payroll (STP) reports were sometimes missed. The system now uses the payslip's creation date instead of the STP submission date, ensuring all payslips are accurately reported to the ATO, even with delayed payment processing. This improves compliance and data accuracy.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
13 changes
Enhancements to existing features
This update simplifies the asset depreciation views in Odoo Enterprise, making them easier to use. Redundant information has been removed, and the default view now shows only active assets. This change improves the overall user experience and efficiency.
Original PR description
Simplify the asset depreciation views by removing redundant information and improving usability. The method column is removed from the assets list since it is already included in the depreciation model name. The depreciation model list is cleaned up to show only the model by default, while filters for method, period, and number of depreciations remain available in the search view. A default Active filter is also added to display only active records. task-6128781
Resolved issues and error corrections
This update ensures that missing payslip issues are only triggered when the payroll closing date has passed. This prevents unnecessary alerts and streamlines the payroll process by focusing on actual overdue payments. It maintains the existing logic for identifying missing payslips.
Original PR description
In this commit, missing payslip in a payrun issue will be raised only if the payroll closing date is due (old conditions remains). task-6008297
This update ensures that payslip simulations accurately reflect current salary rules. Previously, simulations were based on the contract start date, which could lead to incorrect net pay calculations over time. This fix corrects the calculation method to use the current date, guaranteeing accurate pay simulations.
Original PR description
When the salary configurator is used, it generate a simulation payslip to know get a net value based on the gross. It should be done at the current date, because if it is at contract_start day, maybe years ago, it'll use wrong salary rules values to compute it
This update allows accountants to retain KSEF XML files associated with invoices. Previously, these files were automatically discarded after being used to fetch data. Now, the XML files are saved as attachments to the corresponding invoice, providing a backup for longer-term record-keeping requirements.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update resolves an issue where users could unintentionally bypass tax group checks during chart template changes in the l10n_ar module. The update now requires developers to explicitly handle the removal of tax groups, ensuring data integrity and stability. This change restores previous behavior and prevents unexpected errors.
Original PR description
Commit 947e4dc9de3a replaced MODULE_UNINSTALL_FLAG with an explicit 'force_delete' context flag, and as the commit message warns, callees that relied on the previous flag must now detect 'force_delete' on their own. There is no automatic bypass anymore. **STEP TO REPRODUCE** 1.- Install l10n_ar 2-. Select one argentinian regime (fiscal package) & save 3-. Try to change package **FIX** Detect 'force_delete' in check_uninstall_required and return early, restoring 19.0 behavior. Manual deletions of the tax group are still blocked. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261561
This update fixes an issue where the product description field on iOS devices (specifically with Safari) would jump unexpectedly when typing. The problem stemmed from incorrect calculations of the text area's height. The fix removes unnecessary sizing constraints, ensuring the description field resizes correctly and provides a better user experience for adding product details on iPads.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
A recent issue prevented activity updates from being shared correctly across different tabs within Odoo. This fix corrects a typo that was causing this problem, ensuring activity states are now consistently synchronized for all users. This improves the reliability of task tracking and collaboration.
Original PR description
Since [1], the activity state, which is supposed to be shared accross tab through a broadcast channel, isn't anymore. This PR fixes the responsible typo. [1]: #161286 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#259810 Forward-Port-Of: odoo/odoo#255785
This update resolves a visual issue in Safari where the 'is typing' indicator icon was misaligned. The fix avoids complex styling techniques that triggered a bug related to Safari's rendering engine, ensuring the indicator displays correctly. This improves the user experience for Safari users.
Original PR description
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use…
Before this commit, "is typing" icon in Safari browser was misplaced with relative to Discuss Avatar image. This happens due to a bug in Safari that affects `foreignObject` with elements that use some CSS rules, like `opacity`. A prior fix was done to apply on change of opacity with classnames [1], which fixed "offline" icon but is typing still has issues: - change of opacity doesn't use classname, this is coupled to animation frame in CSS - the "is typing" icon uses `filter` and `transform`, both of which are also a problem This commit fixes the issue by not using icon animation for Safari browsers. The rules were mostly used for the animation, and while it's feasible to support the visual in Safari, this would mean a lot of code gymnastic that is not worth supporting this nice-to-have visual. To give an idea of implementation: this would mean a `<g>` for each dot of the typing icon that requires deep integration of `Typing` and `DiscussAvatar` icons, and we should make sure that the styles are applied on the `<g>`. Also a `filter` was used to give better contrast of the typing dot and the green background, notably in dark theme. This is also removed by this commit specifically in Safari, as the technique uses `filter` which causes the bug in Safari. [1]: https://github.com/odoo/odoo/pull/260341 Task-6173311 Before / After <img width="630" height="296" alt="before" src="https://github.com/user-attachments/assets/e600a162-93be-4c11-b5bb-371c01eed773" /> <img width="630" height="298" alt="after" src="https://github.com/user-attachments/assets/36be873a-d24b-49b5-bf1e-e5e462491bde" />
This update fixes an issue where long Source Invoice names were overlapping with the Reference field in point-of-sale reports. A small margin has been added to the Source Invoice block to create more space and improve the report's readability. This ensures a cleaner and more professional presentation of invoice data.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
This update fixes an issue where the system incorrectly flagged payruns as 'missed' reports due to delayed STP submission dates. The change ensures that payruns are accurately identified for Single Touch Payroll reporting, regardless of when the payment is processed, preventing potential ATO reporting errors.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
This update resolves an issue where unit prices were not being rounded correctly when generating invoices for Peppol transactions. This fix ensures accurate pricing calculations for these important international trade processes, improving data integrity and compliance. The change reverts a previous commit that introduced the problem.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870 Forward-Port-Of: odoo/odoo#261941
This pull request addresses a problem with testing related to invoice rounding in the l10n_mx_edi module. It reverts a previous change that was causing test failures. The fix ensures accurate invoice calculations and reporting for Mexican tax purposes.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115610
This update resolves a bug where the cumulated balance calculation in the general ledger was incorrect when using journal groups. The fix ensures that the balance is properly computed when all journals are selected through the journal filter, addressing a discrepancy caused by previous filter logic.
Original PR description
Usually the journal filters doesn't allow the selection of all journals when no journal group is present. However, when a journal group is added, the journal filters allow the selection of all the journal groups to be valid. So, we end up with a filter Journals, with all journals selected but the cumulated balance is not computed. To fix this, if all the journals are selected in the Journals filter, we dont add the journal_ids filter. Step to reproduce: - On any journal, create a journal group - Go to the general ledger - In the Journals filter select "Local Gapp" and the created journal group - Click the journal items button on the line of any account - The cumulated balance will be at 0 even when all the journals are selected.
23 changes
Enhancements to existing features
This update limits the duration of automatically recurring calendar events to 15 years by default, preventing excessive event creation and ensuring predictable scheduling. Administrators can adjust this limit for specific events if needed, maintaining event organization and reducing potential system load.
Original PR description
`forever` recurrent events could currently be created for 720 years into the future, leading to excessive and unnecessary event generation. This change limits the creation of forver recurrent events to a fixed horizon of 15 years (by default) in the future, ensuring predictable behavior and preventing unbounded recurrence. The maximum horizon can be adjusted through the system parameter `calendar.max_recurrence_years` for events that require a longer recurrence window. Task-5714633 Forward-Port-Of: odoo/odoo#247929
This update enhances the bank reconciliation process by displaying the analytic distribution of each reconciliation line. This provides users with clearer insights into where funds are being matched, reducing confusion and improving accuracy. The changes were based on existing bank reconciliation components and now function on hover.
Original PR description
For automated reco models, we didn't take the amount into account. That means that some lines could have a suggestion of reco model that makes no sense. This commit will allow to show the analytic distribution of a line in the line to reconcile so that it's clear for the user. (Most of the code is taken from the analytic distribution widget and adapted) Also make the popover works on hover task-5733382 Forward-Port-Of: odoo/enterprise#106118
Resolved issues and error corrections
This update resolves an issue where reports for Withholding Taxes (WHT) were incorrectly mixed with VAT closing entries. Removing the specific return type for WHT ensures accurate reporting and prevents data confusion, leading to more reliable financial data. This improves the clarity and accuracy of financial reports.
Original PR description
WHT does not require a closing entry. The current return type is causing VAT closing entry to mix with WHT closing entry or vice versa. task-6157814
This update addresses a problem where payruns were incorrectly flagged as missing in the 19.1 release for the Belgian HR Payroll module. The fix removes a dependency on company-level closing dates, aligning the payrun logic with a previous request (GMF). This ensures accurate payrun generation and reporting.
Original PR description
In this commit, we removed the missing payrun issue from 19.1, since we are missing the closing_date in company-level and the missing payrun should depend on that value (GMF request). task-6008297
This update fixes an issue where byproducts added directly to manufacturing orders weren't correctly linked to stock movements. Now, byproducts added to MOs are properly tracked, ensuring accurate inventory and production reporting. This improves the reliability of shop floor data.
Original PR description
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a…
When we add a byproduct followed by SN directly in the MO it will not have the its location as production. Steps to reproduce: ------------------- * Create product tracked by Serial number * Create a Manufacturing order * Add the Product tracked by serial number on the MO as byproduct * Confirm the MO * Go to shop floor * Add the by-product quantity and create a new serial number. * Close production and go back to the MO in manufacturing * Open stock moves -> the by-product does not have "production" for origin Observation: ------------- When we add the byproduct directly in the MO, they will be added to move_byproduct_ids in the MO but not in byproduct_ids on the stock.move because byproduct_ids it's a [link](https://github.com/odoo/odoo/blob/d14bf6289da21065860ff959185c47b947a7418c/addons/mrp/models/stock_move.py#L50-L52) between the stock.move and the BOM. When adding the byproduct in shopfloor, it will create the quant: https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163-L171 Additionaly when creating the quant it will decide the source location depending if the product its a byproduct: https://github.com/odoo/enterprise/blob/1d10ee238a50e7bdb552efdeafc068c5127cd49a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L189-L192 The issue arise because it check if the product it's a byproduct by checking byproduct_ids and since our product was added directly on the MO and not from the BOM it will not appear in byproduct_ids https://github.com/odoo/enterprise/blob/dc5bb0fe8e15063f977970841bdaf8aff1a61e41/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L108-L110 #### Additional notes: The default value for [byproduct_id](https://github.com/odoo/odoo/blob/abb5777cc8324cff0cdf841a8ae42413060dcf92/addons/mrp/models/mrp_production.py#L1263) when creating the stock move is false opw-5974582 Forward-Port-Of: odoo/enterprise#110122
This update resolves an issue where commission calculations were failing for recurring subscription orders due to an empty currency rate table. The fix adds a fallback rate, ensuring commissions are correctly applied when currency rates are not initially populated. This prevents lost revenue and ensures accurate commission payouts for subscription-based sales.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update fixes an issue where the ewallet discount was incorrectly included in delivery calculations. The change adjusts the pricing logic to accurately exclude ewallet amounts from delivery costs, ensuring consistent and accurate shipping charges for customers. This improves the customer experience and prevents overcharging.
Original PR description
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99…
Issue: --- Ewallet line is included in delivery pricing. Steps to reproduce: 1- Create a delivery method `based on rules`. 2- In pricing set rules: - price <= 99 => delivery price = 30 - price > 99 => delivery price = 50 3- Create a eWallet with balance = 200. 4- Create a SO add a line with product. Set the SOL unit amount to 100. 5- Click on `add a shipping`. Add the created delivery method. 6- As you see, the delivery amount is correctly calculated. 7- Now apply the eWallet using `reward` button. 8. Update the shipping cost. The shipping cost is 30, which is not expected. Cause: --- In calculation of shipping amount the ewallet is not taken into account. Even though technically it's considered a discount, ewallet is not functionally the same as discount. However, in `_get_price_available` we cannot have information about `ewallet` lines as it doesn't depend on `sale_loyalty`. Fix: --- We use `_compute_amount_total_without_delivery` which is overridden in `sale_loyalty_delivery` to exclude ewallet and gift cards. opw-6124209 Forward-Port-Of: odoo/odoo#260134
This update allows accountants to retain KSEF XML files associated with invoices. Previously, these files were automatically discarded after being used to fetch data. Now, the XML files are attached to the corresponding invoice, providing a permanent record for accounting and compliance needs.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update resolves an issue where the product description text area on iOS devices (specifically with Safari) would jump unexpectedly when typing. The fix removes a problematic sizing setting that was causing inaccurate scroll height calculations, ensuring the description field behaves correctly and allows users to enter text without the text area shifting.
Original PR description
Steps to reproduce ================== - Use an iPad device - Go to accounting - Sales > New - Add the product column in the invoices lines - Add a new line - Select a product - Add a description - press enter a bunch of times => the cursor will end up beneath the virtual keyboard - enter a letter => the textarea jumps above Cause of the issue ================== With Safari, setting a size on the widget root causes the scrollheight to be miscalculated. It doesn't take into account the last empty lines of the textarea. Solution ======== There is actually no need to set an height on the widget root node. opw-5927775 Forward-Port-Of: odoo/odoo#259855
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that totals align with the sum of invoices, providing more accurate reporting for partner transactions. This improves the reliability of financial data.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update fixes a technical issue that prevented users from leaving live chat channels without triggering an error. The fix ensures the channel leaving process is executed only once, preventing access problems. This improves the stability and usability of the live chat feature for all users.
Original PR description
When a non-livechat user leaves a livechat channel after being invited, an access error occurs. This is due to `leaveChannelRpc` being called twice: once in `_onClose`and again in `leaveChannelProcess`. The first call removes the membership, while the second attempts to access the channel without proper rights, triggering the error. This commit fixes the issue by ensuring that `leaveChannelRpc` is only called once when leaving the channel. Task-[6072247](https://www.odoo.com/odoo/project/1519/tasks/6072247)
This update resolves an issue preventing the deletion of time off allocations when created after a payslip has been validated. Previously, the system incorrectly blocked deletion, requiring manual adjustments through HR. This change ensures time off can be deleted regardless of when it was created relative to payslip validation.
Original PR description
## Issue When creating a time off for a date that is already covered by a confirmed payslip, that time off cannot be deleted. ## Steps to reproduce 1. Install *Time Off in Payslips*…
## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
- Date: anywhere during March
- *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**
## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:
https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203
It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.
The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.
opw-6089990
Forward-Port-Of: odoo/enterprise#114895This update fixes an error in how emission factors are converted within the Odoo Enterprise ESG module. The previous process incorrectly handled unit and currency conversions, leading to inaccurate calculations. This change ensures that emission calculations are now precise and reliable.
Original PR description
Issue: ---------------------------------------- The conversions using Emission factors are done in the wrong way. Steps to reproduce: ---------------------------------------- - Install `esg` module - Create an Emission Factor from ton to kg of 1000 - Create a new Emission using the new factor, set the unit as kg - Notice the conversion is wrong Cause: ---------------------------------------- The two uom are inverted when calling `_compute_quantity()`. Same occured for the currencies. opw-6152413 Forward-Port-Of: odoo/enterprise#115246
This update fixes a visual issue in the invoice report where long 'Source Invoice' names would overlap with the 'Reference' field. A small margin has been added to the 'Source Invoice' block to create more space and improve readability. This ensures a cleaner and more professional appearance of the report.
Original PR description
Before this commit: - When the Source Invoice name is too long, it connect with the Reference field due to missing spacing. After this commit: - Added margin (`me-3`) to the Source Invoice block to ensure proper spacing and avoid overlap with the Reference field. task-6074560 | Before | After | |--------|--------| | <img width="801" height="474" alt="image" src="https://github.com/user-attachments/assets/cbef48f8-c37b-4263-8c6f-a6b0de3716b9" /> | <img width="780" height="462" alt="image" src="https://github.com/user-attachments/assets/fa01e0b5-d877-424f-a51f-8da0ce5a6bd5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256641
This update resolves an issue where unit prices were not being rounded correctly when generating invoices for Peppol transactions. This fix ensures accurate pricing calculations for international trade and compliance with Peppol standards. The change reverts a previous commit that introduced this rounding problem.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870 Forward-Port-Of: odoo/odoo#261941
This pull request addresses an issue with testing related to invoice rounding in the l10n_mx_edi module. It reverts a previous change that introduced errors in the test files, ensuring accurate calculations and reporting. This update maintains the integrity of financial data within the Mexican Electronic Invoicing system.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115609
This update prevents users from starting polls while editing existing messages within channels or groups. Previously, the 'Start a Poll' action appeared misleadingly in the editor's menu. Now, the action is hidden when editing a message, ensuring it's only visible when composing a new message.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- When editing a message in a channel or group and opening the 'More Actions' menu in the composer, the 'Start a poll' action is displayed among the available options. Starting a poll while editing an existing message makes no sense, as polling is only meaningful when composing a new message. **Current behavior before PR:** ---------------------------------------------- - 'Start a poll' action appears in the composer 'More Actions' menu even when the user is editing an existing message - Clicking it while in edit mode opens the poll creation dialog, which is misleading and unintended behavior **Desired behavior after PR is merged:** ---------------------------------------------- - 'Start a poll' action is hidden from the 'More Actions' menu when the composer is in edit mode - The action continues to appear as expected when composing a new message in a channel or group conversation Task-6171541 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the size of the product search bar was incorrectly set, causing issues with a website tour. The fix ensures the search bar's size is only defined for the 'website_sale_renting' module, preventing disruptions to other website features.
Original PR description
__Before commit__ odoo/enterprise@1111381c set the size attribute of the product search bar. However, the view inherits from `website.website_search_box`, which means that all search boxes on the website will have the size attribute set if `website_sale_renting` is installed. The tour `dropdowns_and_header_hide_on_scroll` fails in saas-19.3 because odoo/odoo@9394e17a added a step that depends on the size of the main website search bar, which may vary because of this. __After commit__ Only set the size attribute to the product search bar as intended. runbot-242449
This update resolves minor issues within the point-of-sale test suite, specifically the checkTicketData() function. The changes ensure accurate test results by correctly handling empty data and preventing unexpected type conversions, ultimately increasing the reliability of our POS testing.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566This update fixes a minor bug in the tests for our Point of Sale system. Specifically, it corrects how the tests handle empty data results and prevents unexpected behavior when comparing values. These changes ensure the tests run reliably and accurately, maintaining the stability of the POS functionality.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566This update corrects a potential issue where Single Touch Payroll reporting was missed when payruns were submitted after the initial payment date. The fix now uses the payrun's creation date instead, ensuring accurate reporting to the ATO regardless of payment delays. This improves compliance and data reliability.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
This update fixes a discrepancy in the sale details report by accurately reflecting cash rounding adjustments. Now, the report displays the total cash rounding applied during a session, aligning with payment records and providing a clearer picture of financial transactions. This ensures greater accuracy and transparency in sales reporting.
Original PR description
The sale details report total_paid was computed from sum(order.amount_total), which does not include the cash rounding adjustment. This caused a discrepancy between the displayed total and the sum of individual payment lines when cash rounding is enabled. Use the sum of actual payment amounts instead, which naturally includes cash rounding since payments are recorded with their rounded values. opw-5253018 Forward-Port-Of: odoo/odoo#261671 Forward-Port-Of: odoo/odoo#254401
This update corrects a bug that appeared when editing appointment pages in the website builder. Specifically, an unnecessary attribute was removed from a component, preventing errors during debug mode. This ensures a smoother editing experience for users.
Original PR description
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid…
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid props for component 'BuilderContext': unknown key 'reload'" Cause: ====== The `reload="'/'"` attribute on `<BuilderContext>` in appointment_type_option.xml was never a valid prop on the component: `basicContainerBuilderComponentProps` (the source of `BuilderContext`'s props) doesn't include `reload`. https://github.com/odoo/odoo/blob/f4700ba0f070003ac8a3828f9fd8583c27671e3f/addons/html_builder/static/src/core/utils.js#L887 In normal mode OWL silently ignores unknown attributes, but in debug mode prop validation runs and raises a Traceback Solution: ========= The reload behavior the actions actually need is already handled via `BuilderAction.isReload = true` in `appointment_type_option_plugin.js`, https://github.com/odoo/enterprise/blob/21ed8a6c1cad8d533d04659a3997c2d7e0c3965b/website_appointment/static/src/plugins/appointment_type_option_plugin.js#L35 so the attribute can be removed. opw-6152741 Forward-Port-Of: odoo/enterprise#115242
3 changes
Resolved issues and error corrections
This update removes an unnecessary and invalid configuration setting from the website appointment builder's editing interface. The change was triggered by debug mode validation, which identified an outdated attribute. The underlying functionality is now handled more efficiently, ensuring a smoother editing experience for users.
Original PR description
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid…
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid props for component 'BuilderContext': unknown key 'reload'" Cause: ====== The `reload="'/'"` attribute on `<BuilderContext>` in appointment_type_option.xml was never a valid prop on the component: `basicContainerBuilderComponentProps` (the source of `BuilderContext`'s props) doesn't include `reload`. https://github.com/odoo/odoo/blob/f4700ba0f070003ac8a3828f9fd8583c27671e3f/addons/html_builder/static/src/core/utils.js#L887 In normal mode OWL silently ignores unknown attributes, but in debug mode prop validation runs and raises a Traceback Solution: ========= The reload behavior the actions actually need is already handled via `BuilderAction.isReload = true` in `appointment_type_option_plugin.js`, https://github.com/odoo/enterprise/blob/21ed8a6c1cad8d533d04659a3997c2d7e0c3965b/website_appointment/static/src/plugins/appointment_type_option_plugin.js#L35 so the attribute can be removed. opw-6152741
This update fixes an issue where the IRN (Invoice Reference Number) generated during e-invoicing wasn't correctly saved or displayed on the invoice itself. Now, the IRN number is accurately included in the generated Invoice PDF, ensuring complete invoice documentation for compliance. This improves the visibility and traceability of e-invoices.
Original PR description
**Steps to reproduce:** * Install module *Indian - GSTR with E-invoice (l10n_in_edi_gstr)*. * Configure *Indian integration* with required credentials (E-Invoicing, E-Way bill, etc.). * Save the settings. * Create a *customer invoice*. * Post the invoice. * Send the invoice through *E-Invoicing (EDI)*. * Open the generated *Invoice PDF* and the *form view*. **Observed behavior:** * The *IRN number* is correctly present in the *Invoice PDF*. * However, it is *not saved/displayed* in the invoice form view. **Cause:** * The invoice flow did not store the *IRN number* on the invoice after receiving the EDI response, even though the value was available. **Fix:** * Inherit *_l10n_in_edi_send_invoice*. * Add a condition after the invoice is sent and the JSON response is received. * When the *IRN number* is present in the response, set it on the *l10n_in_irn_number* field of the invoice (in lower case). opw-6097923 Forward-Port-Of: odoo/enterprise#114350
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter was not used. The fix ensures that the total balance aligns with the sum of all invoices within the ledger, providing more accurate financial reporting. This improves the reliability of partner financial data.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
9 changes
Resolved issues and error corrections
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that the total balance aligns with the sum of all invoices, providing more accurate financial reporting for partners. This improves the reliability of our accounting data.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update allows accountants to retain KSEF XML files associated with invoices. Previously, these files were automatically discarded after being processed, preventing accountants from storing them for compliance or auditing purposes. Now, the XML files are attached to the corresponding invoice record, providing easy access for the accountant.
Original PR description
Description of the issue this commit addresses: When fetching the bills from ksef, the xml with the data about the move is received, parsed and then discarded but the XML can be required to be kept for longer than ksef keeps it so we are lacking a way for an accountant to download it and store it locally. --- Desired behavior after this commit is merged: When a move is fetched from ksef via an xml file, that file is put as an attachment on the move created with its data. --- task-6076505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259655
This update resolves an issue where unit prices were not being rounded correctly when generating Peppol invoices. This fix ensures accurate pricing information is included in invoices, improving compliance with Peppol standards and preventing potential discrepancies in financial reporting. The change reverts a previous commit that introduced this error.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. Forward-Port-Of: odoo/odoo#261941
This update fixes an issue where flexible work schedules were incorrectly calculating overtime. The change adjusts how the system determines the weekly work range, ensuring accurate overtime indications for employees with flexible hours. This improves the reliability of timesheet reporting.
Original PR description
**problem:** On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative…
**problem:** On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week. **steps to reproduce:** 1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average) 2. Assign this schedule to an employee 3. Go to Timesheets, search for the employee 4. Navigate to a past week 5. Enter 4h on each working day 6. Observe the overtime indication shows incorrect value (-01:00) **cause:** In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20. **fix:** - Use the UTC date before conversion to the employee's timezone when determining the flexible date range. **note:** Updating the test (test_no_carried_over_leaves_for_flexible_resource) in hr_holidays/tests/test_expiring_leaves.py expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior. link to the enterprise PR: odoo/enterprise#112879 opw-5970511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261049 Forward-Port-Of: odoo/odoo#257269
This update fixes an error in how Odoo calculates overtime for employees on flexible work schedules. Previously, flexible schedules were incorrectly displaying negative overtime values. The fix ensures accurate overtime calculations by correctly handling time zone conversions and date ranges, preventing inaccurate overtime indications.
Original PR description
**problem:** On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative…
**problem:** On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week. **steps to reproduce:** 1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average) 2. Assign this schedule to an employee 3. Go to Timesheets, search for the employee 4. Navigate to a past week 5. Enter 4h on each working day 6. Observe the overtime indication shows incorrect value (-01:00) **cause:** In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20. **fix:** - Use the UTC date before conversion to the employee's timezone when determining the flexible date range. - prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones. **note** Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior. link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879 link to the community PR: https://github.com/odoo/odoo/pull/257269 opw-5970511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#114888 Forward-Port-Of: odoo/enterprise#112879
This update fixes an issue where incorrect Nemhandel identifiers were being generated when Danish company VAT numbers with the 'DK' prefix were entered. The change removes the 'DK' prefix from CVR numbers, ensuring accurate identification and preventing errors for Danish clients using Nemhandel.
Original PR description
Before this PR: - When a user enters a full VAT number with the 'DK' prefix in the company registry, the Nemhandel identifier becomes incorrect and results in a cryptic error being returned to the client. After this PR: - The prefix is removed if the CVR contains the 'DK' country code, to ensure the correctness of the Nemhandel identifier. task-5449059 Forward-Port-Of: odoo/odoo#261719
A small update has replaced the previous video used in the website's editing interface with a new, available video. This ensures the website's video snippets continue to function correctly and avoid any display issues caused by the original video no longer being accessible. This is a routine maintenance fix.
Original PR description
Specification: - The previously embedded video used by the "s_video" snippet (id=G8b4UZIcTfg) is no longer publicly available. After this commit: - This commit replaces the default video with a new publicly available one (id=nbso3NVz3p8). task-6034987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261064 Forward-Port-Of: odoo/odoo#253874
This update fixes an issue where users without write access to the Point of Sale (PoS) in the AT (Austria) version of Fiskaly would receive an access error when attempting to authenticate after a token expiration. The fix ensures that users are correctly denied access, preventing errors and improving the PoS experience for AT business customers.
Original PR description
When trying to auth directly from the PoS when the token expires, if you are logged in with a user that doesn't have write access to the PoS. You would get an access error. Steps to reproduce: ------------------- * Setup Fiskaly in an AT company * Open PoS and try to make a sale * To fake the token expiration I modified the code so that the request always return 401 status code > Observation: You get an access error opw-5925203
This update fixes a bug where users without the necessary permissions were encountering errors when trying to access their profile information. The team added a specific field to the user data to ensure that all users can view their own profile details, regardless of access rights. This improves the user experience and prevents frustration.
Original PR description
Issue: - When a user without access rights tries to view their profile, a permission error is raised. - Issue PR: https://github.com/odoo/odoo/pull/254162 Fix: - Added `employee_country_code` to SELF_READABLE_FIELDS in `res.users`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255260
1 change
Resolved issues and error corrections
This update corrects an issue where the Partner Ledger displayed incorrect initial balances when the date range filter was disabled. Previously, the total balance didn't match the sum of its individual transactions. This change ensures accurate reporting of partner balances, improving financial data reliability.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
9 changes
Enhancements to existing features
This update simplifies tax deductions for employees in India by allowing HR to select a tax deduction schedule (monthly, quarterly, etc.). The system now automatically calculates and displays TDS amounts correctly on tax declarations, ensuring accurate reporting and compliance. This change improves the user experience for HR and payroll teams.
Original PR description
- Added a `l10n_in_tds_schedule` field to the contract and template so HR can easily choose the tax deduction schedule (monthly, quarterly, half-yearly, last three months). - Updated the TDS formula in salary rules to deduct tax based on the chosen schedule, while keeping the tax declaration amounts evenly spread out. - Modified the Tax Declaration web view and PDF report to automatically show the correct label for the chosen schedule. task-4236978
Resolved issues and error corrections
This update ensures that Timesheet reports are only generated for invoices with service lines, not goods-only invoices. Previously, irrelevant reports were automatically created and attached, leading to wasted resources and potential confusion. This change improves efficiency and accuracy in invoice sending.
Original PR description
Before this PR: --- - When adding the Timesheets dynamic report to the "Invoice: Sending" email template, it was always included in the Send & Print wizard. - Even if the invoice contained only goods and no timesheet-based service lines, the Timesheets PDF was generated. - The wizard built attachment placeholders purely from the mail template configuration without validating invoice content. - As a result, irrelevant Timesheets PDFs were generated and attached to goods-only invoices. After this PR: --- - The Timesheets dynamic report is generated only when the invoice contains at least one timesheet-based service line. - For goods-only invoices, the Timesheets report does not appear in the Send & Print attachments widget. - The wizard now filters dynamic report placeholders based on actual invoice content. - Unnecessary Timesheets PDFs are no longer generated or sent. Related - https://github.com/odoo/odoo/pull/187381 task - 5361456
This update fixes an issue where leave calculations were incorrectly recomputed due to outdated employee version references. The change ensures that leave time-offs are calculated using the correct, active version of employee data, leading to more accurate and reliable leave balances. This improves the stability and accuracy of the payroll system.
Original PR description
The employee_type_id, job_id and structure_type_id fields on hr.leave were stored related fields pointing to current_version_id. This caused all time offs to be recomputed whenever the employee's current version changed, and stored the current version's values instead of those active at the time of the leave. task-6175086
This update addresses an issue where Coda transaction files sometimes lacked complete data, leading to default 'No description' labels appearing on bank statements. The change ensures accurate payment references by handling potential missing data from the Coda file, preventing incorrect statement line descriptions.
Original PR description
It can happens that coda file with transaction have no communication or structure communication. This can cause problem since we will have an empty payment_ref for the statement line. This will add "No description" as a default value. task-6045138 Forward-Port-Of: odoo/enterprise#111300
This update resolves two issues impacting manufacturing order management within the Barcode app. Previously, changes to the unit of measure and production quantity were not saved correctly, leading to inconsistencies. Now, these changes are reliably preserved, ensuring accurate production tracking.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#115254 Forward-Port-Of: odoo/enterprise#114075
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The fix ensures that rounding is calculated correctly for each branch, resulting in accurate financial reporting.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This pull request addresses a problem with invoice testing related to rounding calculations in the l10n_mx_edi module. It reverts a previous change that introduced the issue and confirms the fix. This ensures accurate invoice generation and reporting for Mexican businesses using this module.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115612
This update resolves a visual issue where the timesheet system tray overlapped with records when scrolling on smaller devices. The changes expand the timesheet grid and adjust its layout to prevent overlapping, ensuring a cleaner and more user-friendly experience for timesheet management.
Original PR description
Before: The systray overlaps the records when scrolling on small screens Changes: - Expands the record list to avoid scrolling overlaps - Make the timesheet list expand before the checkout button to ensure no overlap - Restrict the height of the timesheet list to avoid the double-scrolling problem --- task: 6115674 Forward-Port-Of: odoo/enterprise#114093
Code cleanup and technical improvements
This update ensures the HR payroll module seamlessly integrates with Odoo's Fleet module. The changes correct missing return statements, ensuring proper functionality across various HR payroll processes related to fleet employees. This improves accuracy and consistency in payroll calculations for employees associated with company vehicles.
Original PR description
task-6045425
8 changes
Enhancements to existing features
This update adapts Odoo's reporting to align with the latest Russian tax regulations (Act 2025). The change removes reliance on outdated tax section dependencies and now uses report line names and tax tags for accurate TDS/TCS reporting, ensuring compliance.
Original PR description
In this commit, the XLSX export and report warning are adapted to support the newly introduced TDS/TCS reports as per Act 2025. Previously, the XLSX reports depended on TDS/TCS sections. However, with Act 2025, certain taxes no longer have associated sections. This dependency has been removed, and report generation now relies on report line names and tax tags instead. task-6124431
Resolved issues and error corrections
This update resolves an issue preventing the generation of VAT Books in the Spanish version of Odoo Enterprise. A change in the button logic required updating the XPath expression to avoid errors. The VAT Books now open successfully after this fix.
Original PR description
After an update, the t-if of the button was changed, and it was necessary to adapt the xpath to avoid errors After the change, the VAT Books opened without problems task-6170173
This update resolves a minor visual issue where the bank reconciliation popover was incorrectly displayed on all lines, even those without relevant transactions. The fix ensures the popover only appears when appropriate, improving the user experience and preventing unnecessary visual clutter. This is a low-impact fix.
Original PR description
In this commit:https://github.com/odoo/enterprise/commit/5d88ae9fc1e1f43797fe7d9118a0582f949dc7be we changed the way the popover was working to make it display on hover but forgot to add the condition to display the popover. It means that it was display for every line even the one without exchange move or partial reconcile, so there was a small visual glitch no task id
This update fixes an issue where the Datev CSV export incorrectly calculated tax amounts when a vendor bill used multiple tax repartition lines. The fix ensures accurate tax reporting for Datev, improving financial data consistency. This resolves a reported problem impacting German tax reporting.
Original PR description
With l10n_de_reports: - Configure a foreign currency with an exchange rate. - Configure a tax with multiple repartition lines. - Create a vendor bill in this foreign currency with this tax. - In the general ledger export the datev csv. In the datev csv the rate is wrong. In the method _l10n_de_datev_get_csv, we build a tax_amount dict. However when one tax has multiple lines, the amount is replaced and not added. opw-6010097 Forward-Port-Of: odoo/enterprise#110453
This update corrects a bug in the appointment booking process for flexible scheduling. Previously, a 20-minute slot was incorrectly serialized, leading to a 404 error. The fix ensures accurate slot duration calculation, resolving the booking issue and improving the user experience.
Original PR description
Steps to reproduce: 1. Install `appointment` 2. Create an appointment type with the followings 3. Schedule type flexible and a slot of 20 min. 4. Share this appointment and try to book appointment for 20 min. Issue: - 404 Error occurs after selectiong the slot Cause: - In 19.0, commit https://github.com/odoo/enterprise/commit/9bae0e13e7bf5e0db25a60fc2683bc51eccb4447 started using slot.duration when building the booking URL for flexible slots. However, slot.duration is rounded to 2 decimals, so a 20-minute slot is serialized as 0.33 instead of its exact value. During validation, the end datetime is recomputed from this rounded duration, which no longer matches the original slot boundaries. This mismatch causes the slot to be considered invalid and the controller raises NotFound. Solution: - Compute the slot duration directly from slot_start_dt_tz and slot_end_dt_tz when building the URL, preserving the full precision. opw-5924312
This update fixes an issue where Single Touch Payroll reports were sometimes missed. The system now checks the creation date of the payslip, rather than the submission date, to ensure all payroll data is accurately reported to the ATO, even with delayed payments. This improves compliance and avoids potential penalties.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865
This update fixes an issue where the Partner Ledger displayed incorrect initial balances when the date range filter wasn't used. The fix ensures that partner balances accurately reflect all transactions, resolving inconsistencies between totals and subline amounts. This improves the reliability of financial reporting.
Original PR description
To reproduce the issue: 1) Create an invoice of 100 € for partner A in 2025 2) Create another invoice of 200€ for the same partner in 2026 3) Open the Partner Ledger for 2026. Unfold A. It shows an initial balance of 100€ and a total of 300€. 4) In debug mode, open the Partner Ledger's form view and uncheck the date range option. 5) Open the Partner Ledger like in step 3) ====> An initial balance of 300€ shows, making the total of Partner A (still 300€) inconsistent with the sum of its sublines (600€) feedback-6042305 Forward-Port-Of: odoo/enterprise#115455
This update corrects a technical error that prevented users from editing appointment pages in the website builder. The issue stemmed from an unnecessary attribute being included in the BuilderContext component, which was flagged by debug mode. This change ensures a smoother editing experience for all users.
Original PR description
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid…
Steps to reproduce: =================== 1. Enable debug mode (`?debug=assets`). 2. Open an appointment page in the website & edit mode. 3. Click the appointment type block. => Traceback "Invalid props for component 'BuilderContext': unknown key 'reload'" Cause: ====== The `reload="'/'"` attribute on `<BuilderContext>` in appointment_type_option.xml was never a valid prop on the component: `basicContainerBuilderComponentProps` (the source of `BuilderContext`'s props) doesn't include `reload`. https://github.com/odoo/odoo/blob/f4700ba0f070003ac8a3828f9fd8583c27671e3f/addons/html_builder/static/src/core/utils.js#L887 In normal mode OWL silently ignores unknown attributes, but in debug mode prop validation runs and raises a Traceback Solution: ========= The reload behavior the actions actually need is already handled via `BuilderAction.isReload = true` in `appointment_type_option_plugin.js`, https://github.com/odoo/enterprise/blob/21ed8a6c1cad8d533d04659a3997c2d7e0c3965b/website_appointment/static/src/plugins/appointment_type_option_plugin.js#L35 so the attribute can be removed. opw-6152741 Forward-Port-Of: odoo/enterprise#115242
8 changes
Resolved issues and error corrections
This update corrects a technical issue that could cause problems with voice message tests in Odoo. Specifically, the system was prematurely resolving promises related to voice playback, leading to potential errors. This fix ensures that the voice player is fully drawn before promises are resolved, improving test reliability and stability.
Original PR description
Before this commit, voice message tests don't wait until the voice player is drawn before resolving the corresponding promise. This may lead to race conditions. This commit fixes the issue by properly `await`ing the completion of the asynchronous code before resolving the promise. Related runbot error: https://runbot.odoo.com/odoo/error/163783 Forward-Port-Of: odoo/odoo#261795
This update fixes an issue where Sale Order Line descriptions were incorrectly displaying vendor-specific information instead of the standard product name. The change ensures the correct product name is used in the description, regardless of whether the customer and vendor are the same. This improves data accuracy and consistency in sales orders.
Original PR description
Steps to reproduce: ------------------------- 1. Install Sales and Purchase modules. 2. Create a product; in the Purchase tab, add a vendor with a vendor "Product Name" and "Product Code". 3. Create…
Steps to reproduce: ------------------------- 1. Install Sales and Purchase modules. 2. Create a product; in the Purchase tab, add a vendor with a vendor "Product Name" and "Product Code". 3. Create a Sale Order using this same vendor as the Customer. 4. Add the product to the Sale Order Line (SOL). Reference [video](https://drive.google.com/file/d/1wqsOoE00kOowm9puGXgDTGdV9Xkkwton/view?usp=sharing) Observation and issue: ------------------------ 1. Before clicking outside the SOL, the description remains unfilled despite the availability of a vendor product name and code. 2. Upon clicking outside the SOL, the description displays only the vendor product name and code incorrectly overriding the standard product name. Cause: --------- * The SOL description([_compute_name](https://github.com/odoo/odoo/blob/cbcfb93067f6a3ec6f87dfa5b05497777bead425/addons/sale/models/sale_order_line.py#L406)) depends on product's `display_name`, but missing dependencies prevent `_compute_display_name` from being triggered before saving. For reference, POL description: https://github.com/odoo/odoo/blob/a877beaeeb45a2ca3d68bf423f9948f58f6c64aa/addons/purchase/models/purchase_order_line.py#L369-L370 * When the customer and vendor are the same, the `display_name` is computed using vendor context (`partner_id`), causing vendor-specific values to override the product name. https://github.com/odoo/odoo/blob/cbcfb93067f6a3ec6f87dfa5b05497777bead425/addons/product/models/product_product.py#L538-L548 Solution: ----------- * Add the required dependencies to ensure the SOL description is computed correctly . * Skip vendor-based naming when the seller and customer are the same, and fallback to the default product name. opw-5262670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where expense or profit entries were incorrectly appearing in both the current and previous year's Profit & Loss statements. The underlying calculation was flawed, leading to inaccurate reporting. This ensures balance sheet reports accurately reflect financial data.
Original PR description
When generating an expense or profit entry for the current year and then opening the balance sheet for that same year, the entry appears in both the current year’s P&L and the previous years’ P&L. This happens because the previous years’ balance includes all entries and then subtracts the current year, but the subtraction was applied incorrectly (it was effectively doing the inverse). opw-6020381
This update resolves an issue where unit prices were not being rounded correctly when generating PEPPOL invoices. This fix ensures accurate pricing calculations for international trade transactions, improving data integrity and compliance with PEPPOL standards. The change reverts a previous commit that introduced this rounding problem.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870
A test within the MRP module was failing due to a dependency on a module only available in the Enterprise version of Odoo. This update removes the problematic dependency, ensuring the test now runs successfully across both Community and Enterprise environments. This resolves a consistent test failure and improves overall test coverage.
Original PR description
The test `test_multi_lot_component_consumption` relies on `move_raw_line_ids`, which is initialized by the `stock_barcode_mrp` module. This module is only available in enterprise, causing the test to fail in community setups. https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/mrp/tests/test_consume_component.py#L494 runbot-242612
This update resolves an issue in the LDAP authentication testing process where the test left behind data in the database. By switching to a simpler `HttpCase` test setup, the problem is fixed and paves the way for adding another test to address a related bug. This ensures the stability and reliability of our LDAP integration.
Original PR description
The unit test is tagged `-standard` and `database_breaking` because it was leaving left overs in the database. Using an `HttpCase` over a `BaseCase` solves that issue in addition to make the code way simpler. We want to resurrect this unit test class because we plan to add another unit test in that class for a bug fix. Forward-Port-Of: odoo/odoo#261743
This update resolves a critical issue where the Libro Diario report crashed on large databases due to excessive memory usage. The fix implements a more efficient, 'lazy-loading' architecture to handle large datasets, ensuring the report remains accessible and reliable. This change also ensures compliance with accounting regulations.
Original PR description
Loading the Libro Diario (Daily Journal Report) on production databases with large volumes of accounting data causes the Odoo server to crash with a MemoryError, killing the worker process and making…
Loading the Libro Diario (Daily Journal Report) on production databases
with large volumes of accounting data causes the Odoo server to crash
with a MemoryError, killing the worker process and making the report
completely inaccessible.
#### Root Cause
The report used a flat, single-tier architecture that loaded all matching `account.move.line` records at once.
Profiling revealed that `_dynamic_lines_generator` attempted to materialize the entire result set into memory via `dictfetchall()` without LIMIT or OFFSET.
Additionally, an `INNER JOIN` on `res_partner` excluded transactions lacking a partner, rendering the report legally non-compliant.
#### Fix
Implemented a two-tier lazy-loading architecture following the General Ledger pattern:
* **Tier 1 (`_dynamic_lines_generator`):** Groups entries by date using SQL `GROUP BY`. Returns summary lines per calendar day (max 31 lines for `this_month`).
* **Tier 2 (`_report_expand_unfoldable_line_libro_diario_day`):** Loads specific `account.move.line` records only when a day is expanded (`load_more_limit = 80`).
* Additional Changes:
- Changed `default_opening_date_filter` from `this_year` to `this_month`.
- Enabled `filter_unfold_all` and `load_more_limit` in XML.
- Switched to `LEFT JOIN res_partner` to include all economic transactions.
- Overrode `_get_domain` to remove the mandatory `partner_id` constraint.
The new architecture remains fully compliant with Articles 125-128 of Regulatory Compliance (Decreto 2649/1993).
opw-6023518This update fixes a bug where users without the necessary permissions were encountering errors when trying to access their profile information. The team added a field to the user data structure to allow access to country codes, resolving the permission issue and ensuring all users can view their profile details.
Original PR description
Issue: - When a user without access rights tries to view their profile, a permission error is raised. - Issue PR: https://github.com/odoo/odoo/pull/254162 Fix: - Added `employee_country_code` to SELF_READABLE_FIELDS in `res.users`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255260
1 change
Enhancements to existing features
This update adjusts payroll deductions for employees aged 60 or older. It ensures NSSF contributions stop when an employee reaches 60, aligning with Kenyan regulations and accounting for the timing of the change (starting in the following month). A new test has been added to verify this functionality.
Original PR description
[IMP] l10n_ke_payroll: stop NSSF deductions after 60
When the user is creating a payslip and if the age of employee is >=60 the NSSF deductions must stop
(If the 60 years is finished in 10th of March -> it will stop in April (deduction stop starts from next month))
Test:
Unit test is written to check stopping NSSF deductions with dynamic birthday.
task - 6074658