Daily updates from Odoo
Monday, March 2, 2026
31 changes · master
Resolved issues and error corrections
This update ensures that check printing accurately reflects the net payment amount after withholding taxes. Previously, the check amount didn't correctly account for withholding, leading to potential discrepancies. A new test case has been added to verify this fix.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108859 Forward-Port-Of: odoo/enterprise#108611
This update resolves an error that occurred when users attempted to initiate the Colombian Electronic Invoicing certification process without a valid certificate. The fix prevents a traceback by ensuring the system handles the case where no certificate is found, improving the user experience and preventing process interruptions.
Original PR description
When no certificate is found in the company, clicking on ``Begin Certification Process`` raises a traceback. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data - Switch to the CO Company - Go to Invoicing > Configuration > Settings > Colombian Electronic Invoicing - Set the Testing ID for Operation mode - In Certificates, delete the existing certificate - Click on Activate the certification process > Begin Certification Process > Ok Traceback: ```py UnboundLocalError cannot access local variable 'cert_sudo' where it is not associated with a value ``` https://github.com/odoo/enterprise/blob/6294be57cf1aa577ec546a958514bc8ec6705935/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1459 The variable ``cert_sudo`` is used outside of the for loop. If no certificate is found, ``cert_sudo`` will be undefined, leading to the UnboundLocalError. sentry-7256943298 Forward-Port-Of: odoo/enterprise#107094
This update clarifies the help text within the Odoo Enterprise payroll module. A previously inaccurate statement was removed to ensure users receive correct information. This change improves the overall usability and accuracy of the payroll functionality.
Original PR description
the last sentence is not always the case so we needed to remove it. task-5423317
This update addresses a recent issue causing tour navigation failures within the Industry FSM modules. The problem stemmed from a removal of a step in a tour file, specifically impacting 'patched tours'. This fix ensures tours function correctly, improving the user experience for those utilizing Industry FSM.
Original PR description
This commit fixes the tours that were failing in `industry_fsm` and `industry_fsm_sale`. The root cause was because of the removal of some step in `industry_fsm_tour`, which is used in patched tours. task-5945991
This update fixes an error in the Spanish Profit & Loss reports where accounts 7950 and 7957 were incorrectly placed in section 10. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108820 Forward-Port-Of: odoo/enterprise#107949
This update fixes a minor typo in the Helpdesk result page related to date formatting. The change ensures consistent display of helpdesk items. This was necessary following a recent update to the Odoo system.
Original PR description
Before this commit and since the merge of https://github.com/odoo/odoo/pull/156878, `date_published` has been replaced by epublished_date` field but the changes have not been made in website_helpdesk_slides module. This commit replaces `date_published` occurrences by `published_date`. task-[5945377](https://www.odoo.com/odoo/project/4105/tasks/5945377) Forward-Port-Of: odoo/enterprise#108253
This update fixes a bug where scrap orders created from the shopfloor didn't trigger notifications. The change ensures that users receive a confirmation message when a scrap order is successfully registered, improving workflow visibility. This resolves an issue reported previously and ensures consistent notification behavior.
Original PR description
Issue before this commit: ========================= Creating a scrap order from the shopfloor does not show any notification after it is created, which was shown in the previous version. Steps to…
Issue before this commit: ========================= Creating a scrap order from the shopfloor does not show any notification after it is created, which was shown in the previous version. Steps to Reproduce: ========================= - Install the mrp_workorder module. - Create a Manufacturing Order for any product (e.g. [FURN_7023] Wood Panel). - Open the shopfloor view. - Click the three-dot menu to access more options. - Create and confirm a scrap order. - No acknowledgement/notification is shown to the user. Cause of the issue: ========================= The method responsible for triggering the notification was renamed in [this PR](https://github.com/odoo/enterprise/pull/85706), but the notification condition was still referring to the old method name. As a result, the notification was never triggered. With This Commit: ========================= Align the method name used in the notification condition so that, when a scrap order is created from the shopfloor, the user correctly receives the notification: `The scrap order has been successfully registered.` Community PR: https://github.com/odoo/odoo/pull/250024 Task: 5958933 Forward-Port-Of: odoo/enterprise#108259
This update enhances the accuracy of payment reference checks by tailoring validation to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system verifies the reference format against the specific country of the bank account, with a fallback for unsupported countries, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#109070 Forward-Port-Of: odoo/enterprise#107116
This update resolves issues with the Belgian XBRL report, specifically correcting inaccurate translations and removing irrelevant company types. The changes enhance the report's data quality and compliance, ensuring more reliable financial reporting.
Original PR description
This commit fixes several issues in the Belgian XBRL report. - Values in report like "false" were being wrongly translated. - Not all company types are valid/relevant. Removed invalid company types. task-5907118 Forward-Port-Of: odoo/enterprise#108556
This update fixes an issue where employees without recorded leave time were not visible in the Gantt view. Now, all employees will be displayed, ensuring a more complete and accurate representation of the workforce. The change improves usability and provides a clearer picture of employee availability.
Original PR description
When going on *Time Off / Management / Time Off > Gantt view*, employees without records (i.e.: leaves) would not be shown. This PR aims to display those employees without records, even supporting any eventual will to paginate the gantt view. To ensure intuitivity, those recordless employees are shown only if the domain passed to the gantt only filters based on fields related to `employee_id`. task-5477588
This update introduces NACE (a European economic classification) codes into the Belgian HR payroll module. This enhancement allows for more detailed reporting and analysis of employee salaries by industry sector, improving compliance and providing valuable business insights. The changes also include updates to flat rate calculations.
This update fixes an issue where payroll rates weren't accurately calculated for employees on attendance-based contracts. The system now correctly uses the planned working schedule's hours per day to determine rates for salary and allowances, ensuring accurate pay calculations when attendance is the primary work source.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry…
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#109048 Forward-Port-Of: odoo/enterprise#103282
This update fixes a bug in the pipeline dashboard where one of the lists wasn't correctly matching data. This ensures that all sales opportunities are accurately displayed and tracked within the dashboard, providing a more reliable view of sales performance. The change was made to improve data accuracy and reporting.
Original PR description
…oard Field matching was missing for the list #1 in the pipeline dashboard. Task: 5092979 Forward-Port-Of: odoo/enterprise#107516
This update fixes an issue where dependent salary rules weren't appearing in the employee input selection. The change ensures that all relevant rules, including dependent ones, are displayed when adding inputs, streamlining the payroll configuration process. This prevents users from missing crucial rules and simplifies payroll setup.
Original PR description
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the…
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display. Navigation: 1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save 2. Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save 3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save 4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available Objective ---------------------- Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet. Solution --------------------------- Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed. Task: 5942461 Forward-Port-Of: odoo/enterprise#109049 Forward-Port-Of: odoo/enterprise#107719
This update corrects an issue where work entries weren't being generated when multiple resource calendar attendances were adjacent. The fix prevents consecutive attendances from being combined, ensuring accurate work entry creation, particularly for credit time entries. The change was driven by a bug discovered during testing and incorporates previously removed tests for comprehensive coverage.
Original PR description
When you have two resource calendar attendances that are stuck together, and you generate work entries, the second one doesn't appear: Bug is caused when having two attendances stuck together: In a resource.calendar, change the time of a resource.calendar.attendance to finish at 15.36 and create a new one that begins at 15.36 and finished at 16.36 with a work entry type of Credit time. Go and regenerate work entries and you can see that no work entries are generated for credit time. Fixed by adding keep_distinct in an interval to not fuse them together. Also added extra checks to another test to not pass with incorrect values. task-5894994 Forward-Port-Of: odoo/enterprise#109050 Forward-Port-Of: odoo/enterprise#105981
This update fixes issues related to the integration of Field Service within the Planning app. Key changes include a new format for time tracking, streamlined field visibility, and the reintroduction of geolocation services, enhancing the efficiency of field service operations.
Original PR description
This commit improves the new field service integration and fixes some mistakes made during the merge of Field Service app inside Planning app. In this commit, - the new format duration has been used…
This commit improves the new field service integration and fixes some mistakes made during the merge of Field Service app inside Planning app. In this commit, - the new format duration has been used for allocated hours and break time fields in planning, - some planning.slot fields are hidden in the form view when field service integration is enabled to reduce the number of fields inside that view since those fields were more useful for a planning manager to prepare the intervention of his workers, - some access right errors are fixed, - the planning user can no longer edit access once field, service integration is disabled, - field service geolocation service has been re-introduced since it was removed when the timer in timesheets has been reviewed, - some terms are now correctly translated, - `planning_field_service` module is flagged as an application, - `Products` menu item has been added in planning field service, - map and activity views has been been added in all planning menu items when field service is enabled. task-5921961 Co-authored-by: Maxime de Neuville (mane) <mane@odoo.com> Forward-Port-Of: odoo/enterprise#108363
This update fixes a reporting issue where NSSF Tier 2 and Pension Contribution deductions weren't always displayed on payslips, even when correctly processed. The changes ensure all contributions are accurately reflected on the payslip, improving payroll transparency and compliance.
Original PR description
Issue: - NSSF Tier 2 and Pension Contribution salary rules only appeared on the payslip and salary computation when remitted to NSSF. - When Tier 2 was remitted to insurance, NSSF Tier 2 deductions were missing from the payslip display, even though reporting was correct. - Similarly, Pension Contribution was missing from the payslip when pension was remitted to insurance instead of the pension authority. Fix: - Updated the NSSF Tier 2 salary rule condition to ensure it always appears in salary computation and payslip. - Updated the Pension Contribution salary rule to ensure it is always displayed on the payslip even when remitted to insurance. - Adapted the NSSF Report as well. task-5896380 Forward-Port-Of: odoo/enterprise#106173
This update fixes an issue where fast payments through the Point of Sale (POS) system were not creating the necessary 'pay later' accounting line. The fix ensures that both normal and fast payment validation processes now correctly generate the required accounting entries, maintaining accurate financial records. This improves the reliability of fast payment processing.
Original PR description
Steps to reproduce ------------------ 1. Install `pos_settle_due` 2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc). 3. Open PoS, and…
Steps to reproduce ------------------ 1. Install `pos_settle_due` 2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc). 3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0 4. Select the invoice(s) 5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom. -> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method. Why the issue ------------- If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created. That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions. After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places: 1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation. 2. On the products screen, when using fast payment, that is fast validation. For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation. However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation. The fix ------- Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation. Notes ----- - We keep the methods in `payment_screen` for backward compatibility, they will be removed in master. - We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`. opw-5488587 Forward-Port-Of: odoo/enterprise#108602 Forward-Port-Of: odoo/enterprise#105660
This update fixes an issue where SII invoices weren't being generated correctly, preventing successful electronic submission. The change updates XML tags related to withholding taxes to align with SII's specific invoice format requirements. This ensures invoices are properly validated and accepted by the SII system.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update fixes a technical error that prevented users from successfully using commands within Odoo's AI chat channels (like '/help'). The issue stemmed from an undefined 'message' response during command execution, now resolved through a code update. This ensures a smoother experience for users interacting with the AI features.
Original PR description
When trying to use commands (for example '/help') in 'ai_chat' channels, an error occurrs. This happens because the 'message' returned from Thread.post method is undefined in that case. Forward-Port-Of: odoo/enterprise#107655
This update resolves an issue where the PIS status field on batch payments wasn't updating correctly after a refresh. The fix ensures the correct database ID is used when fetching the status, now allowing accurate status updates for SEPA credit transfers and similar payments.
Original PR description
When clicking the refresh button next to the PIS status field on a batch payment (e.g., paid with SEPA credit transfer), the status is cleared and no new value is set. This occurs because `onClickFetchStatus` makes an ORM call to fetch the status using `this.props.record.data.id`, which is `undefined`. This commit fixes the issue by correctly using `this.props.record.resId` to pass the database ID to the RPC call. no task-id Forward-Port-Of: odoo/enterprise#108927
This update resolves access restrictions preventing basic users (sale, purchase, stock) from completing key workflows like creating invoices and purchase orders. The change ensures minimal access users can correctly interact with core sales, stock, and purchase processes.
Original PR description
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields…
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access. Here is a list of examples (each performed with every other access rights disabled): - With a `stock user`, open the delivery list or form view #### > Access error - With a `purchase user` create and confirm a PO > Upload Bill #### > the Bill will be created but an access error will prevent the draft bill from opening. - With a `sale user` create and confrim an SO > Create invoice #### > the invoice will be created but an access error will prevent the draft invoice from opening. ## Solutions: ### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user: 1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model. Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view. #### Note for master: IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52 2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53 ### Use case: Open a `stock.picking` views as basic stock user: 3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496 opw-5461135 opw-5417749 Forward-Port-Of: odoo/enterprise#107732 Forward-Port-Of: odoo/enterprise#106694
This update resolves a traceback issue that occurred when reloading the Studio page after opening the product catalog. The change creates a proper action, ensuring the Studio page loads correctly and prevents errors when toggling debug mode or refreshing.
Original PR description
*planning_field_service_sale_timesheet Steps to reproduce: - In Field Service, open the product catalog from a task using state button. - Open Studio - Enable/Disable debug mode or just refresh the page traceback occurs. After this commit: Created the real action so in studio refresh the action loads properly. This prevents the traceback when reloading the page or toggling debug mode. task-5478056
This update resolves a problem where tests were failing when the system used the EUR currency alongside the default USD currency. The fix ensures the USD currency is always active, making the tests more reliable and preventing unexpected errors. This improves the stability of the account invoice extraction feature.
Original PR description
When the tests are run with all modules installed and demo data, some of them fail. One of the other modules activates the EUR currency, which causes the OCR to select it instead of leaving the default USD currency. - Test `test_bank_account` fails because, when the `currency_id` field is set, it triggers a re-computation of `partner_bank_id` which will reset its value to `False`. Runbot build error [240759](https://runbot.odoo.com/odoo/runbot.build.error/240759). - Test `test_invoice_ocr_note_author` fails because it's not expected that the `currency_id` is modified and logged in the tracking message. Runbot build error [238512](https://runbot.odoo.com/odoo/runbot.build.error/238512) (only in saas-19.2 and up, but it is mentionned here as the fix is the same). To make the tests more reliable, we now ensure only the USD currency is active. Forward-Port-Of: odoo/enterprise#108991 Forward-Port-Of: odoo/enterprise#108770
This update fixes an issue where the legal name displayed in the payroll module for Chinese employees was not accurately calculated. The change ensures that the correct legal name is used, complying with local regulations and improving data accuracy for reporting and compliance purposes. This update impacts the HR Payroll module.
Original PR description
task-5979726 Forward-Port-Of: odoo/enterprise#109037
This update ensures self-order transactions in the Odoo Enterprise system now adhere to the same data validation rules as standard point-of-sale orders. This enhancement improves data accuracy and reliability, reducing potential errors and inconsistencies in self-order processing.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order. Forward-Port-Of: odoo/enterprise#108867 Forward-Port-Of: odoo/enterprise#108224
This update corrects the order of payroll warnings displayed to users. The change ensures warnings are presented in a more logical and helpful sequence, streamlining the payroll process. This improves user experience and clarity regarding potential issues.
Original PR description
Order of some warnings were not correct, re-order them. task - 5958677
This update corrects a previous workaround using Ohio as the demo company state, which caused confusion and errors. It now defaults to California and automatically sets the state filing status based on the employee's work address, ensuring accurate payroll validation without compromising existing checks.
Original PR description
Before Main demo company state was set to Ohio to bypass the state filing constraint, which was confusing. Employee versions without a state filing status could also trigger errors. After Restored main company state to California and added automatic defaulting of l10n_us_state_filing_status based on work address state when empty or inconsistent. Impact Removes Ohio workaround confusion and prevents constraint errors while keeping validation intact. Task: 5497781
This update fixes a bug that caused duplicate Dimona activities to be created when updating employee versions or running automated payroll processes. The change ensures that Dimona activities are only created once, streamlining payroll processing and preventing data inconsistencies. This improves the reliability of payroll calculations for Belgian employees.
Original PR description
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on…
This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated. The original bug was: create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium employee > new > payroll > contract > start_date: any date (this should create a first dimona activity) settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually _trigger_l10n_be_next_activities in hr.version of l10n_be_hr_payroll is duplicating Dimona activities on records that already have one. We check if a dimona activity already exists for a given hr.employee before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it. related to: [96423](https://github.com/odoo/enterprise/pull/96423) [tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380)
This update enhances the stability of the HR payroll system by preventing errors when archiving or validating payslips linked to older versions. Specifically, the system now correctly handles scenarios where validated or paid payslips are archived, or when confirming a payslip referencing an archived version. New tests have been added to ensure these changes are functioning as expected.
Original PR description
. If you try to archive/delete a version with Payslips that are validated/paid, a validation error raised . If you try to confirm/validate a payslip that linked to an archived version, a validation error raised . Add corresponding tests task-5432127
This update significantly speeds up the loading of key reporting menus like 'Invoices to be Issued' and 'Invoiced Not Delivered' in the Odoo Enterprise system. The change resolved a performance bottleneck that caused slow load times and memory issues, particularly on large databases. Now, these menus load in just 8.5 seconds instead of over 80, eliminating errors and improving user experience.
Original PR description
### Problem Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus caused MemoryErrors and 80+ second load times on large databases. ### Root Cause `_read_group_for_accrual` loops…
### Problem
Opening the "Invoices to be Issued" and "Invoiced Not Delivered" menus
caused MemoryErrors and 80+ second load times on large databases.
### Root Cause
`_read_group_for_accrual` loops over each group result to manually sum
non-stored computed fields. On each iteration it called `search()` with
a domain containing `('invoice_to_be_issued', '=', True)`, triggering
`_get_accrual_line_ids` once per group instead of once per request.
### Fix
Move the `search()` call outside the loop so matching records are fetched
once per request. The per-group partition is then resolved using
`search_fetch` + `grouped`, which handles the field prefetching and
grouping into recordsets in one call.
### Before / After
| Metric | Before | After |
|-------------------------------|---------|--------|
| Total request time | 82s | 8.5s |
| `_get_accrual_line_ids` calls | 82 | 3 |
| MemoryError on large DBs | ✓ | ✗ |
opw-5392606
Forward-Port-Of: odoo/enterprise#108102