Daily updates from Odoo
Monday, March 23, 2026
306 changes
20 changes
Enhancements to existing features
This update ensures that follow-up reminders are consistently sent to customers, even when a large volume of reminders are queued. The system now automatically re-triggers the reminder process if there are still outstanding reminders, preventing delays and improving customer communication. A configurable batch size allows users to optimize the process for their specific needs.
Original PR description
In case there is a lot of followup to process, the followup cron doesn't retrigger and we have to wait the next day for them to be sent. This commit make use of the ir.cron progress API so that the cron is retriggered if there are followup left to be sent. We also make the batch_size configurable to that a user could tune it on the cron. opw-6042472 Forward-Port-Of: odoo/enterprise#110918
This update enhances the security and reliability of exporting large spreadsheet data from Odoo. It adds logging for key export actions like XLSX downloads and clipboard copies, and restricts access to frozen/XLSX downloads to authorized users. This ensures data integrity and protects sensitive information.
Original PR description
Forward-Port-Of: odoo/enterprise#109138 Forward-Port-Of: odoo/enterprise#85888
Resolved issues and error corrections
This update fixes a visual inconsistency in accounting reports. Previously, the company header was grayed out in dark mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across all Odoo Enterprise environments.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111509 Forward-Port-Of: odoo/enterprise#110108
This update resolves an issue where long tax amounts in invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the numerical size, improving the clarity and accuracy of Ke revenue reports. This enhancement ensures consistent and reliable reporting for Kenyan businesses.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
A technical issue preventing the generation of the Trial Balance report PDF has been resolved. The update corrects a formatting error in the report template, ensuring the PDF can now be successfully printed without errors. This improves the reliability of a key financial reporting tool.
Original PR description
Printing the PDF of the Trial Balance report raises a traceback. Steps to reproduce the error: - Install ``Accounting`` module - Go to Accounting > Reporting > Trial Balance > Click PDF Traceback: ```py AttributeError: 'AccountReportLineData' object has no attribute 'get' ``` https://github.com/odoo/enterprise/blob/ee5be988fd57b9b23265875fec7b42f2a761144f/account_reports/data/trial_balance_template.xml#L28 After Commit [1], line is ``AccountReportLineData`` object instead of disctionary. As a result, accessing line values using ``line.get(...)`` causes the traceback. [1]: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420 sentry-7323693096
This update resolves a technical error that prevented invoices with the ICBPER tax code in Peru from generating correctly. The fix adjusts a configuration setting to avoid a data structure mismatch, ensuring invoices process smoothly and accurately. This improves the reliability of invoice generation for Peruvian clients.
Original PR description
**Steps to reproduce:** 1. Install module `l10n_pe_edi`. 2. Switch company to PE. 3. Create a tax: - Name: ICBPER - Amount type: Fixed - Code: ICBPER - Amount: 0.5(e.g.) - Set the tax group to ICBPER…
**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
- Name: ICBPER
- Amount type: Fixed
- Code: ICBPER
- Amount: 0.5(e.g.)
- Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).
**Issue:**
Processing the invoice raises:
AttributeError: 'dict' object has no attribute '_get_downpayment_lines'
**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.
During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
- With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
- With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.
**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error
**opw-5809939**
Forward-Port-Of: odoo/enterprise#108638This update resolves several issues impacting the Field Service planning feature, specifically related to shift generation, data handling, and user interface display. The changes ensure accurate state management during shift duplication and improve the overall usability of the planning tools.
Original PR description
## [FIX] planning_field_service*,worksheet: fixes follow-up This commit fixes and improves field service feature in planning to be sure to not have any regression compared to the previous field…
## [FIX] planning_field_service*,worksheet: fixes follow-up This commit fixes and improves field service feature in planning to be sure to not have any regression compared to the previous field service app. In detail, this commit will: - better handle SOL generation - fix buttons visibility, display name, multi-company issues - fix mix up demo and data - auto install when sale timesheet and field service - display the first slot for today in the stat button - handle multi-company issue in slot conflicts Make partner phone readonly if no Contact access. Hide the Serial/Lot products from the shift catalog if the user has no inventory access - display view itinerary label in mobile - set role in field service product - fix the domain of SO stat buttons related to shifts - fix the default groups of "Planning By ..."" actions. - use a custom search view for 'resource_ids' in kanban of shifts - ask to switch in employee portal - hide by default some fields in list view of shift - avoid recomputing when a worksheet property changed - display message to design worksheet in desktop only - display plan intervention in ticket - recompute allocated hours when break time changed - rename Publish & send button into Publish in form view of planning.slot model - display full form in my planning only ## [FIX] planning: manage state in copy_data Before this commit, when the shift is duplicated, the state is not reset as expected. This commit sets copy=False on state field of planning.slot model, to handle that in copy_data when the shift is splitted because in that case we want to keep the state instead of resetting it. ## [FIX] planning: display notification error when save as template a template Before this commit, since the Save as template button is in the cog menu, it is still displayed even if shift has already generated a shift template. This commit will display a notification in the action of that button when there is already a template linked to that shift. ## [FIX] planning: display planned dates in display_name when empty Before this commit, the display_name of a shift could be empty and displays "Unamed" in the breadcrumb due to project, task, customer and role can be unset on the shift. This commit will display the planned dates of shift when the other fields used in the compute of display name are unset. However, the planned dates are not displayed in the display name if the view is gantt or calendar because the planned dates are already displayed and would be redundant. ## [FIX] worksheet: hide section when separator is folded Before this commit, when the definition of a worksheet defines 2 sections folded by default with some properties inside of each one and the worksheet template is used for a shift, if the user just unfolds one section to fill in just this one and lets the other section unfolded, then the properties in the both sections are displayed in the portal of the shift even if the second section is folded. The reason is because the value of the second separator is not in the properties of the shift because it is untouched. This commit checks if the separator is by default folded if its value is not in the properties of the shift. task-6020304 Co-Authored: Xavier Bol (xbo) <xbo@odoo.com>
This update enhances the payroll system by expanding worker code searches to include DMFA and egov3 codes, in addition to display names. This ensures more accurate and complete worker code identification, improving payroll processing efficiency and data accuracy.
Original PR description
before when searching for worker code it only used display name. now it uses dmfa, egov3 codes. Task#6020172
This update resolves a technical issue that could cause errors when importing bank statements with multiple journals using different currencies. The fix prevents a redundant process from triggering a singleton error, ensuring smoother and more reliable CODA import for businesses operating with multiple currencies.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111361 Forward-Port-Of: odoo/enterprise#111101
This update corrects a visual discrepancy between how the AI livechat snippet is displayed in the editor and how it appears to users. The fix ensures the snippet's appearance matches the real-time experience, resolving a rendering problem caused by mismatched code structures. This improves the overall user experience for AI livechat setup.
Original PR description
Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change) Forward-Port-Of: odoo/enterprise#109569
This update clarifies potential errors (code 9004) that users might encounter when running the Odoo Instagram module. The change provides a helpful explanation to assist users in troubleshooting without needing to contact support. This improves the overall stability and usability of the Instagram integration.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110571 Forward-Port-Of: odoo/enterprise#109319
This update resolves a problem where reports with annotations were failing to export correctly. The previous filtering process was redundant, and this change removes unnecessary date filtering, ensuring reports with annotations now export reliably. This improves the balance sheet report generation process.
Original PR description
[FIX] account_report: Unable to export Report with Annotations Following changes to the date filter in https://github.com/odoo/enterprise/pull/98695, the date options can be missing a date_from (For example, when using period type: "today"). The date were used to filter on the annotations to display during the period of the report. However, we already filter on those date when generating the annotations so this was redondant and can be safely removed. To reproduce: - Open the Balance sheet - Open the chatter of any account and post a message - Click on the "PDF" button to export the report
This update fixes a potential issue where payroll calculations were being applied to outdated payslips, which could have impacted data accuracy. The change now limits these calculations to ongoing payslips, ensuring more precise and reliable payroll processing. This improves the overall stability and accuracy of the HR module.
Original PR description
Before this commit, `_compute_basic_net` was not limited to specific payslips, potentially affecting thousands of records and even more of `hr.payslip.line` records. This commit restricts the compute to ongoing payslips. task-6022499 Forward-Port-Of: odoo/enterprise#111219 Forward-Port-Of: odoo/enterprise#110069
This update fixes an issue where project timesheets didn't accurately reflect changes in manufacturing employees. The fix automatically updates the AAL (analytic accounting line) associated with the work center when an employee is switched, ensuring accurate timesheet calculations and reporting. This improves the reliability of project cost tracking.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#111040 Forward-Port-Of: odoo/enterprise#109695
This update fixes a usability issue on mobile devices where a key button for loan calculations was hidden within a dropdown. The change ensures a smoother, more intuitive experience when creating new loans on smartphones and tablets, allowing users to easily access necessary features.
Original PR description
Forward-Port-Of: odoo/enterprise#110931 Forward-Port-Of: odoo/enterprise#110120
This update adjusts how Odoo refreshes its GST tokens, moving from automated scheduling to manual triggering. This change ensures compliance and reduces the risk associated with automatic token updates. The process is now controlled by specific actions within the system.
Original PR description
With this PR, the GST token refresh cron interval is updated from 5 hours to 9999 months to effectively disable automatic execution. The cron will instead be triggered manually from `validate_otp` and `_cron_refresh_gst_token` based on the token expiration time. Forward-Port-Of: odoo/enterprise#109937
This update fixes an issue where portal users weren't able to view timesheets linked to projects with 'Invited internal and portal users' visibility. The change expanded the domain to include both 'portal' and 'invited_users' visibility options, ensuring portal users can access timesheets as intended.
Original PR description
Steps to reproduce: - Create Project A with visibility set to `Invited internal and portal users.` - Create a Helpdesk Team and assign Project A to it. - Create a helpdesk ticket. - Log a timesheet…
Steps to reproduce:
- Create Project A with visibility set to `Invited internal and portal users.`
- Create a Helpdesk Team and assign Project A to it.
- Create a helpdesk ticket.
- Log a timesheet on the ticket and share the ticket with the portal user.
- Log in as the portal user and check the timesheet.
- Observe that the timesheet is not visible to the portal user.
Cause:
- After introducing the `invited_users` option in `privacy_visibility`, the portal domain in `_timesheet_in_helpdesk_get_portal_domain` was not updated.
- The domain was still defined as: `('project_id.privacy_visibility', '=', 'portal')`
- As a result, timesheets linked to projects with visibility set to “Invited internal and portal users” were excluded from the portal user’s view.
Solution
Update the domain to include both visibility options: `('project_id.privacy_visibility', 'in', ['portal', 'invited_users'])`
- This ensures timesheets are visible to portal users when the project visibility is either portal or invited_users.
task-5924243
Forward-Port-Of: odoo/enterprise#111548
Forward-Port-Of: odoo/enterprise#107800This update ensures the 'To-Do' feature within Odoo Enterprise works reliably. Previously, uninstalling the 'To-Do' module could cause issues, as the feature remained active. This change guarantees that 'To-Do' is properly installed, resolving potential problems for users.
Original PR description
This commit backports the `project_enterprise_hr_todo` bridge module that ensures that `project-todo` is correctly installed in order to use the todo mail alias feature. Before, this requirement was not enforced so anyone uninstalling To-Do could experience some issue, as the feature would still be part the `project_enterprise_hr` module, even without `project_todo` installed. Forward-Port-Of: odoo/enterprise#109194
This update resolves an issue where payrun creation failed for employees with contracts starting mid-period. The fix ensures the system correctly handles contract start dates, preventing errors and allowing accurate payroll processing. This improves the reliability of pay runs for new hires.
Original PR description
An error is thrown when an employee's contract starts mid-period. ```py Invalid Operation Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Payslip -…
An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```
Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown
Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.
Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.
target: saas-18.4
task-6034836
Forward-Port-Of: odoo/enterprise#111007
Forward-Port-Of: odoo/enterprise#110568This update corrects a problem where appraisal dates weren't being calculated correctly due to a timing issue in the testing process. The fix ensures that appraisal dates are accurately determined based on company settings related to appraisal plans, improving the reliability of employee appraisal scheduling.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111345 Forward-Port-Of: odoo/enterprise#111265
18 changes
Enhancements to existing features
This update ensures that follow-up reminders are consistently sent to customers, even when a large volume of reminders are queued. The system now automatically re-triggers the reminder process if there are still outstanding reminders, preventing delays and improving customer communication. A configurable batch size allows users to optimize the process for their specific needs.
Original PR description
In case there is a lot of followup to process, the followup cron doesn't retrigger and we have to wait the next day for them to be sent. This commit make use of the ir.cron progress API so that the cron is retriggered if there are followup left to be sent. We also make the batch_size configurable to that a user could tune it on the cron. opw-6042472 Forward-Port-Of: odoo/enterprise#110918
This update allows HR staff to create leave entries for Swiss employees even when payroll impacts are present, offering greater flexibility in managing employee time off. The change relaxes previous restrictions based on payroll data, ensuring accurate leave tracking while accommodating various Swiss payroll scenarios. This improves the usability of the HR module for our Swiss clients.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
Resolved issues and error corrections
This update resolves an issue where the topbar menu wasn't correctly updated after a user opened a menu using an AI Agent. The fix ensures the topbar accurately reflects the currently active menu, improving the user experience when interacting with AI-powered features. This enhances usability and consistency.
Original PR description
Purpose: -------- When a menu (view) was opened through an AI Agent, the menu in the topbar was not updated. This commit fixes this behaviour by setting the menu when the menu's action has been loaded Task-6017607 Forward-Port-Of: odoo/enterprise#109929
This update automatically calculates and transmits the required perception commission for Swiss employees through the Swissdec system. This ensures accurate and timely reporting for tax compliance, addressing a previous issue with manual calculations. The change impacts the l10n_ch_hr_payroll module.
Original PR description
task-6050810 Forward-Port-Of: odoo/enterprise#111143
This update resolves a problem where the website's tour process was failing due to timing issues, particularly with translation loading in recent Chrome versions. The fix adds a temporary step to ensure translations load before the tour continues, preventing interruptions and ensuring a smoother user experience.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update resolves a test issue where simultaneous data synchronization in the Point of Sale (POS) tax module caused errors. The fix ensures that backend calls complete before the test continues, improving test reliability and preventing disruptions. This enhances the overall stability of the POS tax functionality.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
This update corrects a bug where changes to view ordering within the Odoo Studio were not being applied correctly. The fix involved updating the default order setting to be applied through the designated `defaultOrderBy` attribute on the related model, ensuring consistent view ordering for users.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update resolves an issue with automatic GST token refreshes in the Odoo Enterprise system. The automatic refresh process has been disabled, and now the refresh is triggered manually when needed, ensuring compliance and reducing potential operational overhead. This change improves stability and control over token management.
Original PR description
With this PR, the GST token refresh cron interval is updated from 5 hours to 9999 months to effectively disable automatic execution. The cron will instead be triggered manually from `validate_otp` and `_cron_refresh_gst_token` based on the token expiration time. Forward-Port-Of: odoo/enterprise#109937
This update clarifies error messages related to Instagram integration (code 9004) within the Odoo Enterprise platform. The change provides users with more helpful guidance when encountering these issues, reducing the need to contact support. This improves the overall user experience and stability of the Instagram feature.
Original PR description
Purpose ======= Explain the possible errors for the code 9004, to help users debugging their Odoo servers without creating a ticket. Task-5972197 Forward-Port-Of: odoo/enterprise#110571 Forward-Port-Of: odoo/enterprise#109319
This update corrects a visual issue in the accounting reports where the company header was grayed out in dark mode. The change ensures consistent branding and a better user experience by using a standard muted data color, aligning with the overall design of the application.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#111509 Forward-Port-Of: odoo/enterprise#110108
This update resolves an issue where long tax amounts in Ke revenue reports were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the numerical size, improving the clarity and accuracy of financial reports. This enhancement impacts the user experience for Ke revenue reporting.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
This update fixes an issue where the Gemini AI feature sometimes returned empty responses to users, creating a confusing 'broken' experience. The fix automatically retries the request with a slightly increased processing budget and, after three attempts, gracefully informs the user of the failure. This ensures a more reliable and consistent AI experience.
Original PR description
It often occurs that gemini responses come back empty without anything to show to the users. Specifically, the response object has content but the "parts" are empty - the place were you either get a function call or a message to the user by the LLM. Prior to this commit, when this occured, we didn't perform any explicit handling. We would always just return what the LLM responded with, which when empty would be nothing. UX wise, it would seem like something broke because the user would basically get no reply. In this commit, we add a retry mechanism in `_request_llm_google` of `llm_api_service.py`, where if we get no response, we increase the thinking budget of the next request to 512 and try again. 512 tokens were chosen completely arbitrarily - anecdotally, the model should use around 300 thinking tokens for its tasks so 512 should be enough. After 3 unsuccessful tries, we send a failure response to the user. Task-5959805 Forward-Port-Of: odoo/enterprise#108755
This update fixes a bug where project timesheets didn't accurately reflect changes in manufacturing employees. The fix automatically updates the AAL (analytic accounting line) associated with the work center when an employee is switched, ensuring accurate tracking of labor costs on the project dashboard. This improves the reliability of project cost reporting.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#111040 Forward-Port-Of: odoo/enterprise#109695
This update resolves an issue preventing invoices with the ICBPER tax code from generating correctly. The fix addresses a technical problem related to how the system handles fixed taxes, ensuring invoices with this tax type now process without errors. This improves the accuracy of invoice generation for Peruvian businesses.
Original PR description
**Steps to reproduce:** 1. Install module `l10n_pe_edi`. 2. Switch company to PE. 3. Create a tax: - Name: ICBPER - Amount type: Fixed - Code: ICBPER - Amount: 0.5(e.g.) - Set the tax group to ICBPER…
**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
- Name: ICBPER
- Amount type: Fixed
- Code: ICBPER
- Amount: 0.5(e.g.)
- Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).
**Issue:**
Processing the invoice raises:
AttributeError: 'dict' object has no attribute '_get_downpayment_lines'
**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.
During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
- With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
- With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.
**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error
**opw-5809939**
Forward-Port-Of: odoo/enterprise#108638This update resolves issues related to how client IDs are formatted within the Odoo Enterprise payroll module (l10n_be_hr_payroll). Specifically, it adapts to a new naming convention for Client IDs, ensuring compatibility and preventing potential errors. The changes also include several bug fixes related to connection and configuration processes within the payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#111276
This update resolves an issue where CFDI reports incorrectly displayed '99 - False' instead of '99 - Por definir' for payment method 99. The fix ensures that the report accurately reflects the payment method selected during invoice creation, improving report accuracy for Mexican tax compliance.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves issues with overtime calculations related to employee timezones. Previously, the system incorrectly handled overlapping attendances and failed to properly delete outdated overtime lines, leading to inaccurate reporting. This fix ensures accurate overtime tracking regardless of employee timezone settings.
Original PR description
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a…
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)". Steps to reproduce (stale overtime lines): With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed. The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`. The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Solution: - In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day. - In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors. - In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle. opw-5931665 Forward-Port-Of: odoo/enterprise#109419
This update corrects a problem where appraisal dates weren't being calculated correctly due to a timing issue in the testing process. The fix ensures that appraisal settings are properly applied before test employees are created, resulting in accurate appraisal date calculations for employees.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111345 Forward-Port-Of: odoo/enterprise#111265
7 changes
Resolved issues and error corrections
This update resolves an issue where prompts within email templates weren't being evaluated correctly in version 18.4. The fix ensures that all prompt content is wrapped in a `<div>` tag, preventing errors and guaranteeing prompt evaluation during template previews. This improves the functionality of the AI composer feature.
Original PR description
Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element. Steps to…
Note: In 18.4, the editor inserts a space before and after the prompt container, in which case the following steps won't cause an error because the container won't be the only html element. Steps to reproduce: - Create a new email template. - Insert a prompt by using the '/prompt' command. - Type any prompt like 'Say Hello'. - Save the email template. - Click on preview. - The prompt isn't evaluated. The '_eval_ai_prompts' method creates a root element from the passed html content. When the passed content represents a single prompt container html element, the root will become that prompt container. The method will try to evaluate the prompt and replace the prompt container and then return the root. The returned root won't contain the evaluation of the prompt in this case because the whole root should be replaced by the evaluation given that there is no other elements. To fix this, the html content will always be wrapped in a `<div>` to avoid the need for replacing the whole root element.
This update fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payslip data, which was resolved by recalculating the data based on payslip line items. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update relaxes a restriction that previously prevented leave creation when payroll data was present for an employee. Now, leave can be created under specific conditions related to payroll impact and disability percentages, ensuring greater flexibility for HR teams. This change improves the usability of the leave management system.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
This update fixes an issue where the SDWorx payroll report didn't account for public holidays. The change ensures that employee attendance is accurately calculated, reflecting actual working days as defined by public holidays. This improves the reliability of payroll reporting.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070 Forward-Port-Of: odoo/enterprise#106065
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111537 Forward-Port-Of: odoo/enterprise#111290
This update fixes an issue where repositioning a signature within the PDF viewer caused inconsistent resizing behavior due to multiple event listeners. The change ensures only one resize listener is attached, resulting in a more reliable and predictable resizing experience for users. This improves the overall usability of the signature feature.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111520 Forward-Port-Of: odoo/enterprise#111146
This update fixes an issue where multi-select rectangles on scaled PDF signature pages were inaccurately drawn, leading to incorrect selections. Additionally, the fix addresses a potential error when dropping elements and ensures helper lines align properly during dragging. This enhances the reliability and usability of the signature process.
Original PR description
When drawing the multi-select rectangle on scaled PDF pages, the rectangle corner was not properly synchronized with the mouse pointer, leading to inaccurate selection. Additional fixes: - An uncaught error could be triggered when dropping elements on the page. - Helper lines during dragging were not accurately aligned around sign items. task-6049004 Forward-Port-Of: odoo/enterprise#111156
18 changes
Enhancements to existing features
This update loosens restrictions on creating leave for employees with Swiss payroll, allowing leave entries even when payroll impacts are present under specific conditions. Previously, leave creation was blocked if a payslip was validated. Now, certain scenarios – primarily related to continued pay percentages – are permitted, improving flexibility for HR processes.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
Resolved issues and error corrections
This update fixes a bug where users could confirm popups with empty input fields, such as gift card codes. Now, the confirmation button is disabled if the input is blank or contains only spaces, ensuring data integrity and preventing incorrect transactions. This impacts key features like adding floors and generating gift cards.
Original PR description
*= point_of_sale, pos_loyalty, pos_restaurant Before this commit: =================== - User was able to confirm `TextInputPopup` with an empty input value. Affected functionalities: - Add New Floor - Rename Floor / Table - Enter Code (Gift card or Discount code) - Generate a Gift Card After this commit: ================== - The confirm button will be disabled if the input value is empty or has only spaces so that an empty string will not be accepted. Task-6019160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254994 Forward-Port-Of: odoo/odoo#253307
This update resolves an issue where cross-origin requests with the Range header were failing due to preflight checks. The change adds the necessary header to allow these requests to succeed, improving the reliability of external integrations. While future customization is considered, this fix addresses a specific, previously undetected problem.
Original PR description
Previously, specifying the Range header in a CORS request would result in a preflight failure even if cors was enabled on the route. It is sometimes desirable to allow querying ranges even in a CORS context. It may be desirable at some point in the future to allow controllers to customize their preflight responses more thoroughly, but considering this hasn't really be an issue before, it seems premature. Instead, this commit just adds the Range header to the Allow-Control-Allow-Headers response header to allow such requests to succeed. Forward-Port-Of: odoo/odoo#254805
This update fixes a technical error that prevented the generation of 281.10 reports for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payroll data, which was resolved by recalculating vehicle information using pay slip line IDs. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving invoice clarity for users. This impacts the Ke edition of Odoo Enterprise.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
This update resolves a recurring issue where the Italian POS printer would generate errors when the system was offline. The fix adds a safety mechanism to gracefully handle network disruptions during receipt printing, preventing errors and improving the user experience for Italian businesses using the POS module. This ensures reliable operation even without an internet connection.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#110326 Forward-Port-Of: odoo/enterprise#105515
This update fixes a formatting issue in Odoo's XML files related to Danish VAT returns (OIOUBL21). The 'DK' prefix was missing, which is now added to the PartyIdentification text to ensure compliance with Danish tax regulations. This ensures accurate data transmission and avoids potential processing errors.
Original PR description
In this commit af94099c4d74e9c48251a1c1656e3ad11b9f8a70, we made a fix regarding OIOUBL21 XML files, but we forgot to add the 'DK' prefix for CVR nemhandel identifier. The format should be 'DK' + nemhandel_identifier_value. no-task Forward-Port-Of: odoo/odoo#254430
This update addresses a previous issue where exporting XML from bills resulted in incorrect customer and supplier information. The button has been removed for non-self-bill invoices to prevent customer confusion. This ensures data integrity during import processes.
Original PR description
Problem --------- Currently, in the bills list view, when you select bills > Print > Export XML; not-imported bills gets their customer and supplier party inverted. This is because the XML export of those trigger the XML computation which is not designed for bills but only for invoices or self-bills. For imported bills (coming from Peppols for example), we re-use the imported XML. Since XML export of created bills is not supported anymore. The button leaves customers confused as to why their partner are inverted in the XML. Solution --------- Don't show the "Export XML" if one or more move are selected for the import and don't compute the XML for bills that are not self-bills. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where multi-select rectangles on scaled PDF signature pages were inaccurately drawn, leading to incorrect selections. Additionally, the update resolves a potential error when dropping elements and ensures helper lines align correctly during dragging. This improves the overall usability and reliability of the signature process.
Original PR description
When drawing the multi-select rectangle on scaled PDF pages, the rectangle corner was not properly synchronized with the mouse pointer, leading to inaccurate selection. Additional fixes: - An uncaught error could be triggered when dropping elements on the page. - Helper lines during dragging were not accurately aligned around sign items. task-6049004
A bug in Odoo's testing framework was causing freezes due to an infinite loop. This has been resolved by switching from an array to a set data structure, preventing the framework from repeatedly accessing the same data and avoiding the loop. This ensures the stability of the Odoo system.
Original PR description
Problem: Triggering the `child_of` operator in the testing framework caused an infinite loop that froze Odoo. This occurred because the framework attempted to fetch all children of the root operand without accounting for already visited nodes, resulting in children being added indefinitely. Solution: Switched from using an `array` to `set` to prevent duplicate traversal. Task-6023290 Forward-Port-Of: odoo/odoo#255067 Forward-Port-Of: odoo/odoo#254857
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111439 Forward-Port-Of: odoo/enterprise#111290
This update ensures that all required address fields (street, city, zip, state, and country) are included when generating seller addresses on e-invoices for Viettel. This change is necessary to meet Viettel's EDI requirements and avoid potential invoice rejection issues, ensuring compliance and accurate reporting.
Original PR description
The seller address on e-invoices was missing some fields. This commit updates the logic to include street2, city, zip, state, and country when generating the seller address, ensuring full address details are provided in compliance with Viettel EDI requirements. task-6040875 Forward-Port-Of: odoo/odoo#254564
This update fixes an issue where repositioning PDF sign items caused inconsistent resizing behavior due to multiple event listeners being attached. The change ensures only one resize listener is registered, resulting in a more stable and predictable user experience when working with PDF signatures. This improves the reliability of the sign request process.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111146
This update corrects a bug where a down payment line was incorrectly added twice to POS order settlements when automatic invoicing was enabled. The fix ensures that only the initial down payment line is processed, preventing data duplication and ensuring accurate order totals. This improves the reliability of POS transactions.
Original PR description
Case 1: --- **Steps to produce:** - Install `pos_sale` module. - Enable `Automatic Invoice` in settings - Create a new SO with product price 1000. - In `Other Info`, set `Online Payment` to 30%. -…
Case 1: --- **Steps to produce:** - Install `pos_sale` module. - Enable `Automatic Invoice` in settings - Create a new SO with product price 1000. - In `Other Info`, set `Online Payment` to 30%. - Preview > make payment > down payment of 300 is created in SO. - In POS, open Furniture Shop register > Actions > Quotation/Order > select the SO > settle order. **Issue:** - The down payment line is added twice in the POS order. **Root cause:** - At [1], `sale_order.amount_paid` = 300, so `addDownPaymentProductOrderlineToOrder` adds the line in order. - At [2], the down payment line from the SO is added again. - Here, when `Automatic invoice` is on and we make the online payment then `amount_paid` is updated and the downpayment invoice is also created. - So, we have also downpayment line in sale order also. **Solution:** - Ensure that if a downpayment line has already been added to the POS order, the first downpayment line matching `amount_paid` is skipped. [1]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L88-L93 [2]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L109-L111 Before: <img width="484" height="279" alt="image" src="https://github.com/user-attachments/assets/c803c9bd-0751-4a90-81f4-8fb3da3b393e" /> After: <img width="490" height="235" alt="image" src="https://github.com/user-attachments/assets/2ec4ac43-1db3-4c2e-bfcf-8c52a4830dac" /> Case 2: --- **Steps to produce:** - Install `pos_sale` module. - Enable `Automatic Invoice` in settings - Create a new SO with product price 1000. - In `Other Info`, set `Online Payment` to 30%. - Preview > make payment. **Issue:** -The computed value of amount_unpaid is 400, whereas it should be 700. **Root cause:** - When Automatic Invoice is enabled and an online payment is made, the invoice is automatically created and amount_paid is also updated. - At [3], the logic subtracts both the total invoice amount and amount_paid from the actual total, which results in an incorrect calculation. **Solution:** - When an online payment is made, a transaction is created and linked to an invoice. - While computing the total invoice amount, if the transaction’s invoice ID is encountered again, it should be skipped to avoid double-counting. [3]: https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51 opw-5415404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254964 Forward-Port-Of: odoo/odoo#242026
This update fixes an issue in our tax reporting calculations, specifically when using 'trimester' tax periods. The previous calculation incorrectly identified date boundaries, leading to inaccurate report values. This change ensures correct reporting for carryover tax scenarios, improving data accuracy for financial reporting.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111330 Forward-Port-Of: odoo/enterprise#110504
This update corrects a bug that was causing incorrect leave calculations within the holiday accrual process. The issue stemmed from an inconsistent field being used instead of the correct variable, which could lead to an infinite loop. This fix ensures accurate leave accruals and prevents potential errors.
Original PR description
## Issue Oblivion regarding community-239836 The field `leaves_taken` (which shouldn't be accessed from the `_process_accrual_plans` method because it is inconsistent/can lead to infinite loop, see the related PR explanation) is used instead of the variable `leaves_taken`. robodoo up to saas-18.4 included Forward-Port-Of: odoo/odoo#253076
This update improves how charges are handled on invoices generated for UBL/BIS3 transactions. Instead of creating a new invoice line for charges, the charge amount is now directly added to the original invoice line's price unit. This ensures accurate and consistent reporting of charges on invoices.
Original PR description
Before this commit: A charge in an InvoiceLine was creating a new invoice line with the amount of the charge. After this commit: The charge is added in the price unit of the original line --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254620 Forward-Port-Of: odoo/odoo#254111
This update ensures the SDWorx payroll report accurately reflects employee attendance by now considering public holidays. Previously, the report didn't account for resource calendar leaves, leading to incorrect attendance calculations. This fix improves the accuracy of payroll reporting for Belgium.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070 Forward-Port-Of: odoo/enterprise#106065
8 changes
Resolved issues and error corrections
This update fixes a bug that prevented users from adding reactions to messages within the 'mail_group' module in Discuss. The fix ensures the 'add reaction' button isn't displayed for message types that don't inherit from the standard message structure, improving stability and usability.
Original PR description
Steps to reproduce: - Install the mail_group module - Open Discuss - Go to the History tab - Add a reaction on a message that has model mail.group - Throws an error The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`. community: https://github.com/odoo/odoo/pull/218615 Task-5098050
This update resolves an issue where the CFDI payment method '99' was incorrectly displayed as 'False' in reports. The fix ensures that '99 - Por definir' is shown accurately, aligning with Mexican tax regulations. This ensures correct reporting for invoices generated with the mx company.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111051 Forward-Port-Of: odoo/enterprise#107267
This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML adheres to current Swiss banking standards, improving payment processing accuracy and compliance. It also includes enhancements for validator schema and QR-IBAN support.
Original PR description
**PROBLEM** According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured. This isn't the case when generating a xml for the payment method iso20022_ch. **STEP TO REPRODUCE** 1. install l10n_ch and account_iso20022. 2. Create a swiss contact with a full address. And activate payment on the bank account of this contact. 3. Select the Company CH, and set a bank account in the bank journal configuration. 4. Create a vendor payment to the swiss contact. 5. Create a batch payment with it, and validate to get the xml. 6. Open the xml, and notice the PstlAdr isn't structured. Ticket [link](https://www.odoo.com/odoo/project.task/5880247) opw-5880247 Forward-Port-Of: odoo/enterprise#107025
This update automatically calculates and transmits the required commission payments (ELM) for Swiss payroll, streamlining the process for our Swiss clients. The change ensures accurate reporting to Swiss tax authorities, reducing the risk of errors and improving compliance. This update impacts the Swiss payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#111143
This update ensures that changes to a subscription's salesperson are automatically reflected for all associated contacts. Previously, updates only applied to the company partner, leading to inconsistencies. This change improves data accuracy and reduces the need for manual updates, streamlining the portal experience.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271 Forward-Port-Of: odoo/enterprise#108339
This update fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payslip data, which was resolved by recalculating the necessary information. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update fixes an issue where repositioning PDF signs within the Odoo interface caused erratic resizing behavior due to multiple event listeners. The change ensures only one resize listener is attached per sign, resulting in a more reliable and predictable resizing experience for users. This enhances the overall usability of the PDF sign functionality.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111146
This update fixes an issue in how tax reports calculate period boundaries, particularly when using 'trimester' tax periods. The change ensures accurate reporting by correctly identifying the relevant tax period for calculations, preventing incorrect values being displayed in reports. This improves the reliability of financial reporting.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111330 Forward-Port-Of: odoo/enterprise#110504
11 changes
Resolved issues and error corrections
This update fixes an issue where users weren't receiving email notifications for signature requests when their notification preferences were set to 'inbox'. Now, all signature requests will trigger email notifications, ensuring signers are promptly informed. This change maintains in-app visibility for users who track requests within Odoo.
Original PR description
When a user's notification preference is set to "inbox", no email is sent, which may prevent signers from being notified of signature requests. This commit enforces sending email notifications for signature requests regardless of user notification settings. Notifications are still created in Odoo, preserving in-app visibility for users who rely on it. task-6041834
This update corrects a bug where changes to view order within the Odoo Studio interface weren't consistently applied. The fix involved updating the code to properly set the default order for views using the designated attribute on the relational model. This ensures that view order changes made through the Studio are now correctly reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111395 Forward-Port-Of: odoo/enterprise#111091
This update resolves an issue where long tax amounts in Ke EDI reports were causing display problems. The fix ensures that tax totals are accurately and clearly presented, regardless of the numerical size. This improves the readability and usability of invoices generated using the l10n_ke_edi_oscu module.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#111003 Forward-Port-Of: odoo/enterprise#100319
This update resolves an issue where the calculation of employee appraisal dates was inconsistent. The fix ensures test employees are created *after* company appraisal settings are configured, leading to accurate appraisal date calculations. This improves the reliability of appraisal scheduling within the system.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719 Forward-Port-Of: odoo/enterprise#111265
This update automatically calculates and transmits the necessary commission payments related to employee earnings for Swiss payroll (l10n_ch_hr_payroll). Previously, this calculation was manual, and this change streamlines the process, ensuring accurate and timely reporting to Swiss tax authorities. This improves compliance and reduces the risk of errors.
Original PR description
Forward-Port-Of: odoo/enterprise#111143
This update fixes an issue where DATEV exports were inaccurate when a move line's account was changed. Now, updating a move line's account automatically recalculates the DATEV main account, ensuring the exported data correctly reflects the current financial accounts. This prevents duplicate lines in DATEV reports.
Original PR description
Description of the issue this commit addresses: When the account of a move line is updated (e.g. replacing the suspense account with the actual one), l10n_de_datev_main_account_id was not recomputed which leads to an incorrect DATEV export with duplicate lines. Desired behavior after this commit is merged: Changing the account_id of a move line recomputes l10n_de_datev_main_account_id so that the exported DATEV data reflects the current accounts of the move.
This update corrects a technical issue in how Odoo processes top-up payments for UK accounts. The data structure for UK accounts differs from the EU, requiring a change to the system's location data retrieval. This ensures accurate payment processing for UK customers.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground
This update resolves an issue where night shift slots (e.g., 20PM - 4AM) were not visible in the weekly planning view. The fix adjusts how the system displays multi-day slots, ensuring all scheduled hours are accurately shown. This improves the planning experience for employees with flexible work arrangements.
Original PR description
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish…
**Steps to reproduce** 1. Have an employee using a flexible schedule 2. Create a slot from e.g. 20PM to 4AM for this employee. Make sure this is the only slot that week for the employee. 3. Publish the Schedule and send it to the employee. Open the outgoing mail to access the link to the planning view. Issue: the slot is not visible in the week view. **Cause** https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194 The `event_hour_min` and `event_hour_max` returned by `planning_get` and used to control the min/max hours displayed in the week view, didn't account for slots over multiple days. For a slot between 20pm and 4am, the `event_hour_max` should be the end of the day, and the `event_hour_min` should be the start of the day. **Solution** - we change the `event_hour_min` and `event_hour_max` for multi-day slots to display the full days in the week view - the previous point has the drawback of displaying the full days for non-flexible employees even when not necessary. This is because `slots_start_datetime` and `slots_end_datetime` contained the `planning.slot` start and end. Instead, we can look at the actual slot values displayed (by `_get_slots_vals`). For example, a 5 day slot for a non-flexible employee may contain actual slot values corresponding to a typical 8-17 working day. opw-5245985 Forward-Port-Of: odoo/enterprise#99784
This update ensures that payroll payslips with analytic rules are correctly anonymized, preventing individual employee lines from appearing in aggregated accounting moves. The fix addresses a technical issue related to how analytic distributions are processed, enhancing data privacy and compliance. A new test has been added to verify the fix.
Original PR description
The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to…
The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to enforce privacy and avoid having lines for each employee in the payrun. If salary rules with analytic distributions are involved, though, the lines are not merged and we lose the anonimity.
This happens because in the _get_existing_lines funciton, that should return the lines to be merged with the input line (line), the condition for the rules that have an analytic distribution is wrong.
In particular, the condition is wrong because the
distribution_analytic_account_ids field is a recordset of the accounts, while line_id['analytic_distribution'] is a dictionary with keys that are comma separated strings of the ids of the accounts, with values reflecting the percentage.
For example, if a rule has one analytic distribution for 40% and involving accounts 13,7 and 12 + another analytic distribution for 60% involving accounts 3 and 5, line_id['analytic_distribution'] will be {'13,7,12': 40.0, '3,5': 60.0} while distribution_analytic_etc will be a recordset containing (13,7,12,3,5). To fix the problem and keep everything inline, we extract the logic to a new function, where we first unravel the ids from the keys of the dictionary and only then try to match them to the values in the recordset.
Task: 6043957This update ensures the 'mark as complete' button is always visible when closing a return flow, regardless of whether the user is using the API or a manual upload. This resolves an issue where the button was hidden for certain localization setups and temporary API connection problems, allowing users to consistently finalize return processes.
Original PR description
When a flow is already started, the button "mark as complete" on returns was invisible. This is an issue for some localizations that don't handle the flow when the API connection is not desired by the user. Another use case, for example, is the API connection is down temporarily, the user manually uploads it on the website, then wants to close the started return.
This update relaxes a restriction that previously prevented leave creation when payroll data was active for an employee. Now, leave can be created under specific conditions – primarily when payroll impact is false, or when continued and disability payments are both 100% if payroll impact is true. This improves flexibility in managing employee time off.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
13 changes
Enhancements to existing features
This update allows employees to create leave requests even when a payroll record exists for that period. Previously, leave creation was blocked if payroll was validated. This change relaxes the rules, enabling more flexible leave management while maintaining accurate payroll calculations, specifically addressing scenarios related to Swissdec payroll impact.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
Resolved issues and error corrections
This update corrects a bug in the MX CFDI invoice generation process. Previously, the required 'NumeroPedimento' information was missing, leading to invoice rejection. The fix ensures that the correct pedimento number is included in the generated CFDI documents, complying with Mexican tax regulations.
Original PR description
The numero pediemento is missing in invoices CFDI Step to reproduce: - in MX company with l10n_mx_edi_landing - create an invoice - add product with a custom number (with 2 spaces between number ranges) - Confirm and send The generated CFDI is missing the `InformacionAduanera` node and its `NumeroPedimento` attribute. Cause: Node and attribute are filled in the CFDI from the 'complementos_list'. Which is a copy of each base_line 'l10n_mx_cfdi_values'. The list was missing the `informacion_aduanera_list`. opw-5949684
This update resolves an issue where non-sales users were encountering an error when viewing product information. The fix allows all users to access product pricing details by bypassing access restrictions within the product view calculation. This ensures a smoother experience for all users.
Original PR description
Steps to reproduce: - Install sale_subscription. - Create a user with access to products but no access to Sales (e.g., base.group_user). - Log in as that user and open the Products Kanban or Form view. Observation: An Access Error is raised preventing the user from viewing the products. Cause: The UI evaluates fields and view modifiers (like invisible attributes) referencing restricted data. Since product_subscription_pricing_ids is restricted to Sales groups, non-sales users trigger an Access Error when the view or the compute method attempts to read it. Solution: n the _compute_display_subscription_pricing method, use .sudo() when accessing product_subscription_pricing_ids. This ensures that the display string can be computed for all users (including those without Sales access) by bypassing the access restrictions on the underlying pricing records. opw-5934036
This update resolves an issue where dropship orders between companies were not accurately reflecting delivered quantities. The fix adjusts how the system tracks moves during dropship transactions, ensuring the correct quantity is displayed on the sale order line. This ensures accurate order fulfillment and reporting across inter-company sales.
Original PR description
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check…
**Steps to reproduce:** - Make sure you have 3 companies (comp A, B and C) - Navigate to Settings/Users & Companies/ Companies - for each company in the 'Inter Company Transactions' tab: check 'generate Sale Orders', 'generate purchase orders' and 'synchronize Deliveries to your receipts' then select a warehouse and a receipt operation type From company A - create a storable product - in the Purchase tab, set the company B as a vendor From company B - in the Purchase tab of the product, set company C as a vendor From company C - set a positive on hand quantity From Company A - create a SO for 1 quantity of your product - on the sale order line, unhide de route_id column and set it to dropship - confirm the SO and the linked PO From company B - on the SO created with company A as customer (you might need to remove the 'my quotations filter to find it), set the dropship route in the route_id column of the sale order line - confirm the SO and the linked PO From company C - confirm SO created with company B as customer - validate the delivery From company B - validate the dropship **Current behavior:** the quantity delivered on the sale order line is 0 **Expected behavior:** it should be 1 **Cause of the issue:** inside _compute_qty_delivered, we fetch the incoming and outgoing moves using _get_outgoing_incoming_moves() https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L200 There, for the move of the dropship picking, inside the if condition, move._is_dropshipped_returned() will be True https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/sale_stock/models/sale_order_line.py#L348-L354 That's because the move is going from transit to transit https://github.com/odoo/odoo/blob/b936b64ed0217909ff96a1b28d1370f5064be46a/addons/stock_account/models/stock_move.py#L186-L195 So it will not be added to the outgoing moves and qty_delivered will stay 0. **fix** is_dropshipped_returned should not prevent the move to be added to the outgoing moves if is_dropshipped() is aslo true (i.e. it's a transit to transit move) opw-5023215
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report only includes partners with total invoices and credit notes exceeding 1,000 EUR, ensuring more accurate financial reporting. The calculation considers both invoices and credit notes, and also accounts for Part B transactions.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#101333
This update fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payroll data, which was resolved by recalculating vehicle information based on payroll line items. This ensures accurate report generation.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#110860This update fixes an issue where repositioning PDF signs would cause multiple resize events, leading to unpredictable behavior. The change ensures only one resize listener is attached per sign, resulting in a more stable and reliable resizing experience for users. This improves the overall usability of the PDF sign functionality.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111146
This update fixes a misunderstanding regarding the date a W4 form is filed with an employer. The previous field incorrectly tracked when the form was filled out, rather than the actual filing date. This correction ensures accurate payroll processing for US HR payroll.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111213
This update corrects a legal requirement for GT EDI invoices. Previously, crucial 'complementos' data were missing from the PDF invoices generated for specific document types (FCAM, FCAP, FESP), while they were present in the XML. This change ensures compliance and accurate invoice generation.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285
This update prevents the entire reports cron job from stopping if a single report export fails. Previously, an error would halt the entire process. Now, the cron will continue to attempt exporting other reports, ensuring a more reliable and complete report generation.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#105191
This update fixes a bug related to currency rate calculations for Bulgaria. After the country switched to the Euro, the system was incorrectly using reversed rates from the data source. The change adjusts the parsing process to use the correct 'RATE' value, ensuring accurate currency conversions.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update fixes an issue where the SDWorx payroll report wasn't correctly accounting for public holidays. The change ensures that employee attendance is accurately calculated, reflecting scheduled holidays and improving payroll report accuracy. This resolves a discrepancy in reporting for employees on leave during public holidays.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070 Forward-Port-Of: odoo/enterprise#106065
This update resolves an issue where users were directed to the wrong document form view when configuring PEPPOL document syncing settings. The change adds a dedicated Kanban view for managing PEPPOL documents, ensuring users access the correct interface for organizing and accessing these important files. This improves the user experience and streamlines document management.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802
5 changes
Resolved issues and error corrections
This update fixes an issue where currency rates were incorrectly calculated after Bulgaria transitioned to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. The fix ensures accurate currency calculations by using the correct 'RATE' value from the XML.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519
This update resolves a minor issue with a message displayed in the HR payroll documents. The fix ensures accurate and consistent reporting, preventing potential confusion or errors in payroll processing. This change improves the reliability of the documents generated for employees.
Original PR description
Task#5980045
This update resolves a bug preventing users from correctly changing the 'Recurring' status on subscription products with existing sales orders. The fix ensures the change is reverted properly, preventing incorrect data and improving data integrity. This update impacts subscription management functionality.
Original PR description
**Problem:** When attempting to change "Recurring" on products in the form view, if there are confirmed SOs, the change should be reverted and a message should appear explaining this. However, there is a bug in how the change is reverted where it takes the current form value of the field. This cannot be trusted as it's possible to trigger another onchange before the first one resolves, so the second onchange is based on the wrong value. **Steps to Reproduce:** - w/Demo Data, go to product "Office Cleaning Service (SUB)" (This is a subscription product which has confirmed SOs) - Quickly click the checkbox for "Recurring" twice -> Two warnings appear, but Recurring is False and can be saved **Solution:** Instead of reading the current form value and setting its opposite, we can revert to the current value on the server.
This update fixes an issue where the SDWorx payroll report didn't account for public holidays. The change ensures that employee attendance is correctly calculated, including days when the company is closed for holidays, leading to more accurate payroll reporting.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070
This update resolves an issue where scanning a barcode with a different serial number than the reserved one didn't create a new lot in stock. The fix ensures that the correct lot is always used when scanning in batches, preventing incorrect inventory tracking. This improves the accuracy of stock management.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921