Daily updates from Odoo
Navigate
Branch
Monday, January 12, 2026
190 changes
36 changes
Enhancements to existing features
This update modifies the chart of accounts for Odoo's Vietnamese localization to align with new accounting regulations (Circular 99/2025). These changes are necessary to ensure compliance with current Vietnamese tax laws, taking effect in January 2026. This update impacts financial reporting for Vietnamese businesses using the Odoo system.
Original PR description
Update the COA for the vietnamese localization, which is based on the circular 200/2014 by the new one based on the circular 99/2025. This new COA applies starting in Jan. 2026 task-5357470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243078 Forward-Port-Of: odoo/odoo#238983
This update modifies the chart of accounts for Odoo's Vietnamese localization to align with recent accounting regulations (Circular 99/2025). This change is necessary to ensure compliance with updated Vietnamese accounting standards, effective January 2026. It impacts financial reporting within the Vietnamese Odoo implementation.
Original PR description
Update the COA for the vietnamese localization, which is based on the circular 200/2014 by the new one based on the circular 99/2025. This new COA applies starting in Jan. 2026 task-5357470 Forward-Port-Of: odoo/enterprise#103823 Forward-Port-Of: odoo/enterprise#102843
This update enhances the way Odoo fetches invoices from Nilvera. Previously, only recent documents were retrieved, but now the system supports pagination and resuming interrupted downloads, ensuring all invoices are fetched in the correct order and without duplication. This improves data accuracy and efficiency.
Original PR description
Nilvera returns documents in pages of 30 items and, when no date range is provided, only returns documents created within the last week. As a result, _l10n_tr_nilvera_get_documents only processed the first page of recent documents. This commit introduces a full pagination and incremental-fetching mechanism: - Provide explicit StartDate and EndDate parameters. - Store the last successfully fetched CreatedDate per company in an ir.config_parameter to allow resuming after interruptions. - Fetch pages in ascending CreationDateTime order. This ensures all documents are fetched, in order, without duplication and without reprocessing previously downloaded data. task-5186428 Forward-Port-Of: odoo/odoo#239536
This update enhances the user experience by allowing new lines within tooltip strings displayed in tree views. Previously, tooltips were limited in their formatting, making it difficult to convey complex information. This change ensures clearer and more informative tooltips for users interacting with the Odoo application.
Original PR description
we need to add this: https://github.com/odoo/odoo/pull/239198/changes/b3b2ea48f0e8dc7c709e0e1bc5ad23750dc3cb91 in tree view as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the calculation of work time in Odoo's payroll system. Previously, the same calculation was performed repeatedly, leading to slower processing times. This change eliminates redundant calculations, resulting in a performance improvement.
Original PR description
Before the work time was calculated inside a for loop of worked_days, because this function can be called and is usually called by all worked_day_line_ids of a payslip, the same calculation is done multiple times.
Resolved issues and error corrections
A bug was causing the timer to malfunction when switching between views with sample timesheet data. This update ensures all sample records have their timers paused, preventing data conflicts and improving the reliability of the timesheet display. This resolves a technical issue impacting user experience.
Original PR description
Steps to reproduce: - Open Timesheets app, - Click on search(magnifying lens) to open on cell with no records. - Let sample record be loaded. Issue: - Timer is already started. If you switch back to grid view and stop the time it throws traceback as it has data of sample records. Reason: - The sample records can have record states that are running. Fix: - Make sure all the sample records created have their timer paused using field `is_timer_running`. - Update condition in time display to check if time is running instead using `is_timer_running` not using `time_start` and `time_pause` as `time_pause` is not an active field. task-5267303 Forward-Port-Of: odoo/enterprise#102035
This update strengthens the security of our Point of Sale (POS) system by ensuring that data is accessed securely. Previously, unauthorized access attempts could cause errors and crashes. Now, the system checks permissions before reading POS data, preventing disruptions and improving stability.
Original PR description
**: pos_hr Before this commit: --- - POS data was read directly from records without validating read access. - This could raise `AccessError` when the user lacked permissions, breaking POS data loading. After this commit: --- - Check read access on records before calling `read`. - Prevent POS crashes caused by unauthorized model reads. runbot-231708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226421
A recent issue preventing the completion of a key tour test for holiday allocation has been resolved. The problem stemmed from an empty leave type value causing form saving failures and timeouts. The fix ensures a valid leave type is always selected, guaranteeing the tour test runs successfully and accurately demonstrates the holiday allocation process.
Original PR description
Step to reproduce: - Install hr_holidays. - Run the time_off_allocation_warning_tour tour test. - The following error occurs: '(.o_form_readonly, .o_form_saved) has not been found. TIMEOUT: step failed to complete within 10000 ms'. Cause: - The leave type value is coming empty, causing the form to fail to save and resulting in a timeout. Fix: - Ensure holiday_status_id picks a valid leave type from selector. - Provide start dates and set the end dates to check the functionality. Task - 5264183 Forward-Port-Of: odoo/odoo#236639
This update resolves a technical issue within the HTML editor that could cause errors when content is completely removed after being inserted. The fix ensures the editor doesn't attempt to set a selection on a node that no longer exists in the DOM, improving stability and preventing unexpected errors. This primarily impacts the user experience when pasting and editing content.
Original PR description
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`,…
During an `DomPlugin.insert`, the inserted content is added. Then some transformations are applied to clean up, including the removal of some nodes which are inventoried into `candidatesForRemoval`, and some specific `<br>` nodes. Ultimately, the selection is set after the last inserted node. In some cases, none of the inserted content remains after the clean up. When this happens, the selection is being set after the last inserted node, which is not part of the DOM anymore, and therefore leads to an error. This commit prevents this from happening by detecting when all inserted content was actually already removed. Steps to reproduce: - In a plain web page, copy a <br> into the clipboard - In an editor, put a character on a line - Paste => An error popup was displayed task-5429909 [FIX] html_editor: avoid failing when selection nodes are disconnected This commit addresses a traceback that was spotted but for which the actual scenario remains undetermined. The only possible way this traceback may occur is if nodes inside a selection are disconnected. The test added by this commit produces the same traceback as the observed one. task-5429909 Forward-Port-Of: odoo/odoo#242941 Forward-Port-Of: odoo/odoo#242488
This update corrects a bug that caused automatic balancing lines to be added to journal entries for company-paid expenses. The fix ensures that tax calculations are handled correctly when creating these expense reports, preventing inaccurate accounting entries. This improves the reliability of expense tracking for company-paid expenses.
Original PR description
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2.…
Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line. ## Steps to reproduce 1. Create an expense paid by the company. 2. Confirm and generate the expense report. 3. Reset the expense’s journal entry to draft and add an analytic account on the first line. → An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited. ## Cause For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*. In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes. However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`. This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines. As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate. ## Solution Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`. **opw-5166707** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243052 Forward-Port-Of: odoo/odoo#233841
This update resolves an inconsistency in the SLSP reports by standardizing the order of data lines within the reports. Previously, test failures occurred due to varying data presentation. Adding a default order by clause to the SQL queries ensures a consistent and reliable report output.
Original PR description
A recent test was added that tests the lines of the SLSP reports. Up until now, all tests were either testing specific lines (not the report structure) or the export, which uses different queries. This new test is now failing inconsistently due to the order in which the data is being displayed. We add default orderby in SQL queries of the SLSP (using the models default orderby) in order to make the order consistent and avoid further issues.
This update fixes an issue where the barcode app on mobile devices displayed stock locations in a list view, which wasn't ideal for small screens. The change prioritizes a more user-friendly kanban view for mobile, ensuring product information is easily accessible on smaller devices.
Original PR description
Issue ===== On mobile, we should prioritize kanban views over list views because kanban views are usually more suitable for small device screen. That said, when a product's barcode is scanned in the Barcode app main menu, we show this product's stock locations but we do that with a list view, no matter if the user is on a big screen or a small screen. How to reproduce ================ On mobile device: - Enable location and have a product with a barcode and with quantities in two different locations; - Open Barcode app; - Scan the product's barcode => The product's stock locations are displayed in a list view, which is not very pratical on small device. Fix === The action key `mobile_view_mode` was not set, with this key, we can define what view type we want to prioritize for mobile device. [opw-5180783](https://www.odoo.com/odoo/project/49/tasks/5180783) Forward-Port-Of: odoo/enterprise#101957 Forward-Port-Of: odoo/enterprise#101336
This update resolves a bug where image styles (like width and transform) were incorrectly applied to new media types after an image was replaced. Now, styles are automatically cleared when switching between image and other media types, ensuring consistent and accurate media display.
Original PR description
**Current behavior before PR:** - When an image had styles applied to it (such as transform or width) and was replaced with another media type like an icon or document, those styles were incorrectly carried over to the replaced media. **Desired behavior after PR is merged:** - Since transform and width styles are meant to apply only to images, they are now removed when an image is replaced with other media types. task-5373362 Forward-Port-Of: odoo/odoo#240284 Forward-Port-Of: odoo/odoo#238319
This update fixes a potential issue where invoices generated from sales orders didn't always align with the correct fiscal partner information. Now, invoices use the invoice partner's details, ensuring consistent fiscal calculations across sales orders and their corresponding invoices. This improves accuracy and avoids discrepancies in financial reporting.
Original PR description
## Before this commit Fiscal position on Sale Orders was computed based on `partner_id` and `partner_shipping_id`. However, during invoice creation from a Sale Order, We uses `partner_invoice_id` as the invoice’s `partner_id`. This mismatch caused fiscal inconsistencies between the Sale Order and the generated Invoice in certain edge cases. ## After this commit Fiscal position is now computed using `partner_invoice_id` to ensure that both the Sale Order and its Invoice use the same fiscal partner reference. This aligns fiscal determination across documents and avoids inconsistencies in scenarios where the invoice partner differs from the order’s main or shipping partner. opw-5367523 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239806
This update clarifies the call settings interface for users who have muted participants. Previously, the interface was confusing, showing the 'deafen' icon with the 'unmute' label. Now, only the 'undeafen' button is displayed when a participant is muted, providing a clearer and more intuitive experience.
Original PR description
Before this commit, the hint in the call settings was not taking into account if it was deafen or mute. On top of that the icon in the menu was showing the deafen icon but with the unmute label. When deafened, this was redundant with the undeafen button as well since unmute and undeafen are practically doing the same thing. Now, when deafen is activated, only the undeafen button is shown in the call menu and the hint in the call actions is undeafen not unmute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242519
This update resolves issues that could lead to data inconsistencies when uninstalling the 'mail' module. Specifically, it ensures that model and field definitions are properly cleaned up during uninstallation and adds warnings to alert developers to potential problems with deleted records.
Original PR description
This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled. It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator. ### Add warnings…
This fixes two overrides of `unlink()` that break when module `mail` is being uninstalled.
It also fixes the uninstalling system to comply to the spec of the `ondelete` decorator.
### Add warnings when some model/field could not be deleted
The uninstallation process tries to delete all the records created by the modules being uninstalled. It uses a best-effort strategy, i.e., it skips the records that cannot be deleted, whatever the reason. But some records are very likely to cause problems, namely `ir.model` and `ir.model.fields` records, because skipping them implies not cleaning up their corresponding table's schema.
For instance, if a column is not dropped, reinstalling the corresponding module will possibly cause inconsistencies, because
- the column contains old values for existing records, which won't be recomputed (if the field is computed);
- the column contains NULLs for records created between the uninstallation and the reinstallation of the module.
We therefore add a warning in those cases, in order to detect and fix those potential issues as soon as possible.
### Make ondelete decorator work as documented
A method decorated with `@api.ondelete(at_uninstall=False)` should be called except when the method's module is being uninstalled. Currently the method is skipped when *any* module is uninstalled.
The fix consists in adding the set of modules being uninstalled in the attribute `registry.uninstalling_modules`, which may be used to detect uninstallation and determine which modules are being uninstalled.
### Replace MODULE_UNINSTALL_FLAG by new conventional flag 'force_delete'
We turn constant `MODULE_UNINSTALL_FLAG` into an explicit conventional flag, and rename it `force_delete` for the sake of simplicity. The idea is to decouple the flag from uninstallation. The caller simply uses
```py
records.with_context(force_delete=True).unlink()
```
to bypass some deletion hooks, which typically prevent deletion by raising some exception, in order to avoid data inconsistencies. On the callee's side, one has to explicitly detect the flag and skip the checks, like in:
```py
@api.ondelete(at_uninstall=False)
def _prevent_deleting_confirmed(self):
if self.env.context.get('force_delete'):
return
if any(record.state == 'confirm' for record in self):
raise UserError(_("You cannot delete confirmed records!"))
```
Note that the uninstallation process uses the convention by automatically adding `force_delete=True` in the `context` for deleting records.
### Fix issue module mail uninstallation
Two overrides of `unlink()` on models `ir.model` and `ir.model.fields` fail when uninstalling module "mail", because their code relies on some columns and those columns have been dropped already. This causes some table and column to remain after uninstallation. When reinstalling module "mail", errors like follows are logged:
```
column "mail_message_id" of relation "mail_tracking_value" contains null values
```
The fix consists in turning the overrides in proper "ondelete" methods, which are skipped when module "mail" is uninstalled.
https://github.com/odoo/enterprise/pull/103651This update resolves an issue that could cause errors during the removal of certain Odoo modules. The changes ensure that data is handled correctly when a module is deleted, preventing potential data loss or system instability. This improves the overall reliability of the Odoo Enterprise platform.
Original PR description
Companion of https://github.com/odoo/odoo/pull/242777
This update resolves an issue where pressing "Enter" in a form containing a Kanban-displayed x2many field would cause the system to crash. The fix ensures the Kanban renderer handles optional properties correctly, preventing errors and improving form stability. This ensures a smoother user experience when working with related records.
Original PR description
Be in a form view containing an x2many field displayed as a kanban view. Press "Enter". Before this commit, it crashed, because the kanban renderer tried to access it's `quickCreateState` props which was undefined. The props is indeed optional, so we must be careful when reading/using it. Issue introduced by https://github.com/odoo/odoo/pull/228632 Spotted by task~5441808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that all MOA (Monthly Accounting) values within the French accounting module are positive integers. Previously, the system could generate negative values, which caused errors. This change improves data accuracy and reliability for French tax reporting.
Original PR description
All MOA fields should be positive integer. task-5380637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242976 Forward-Port-Of: odoo/odoo#239587
This update corrects a discrepancy in the calculation of employment bonuses for the Belgian payroll module (l10n_be_hr_payroll). The changes ensure bonus calculations are accurate up to March 2026, aligning with the latest tax regulations. This update maintains accurate financial reporting and compliance for businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update fixes an issue where the timesheet timer wasn't correctly associated with the task being worked on. The fix ensures the timer uses the correct task or project from the list view, providing a more accurate and user-friendly timesheet experience. This prevents timesheets from being incorrectly linked to the user's favorite project.
Original PR description
### Issue: When looking at the list of timesheet for a task, we can start the time but the timer have default values that don't correspond to the task. ### Cause: `startTimer` in the `timesheetTimerService` is called from the timesheet timer hook without vals. It then makes an orm call to `action_start_new_timesheet_timer` to retrieve the fields (project or task) but as nothing is given in the vals, the selected project is the one returned by `_get_favorite_project_id()`. ### Solution: Get the context of the list view to retrieve the task or the project and input it in `vals`. opw-5342525 Forward-Port-Of: odoo/enterprise#102152
This update corrects a technical issue that prevented users from accessing bank accounts correctly when signing contracts within the HR module. The fix ensures a smooth and reliable process for managing contract signatures and associated banking permissions. This resolves a potential disruption to business operations.
Original PR description
Forward-Port-Of: odoo/enterprise#103807
This update resolves a bug impacting how absences are tracked within the HR Attendance module. The fix ensures accurate recording and reporting of employee absences, improving the reliability of attendance data. This change primarily affects the HR Attendance and HR Holidays Attendance modules.
Original PR description
Task: 5470030 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242567
This pull request addresses an issue with the way absences are managed within the HR Work Attendance module. The fix ensures accurate tracking and reporting of employee absences, improving the reliability of HR data. This update resolves a technical bug impacting the core functionality of this module.
Original PR description
Task: 5470030 Forward-Port-Of: odoo/enterprise#103781
This update resolves an issue where empty popups remained open and displayed incorrect options after content was removed. The fix ensures that popups are correctly closed when empty, preventing errors and improving the user experience. This improves the reliability of the website builder.
Original PR description
**Descripion of the problems** When the content of a popup is deleted, two problems happen: 1. The popup stays open displaying an empty white rectangle. 2. Options relative to the last removed…
**Descripion of the problems** When the content of a popup is deleted, two problems happen: 1. The popup stays open displaying an empty white rectangle. 2. Options relative to the last removed element are still displayed and produce an error if the user interacts with them. **How to reproduce** Drop the snippet `s_popup`, and remove the "Block" element. Problems: 1. the popup is still open but empty, 2. the "Block" options are still displayed. **Origin of the problems** Problem 1 happens simply because nothing takes care of removing empty popups. Problem 2 happens because `RemovePlugin.removeCurrentTarget` set the `nextTargetEl` without first checking if the element is activable or not. Thus, when removing the last block in a popup, the next target is set to the `.o_we_no_overlay` close button, despite it being not activable. As a result, when `BuilderOptionsPlugin.updateContainers` is called, it does not update containers because the target is not activable. Thus, the "Block" options are still displayed despite the element being removed. **Fix** Both problems are fixed by changing `RemovePlugin.isEmptyAndRemovable` such that empty popups are marked as removable. task-5401692 Forward-Port-Of: odoo/odoo#242377 Forward-Port-Of: odoo/odoo#239507
This update fixes minor inaccuracies in the German Point of Sale (POS) reporting process by ensuring the correct net value is used for pricing and by sending amounts as strings to the payment processor, Fiskaly. The changes also improve rounding precision to meet Fiskaly's requirements, and adjust order amounts for customer payments.
Original PR description
In this commit: ------------------ - Transferred **net value** instead of **gross value** for `price_per_unit`. - Included **cash statement business cases** that were prepared earlier but not sent to Fiskaly. - Ensured all **amount fields are sent as strings** to Fiskaly. - Fixed rounding precision using `toFixed()` to maintain **2–5 decimal places**, as required by Fiskaly (e.g., `4.70` should not become `4.7`). - Adjusted logic for **customer account payments** to send the **adjusted order amount** instead of the original total. task: 5122652 Forward-Port-Of: odoo/enterprise#99643
This update fixes an issue where refund alerts in the Point of Sale (POS) system could be triggered incorrectly due to rounding differences in order totals. The change ensures that the system accurately compares refund amounts against original order amounts, preventing false alerts and improving the reliability of the POS system. This update enhances the accuracy of financial reporting within the POS module.
Original PR description
Before this commit, if the total amount of the order had rounding differences compared to the sum of its lines, the system could incorrectly trigger an alert stating that the refund amount exceeds the original order amount. This was due to a direct comparison between the two amounts without considering potential rounding issues. opw-5402240 Forward-Port-Of: odoo/enterprise#103758 Forward-Port-Of: odoo/enterprise#102224
This update prevents users from creating new POS sessions when multiple online payment methods are linked to a single POS configuration. Previously, a workaround involving deleting payment methods was required. Now, a constraint ensures only one online payment method can be associated with a POS config, improving session stability.
Original PR description
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are…
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session. In addition, if a session is already open, it is no longer possible to resolve the situation: * From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method. * From `pos.config`: the payment methods field is read-only when there is an open session. We had to delete one of the online payment methods from the database directly to be able to open the POS session again. To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method. Forward-Port-Of: odoo/odoo#240343
This update addresses several issues impacting the accuracy of the social balance sheet calculations for Belgian payroll. Specifically, the system now correctly handles employees without certificates, avoids double-counting, and prevents incorrect gender checks on payslipless employees. These fixes ensure more reliable reporting for HR and accounting teams.
Original PR description
Forward-Port-Of: odoo/enterprise#103786
This update resolves a technical issue that caused warnings and potential crashes when searching for delayed production orders in the Manufacturing Orders list view. The change ensures the filter functions correctly and avoids future compatibility problems with Odoo's database system.
Original PR description
Issue before this commit: ========================= Searching for Delayed Productions in the MRP list view triggered: - A deprecation warning in saas-18.4 → 19.0: `warnings.warn("Since 19.0, use…
Issue before this commit:
=========================
Searching for Delayed Productions in the MRP list view triggered:
- A deprecation warning in saas-18.4 → 19.0:
`warnings.warn("Since 19.0, use Domain.custom(to_sql=lambda model, alias, query: SQL(...))", DeprecationWarning)`
- A traceback in master:
`Failed to cast TableSQL('mrp_production', -, None).date_finished into a datetime`
Steps to Reproduce:
=========================
- Install mrp module.
- Open the Manufacturing Orders list view.
- Filter by Delayed Productions.
- Observe the warning (saas-18.4 → 19.0) or traceback (master).
Cause of the issue:
=========================
Recent ORM changes in [PR](https://github.com/odoo/odoo/commit/f811af2c52df798b6ba0fc18e3f45944abdb7a12) disallow using raw SQL expressions as values inside normal domains.
Only Domain.custom() is permitted for injecting custom SQL.
The previous _search_is_delayed implementation used a deprecated pattern,
which caused the warning in current versions and a crash in the master version.
With This Commit:
=========================
- Rewrite the delayed production filter using Domain.custom() to safely generate the SQL.
- Preserve functional behaviour: the filter still returns delayed productions correctly.
- Avoid deprecation warnings and prevent traceback.
TaskID:- 5404547
Forward-Port-Of: odoo/odoo#243134
Forward-Port-Of: odoo/odoo#239574This update resolves a problem where the sign flow's dropdown menu wouldn't display all available styles correctly. Previously, users had to wait for a background process to complete before selecting options, leading to a limited selection. This change ensures all styles are consistently available in the dropdown.
Original PR description
In this tour, when we want to select the third dropdown item in style list menu, we must wait that the rpc get_fonts/ is done, or else, it has only one item in the menu. When the menu is opened before the call is completed, there is only one style. When it is opened after, there is all styles loaded. runbot-error-id~232652 Forward-Port-Of: odoo/enterprise#103813
This update corrects a display issue where the CFDI button was incorrectly shown on payruns that didn't meet Mexican tax requirements. The change ensures the button only appears for payruns containing Mexican payslips, improving the user experience and preventing unnecessary complexity. This fix enhances the accuracy of payroll reporting.
Original PR description
Before this commit, the computed fields `l10n_mx_cfdi_primary` and `l10n_mx_cfdi_secondary` would return True for payruns containing only non-Mexican payslips. This happened because `all()` returns True for empty iterables, causing the CFDI button to appear on payruns that have no Mexican payslips. This commit: - Adds explicit check for Mexican payslips existence before evaluating the CFDI state conditions - Hides `l10n_mx_edi_cfdi_origin` field for non-Mexican payslips - Adds test coverage for CFDI visibility on non-Mexican payruns task-5478038
This update resolves an issue where the attendance app would crash when an employee didn't have a linked calendar. The fix ensures the app handles employees with flexible schedules properly by skipping calendar periods when a calendar isn't assigned, aligning with existing flexible calendar functionality.
Original PR description
Steps to reproduce: - Create an employee - Remove the calendar to have fully flex - Open the attendance app -> traceback When an employee has no resource calendar (resource_calendar_id=False), the _gantt_unavailability method would crash with a TypeError when trying to create a ZoneInfo from calendar.tz (which is False/None). This fix adds a check to skip calendar periods where the calendar is not set, consistent with how flexible calendars are already handled. task-5462208
This update resolves an issue with how hourly wages are calculated, ensuring greater accuracy for payroll processing, particularly for employees with variable working schedules. The changes also eliminate a technical dependency issue that previously caused unexpected validation errors when managing offers.
Original PR description
- All percentage fields now use self.env.remove_to_compute to break circular dependencies, so UIs no longer need the ad-hoc skip_percentage_calc context. - _l10n_in_get_montly_wage now derives monthly hours from the version’s or its company’s resource calendar via hours/week previously it was static to 22 days. - fix raises validation when opening offer after changing working schedule it raise validation error which isn't expected behaviour. task-5421228 Forward-Port-Of: odoo/enterprise#102488
This update removes a confusing and unnecessary filter option (Templates) from project selection screens in other apps. Previously, the filter appeared globally due to a shared search view. This change simplifies the user experience and ensures consistency within the project module.
Original PR description
**Steps to reproduce:** - Open the Planning app or any app where project_id field - Click New - Click on the Project field - Click Search More - Look at the search filters - The Templates filter is visible **Issue:** The Templates filter shows up when choosing a project from there, even though it is not useful there. **Cause:** They uses the same project search view as the main project app, so the templates filter appears everywhere. **Fix:** Add a condition check in filter to make invisible in other module and show only in project. **Dev Notes (sale_project):** The context was already used for milestone display name computation, but it was missing in the sale_project override. Due to this, when Project Stages were enabled, the milestone display name did not include the deadline. task-5255295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241797
This update fixes an issue where milestone deadlines weren't shown in the Project list view. The fix ensures that milestone names now accurately include the associated deadline, providing users with clearer project timelines. This improves the usability of the Industry FSM module for project management.
Original PR description
**Steps to Reproduce:** - Install the Industry FSM module. - Navigate to Project Configuration. - Enable Milestones. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The required context was not passed in the overrided action's context, so the display_name computation did not add the deadline to the milestone name. **Fix:** Pass the appropriate context in the action to correctly compute and display the name along with its deadline. Task: 5255295 Forward-Port-Of: odoo/enterprise#103157
6 changes
Resolved issues and error corrections
This update resolves an issue where modifying milestones linked to sales orders would trigger an error. The fix corrects a misidentification of the record ID, ensuring the system correctly updates milestones associated with sales projects. This prevents disruptions to sales workflows and improves data accuracy.
Original PR description
**Issue:** A MissingError is raised when trying to modify a milestone from a sale order **Steps to reproduce:** 1. In Sales, create a quotation based on a product milestone (this creates a project + task) 2. Confirm the quotation 3. Click the Milestone button on the sale.order 4. Modify any field in the milestone list view The error “Record does not exist or has been deleted” is raised **cause:** https://github.com/odoo/odoo/blob/61116191c6b933ca9b40863774d506f219a410a1/addons/project/models/project_milestone.py#L18-L19 The active_id being passed down is the sale order id not the project id **opw-4944212**
This update corrects a display issue where archived recurring plans continued to show up as pricing options on product pages. The fix ensures that archived plans are no longer considered during pricing selection, providing a cleaner and more accurate presentation of available plans to customers. This improves the user experience and prevents confusion.
Original PR description
**Steps to produce:** - Install `sale_subscription,website_sale` module. - `Subscription > Configuration > Recurring Plans`. - `Archive` the `Monthly` plan. - Go to website > Shop > Open product `Car…
**Steps to produce:** - Install `sale_subscription,website_sale` module. - `Subscription > Configuration > Recurring Plans`. - `Archive` the `Monthly` plan. - Go to website > Shop > Open product `Car Leasing (SUB)`. **Issue:** - Even after archiving the Monthly recurring plan, its pricing still appears on the website product page. **Root cause:** - At [1], when searching for a suitable recurring price, the system does not filter out pricing records belonging to archived recurring plans. - As a result, inactive plans are still considered during pricing selection. **Solution:** - In this fix, we ensure that recurring plan pricing is included only if the related plan is active. - Archived plans are now ignored, preventing them from appearing on the website. [1]: https://github.com/odoo/enterprise/blob/25edaac85f8fd1699bb78163b01efb966e7fb680/sale_subscription/models/sale_subscription_pricing.py#L78-L79 before <img width="340" height="184" alt="recurring_plan_before" src="https://github.com/user-attachments/assets/abac39fb-5765-4bc4-aec3-87eef7135a18" /> after <img width="337" height="168" alt="recurring_plan_after" src="https://github.com/user-attachments/assets/35ee92e8-e66b-4612-add3-58b277560ea5" /> **opw-5266333** Forward-Port-Of: odoo/enterprise#103428 Forward-Port-Of: odoo/enterprise#100587
This update corrects a bug where the FAIA XML reports generated for l10n_lu companies with products having multiple taxes were missing a crucial element (`TaxBase`). This ensures accurate reporting to tax authorities, resolving a compliance issue and improving data integrity.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This update fixes an issue where the automated PDF generation for paychecks wasn't working when multiple payslips were being processed. The change ensures that PDFs are correctly generated regardless of the number of paychecks being created, improving payroll processing reliability. This resolves a bug that prevented scheduled PDF generation from functioning as intended.
Original PR description
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled…
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step) - Refuse all time off for "Anita Oliver" (to avoid side effect in next step) - Create a user for the employee "Anita Oliver" - Link the employee and the user - Create 2 payslips - 1 for "Mitchell Admin" - 1 for "Anita Oliver" - Compute sheet and confirm both payslips - Run scheduled action: "Payroll: Generate pdfs" - Nothing happens ### Cause: The traceback is raised on the line `self._get_document_partner().id` because `_get_document_partner()` can return a recordset. ### Solution: Call `ids` instead of `id`. ### Note: Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`. The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86). opw-5213979 Forward-Port-Of: odoo/enterprise#103548 Forward-Port-Of: odoo/enterprise#101911
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to employment bonuses. The changes ensure that bonus calculations accurately reflect payments up to March 2026, aligning with updated Belgian tax regulations. This update maintains accurate financial reporting for businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures the deduction accurately reflects tax regulations up to the year 2026, improving payroll accuracy for Belgian users. This fix addresses a previously identified discrepancy.
Original PR description
Forward-Port-Of: odoo/enterprise#103824
12 changes
Resolved issues and error corrections
This update fixes a visual issue where long product names in the combo configurator popup caused misalignment of product cards. The change ensures all product cards maintain consistent alignment and dimensions, regardless of name length, providing a cleaner and more professional user experience.
Original PR description
Before this commit: ================= Product cards with long names caused a slight vertical misalignment in the combo configurator popup, resulting in inconsistent card sizes within the grid. After this commit: ================== Ensure all product cards remain uniformly aligned and maintain consistent dimensions in the combo configurator popup, even when product names are long. Task:5447320 Forward-Port-Of: odoo/odoo#241720
This update corrects a bug in the l10n_lu reports that prevented the `TaxBase` element from being included in FAIA XML reports when invoices had multiple taxes. This ensures compliance with Luxembourg tax regulations and accurate reporting to tax authorities, resolving a potential data discrepancy.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This update corrects a problem with Odoo invoices generated for Danish customers (l10n_dk). The issue stemmed from using the incorrect codelist for the EndpointID, preventing the invoices from passing validation checks. This ensures invoices comply with Danish regulations and can be successfully processed.
Original PR description
**PROBLEM** Generated OIOUBL files don't pass schematrons validations. **STEP TO REPRODUCE** 1. Install the l10n_dk module. 2. Create a dk partner with an adress, and VAT number (DK12345674 for example, don't forget to add a street number for the DK Company address). 3. Create an invoice for the DK partner, and download the xml. 4. Use this validator https://oioubl.nemhandel.dk/validation (Odoo Peppol IAP validator tests oioubl version 3.0 which is not the version we want to test). **CAUSE** We used [wrong codelist](https://oioubl-demo.nemhandel.dk/oioubl/kodelister/ElectronicAddressSchemeCode-3.0.html) (oiubl3.0) for schemeID instead of the [one we should use](https://oioubl21.oioubl.dk/Codelists/en/urn_oioubl_scheme_endpointid-1.1.html) (oioubl2.1). opw-5379474 Forward-Port-Of: odoo/odoo#240586
This update corrects a discrepancy in the calculation of employment bonuses for the Belgian payroll module (l10n_be_hr_payroll). The changes ensure bonus calculations are accurate up to March 2026, aligning with the latest tax regulations. This update maintains accurate payroll reporting for our Belgian clients.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures that the deduction amount is accurately reflected up to the year 2026, aligning with updated Belgian tax regulations. This ensures accurate payroll reporting and compliance for users in Belgium.
Original PR description
Forward-Port-Of: odoo/enterprise#103824
This update corrects a technical issue where bank statements were incorrectly accessing elevated permissions. The change removes this unnecessary access, improving security and stability within the account module. This ensures data integrity and prevents potential vulnerabilities.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242899 Forward-Port-Of: odoo/odoo#242771
This update prevents users from creating new POS sessions when multiple online payment methods are linked to a single POS configuration. Previously, inconsistencies required manually deleting payment methods, leading to a frustrating user experience. Now, a constraint ensures only one online payment method is active per POS config, improving session stability.
Original PR description
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are…
Task: [#5420237](https://www.odoo.com/odoo/project/1737/tasks/5420237) --- There is a constraint on the `pos.config` model that prevents opening a POS session when multiple online payment methods are configured for the same POS config. However, from the `pos.payment.method` model, it is still possible to add multiple online payment methods to a single POS config, which then prevents opening a session. In addition, if a session is already open, it is no longer possible to resolve the situation: * From `pos.payment.method`: the POS session must be closed before removing the POS config from an online payment method. * From `pos.config`: the payment methods field is read-only when there is an open session. We had to delete one of the online payment methods from the database directly to be able to open the POS session again. To prevent this inconsistent state, a constraint is added on `pos.payment.method` to ensure that each POS config has at most one online payment method. Forward-Port-Of: odoo/odoo#240343
This update ensures that leave dates automatically recalculate when an employee's or contract's working schedule changes. Previously, leave calendars weren't updated, leading to potential inaccuracies. This fix maintains accurate leave balances by reflecting the latest schedule.
Original PR description
purpose: Accepted leaves should be recomputed upon working schedule change. - made the `resource_calendar_id` change on the leave when it's changed on the corresponding employee/contract, then forced recomputation of its dates from the new resource calendar task-id: 5424312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242381 Forward-Port-Of: odoo/odoo#241284
This update fixes a minor issue in the HTML editor's testing process. The change ensures that test actions are executed correctly, preventing redundant selections and improving the reliability of hoot tests. This enhances the overall stability of the HTML editor module.
Original PR description
The `simulateArrowKeyPress` method used in hoot tests performs both an actual `press` and modifies the selection. However, in some cases, the `press` already updates the selection because of our own listeners, which leads to a selection similar to performing the action twice. This commit avoids this by making sure the default `press` did not get prevented by our own custom listeners before modifying the selection. task-5438683 Forward-Port-Of: odoo/odoo#241604
This update fixes a technical issue that caused users to receive confusing tracebacks when errors occurred during ZATCA onboarding. Now, users will see a clear, user-friendly alert message with the actual error returned by ZATCA, improving the onboarding experience and ensuring compliance.
Original PR description
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace…
Whenever an error occurs during the ZATCA onboarding steps—such as providing a company name that exceeds 127 bytes in binary representation (for example, 64 Arabic characters without whitespace result in exactly 127 bytes; see refs [1] and [2])—the system returns a traceback to the user instead of a clear and user-friendly error message. Error: `TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType' This is due to the check-in `_l10n_sa_request_production_csid` for an 'error' key, not present in the response when an OTP is invalid because in these cases, the `_l10n_sa_call_api` returns the response_data directly. This fix improves the behaviour by displaying a user-friendly alert message with the error returned by ZATCA, instead of a traceback. This ensures a better experience and compliance with CCSID onboarding flows. [1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571 [2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960 sentry-7169834710 Forward-Port-Of: odoo/odoo#242810
This update corrects a problem in the Barcode app for Manufacturing Orders. When tracking is disabled, a manufacturing order creation process incorrectly deleted stock move lines, preventing components from being added. The fix ensures the necessary data is available before the creation process, resolving this issue and improving order accuracy.
Original PR description
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws…
Fix an incorrect flow when creating a Manufacturing Order through the Barcode app. Steps to reproduce: - Disable tracking in Settings - Create a BOM for product Table with components Wood and Screws - In the Barcode app, go to Manufacturing - Click New > Add product and select Table - Click Confirm -> Components are not added after the Table line The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected. This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`. This fix ensures that `lot_producing_id` is defined before performing the comparison. opw-5165163 Forward-Port-Of: odoo/enterprise#103619 Forward-Port-Of: odoo/enterprise#98440
This update fixes an error in how stock valuations are calculated when processing foreign currency purchases with auto-standard products. Previously, incorrect currency exchange rate adjustments were being applied, leading to inaccurate inventory values. The fix ensures that stock valuations accurately reflect the product cost in the correct currency.
Original PR description
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the…
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the rates as followed: - Yesterday: 2 - Today: 2.5 2. Create a product category: - Method: Standard - Valuation: Automated 3. Create a product P in that category - Cost: 10 USD 4. [Yesterday] Confirm a PO in EUR with 1 x P 5. [Yesterday] Receive it 6. Bill Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form. Since [1], in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict. [1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7 OPW-5380665 Forward-Port-Of: odoo/odoo#243094 Forward-Port-Of: odoo/odoo#243029
6 changes
Resolved issues and error corrections
This update corrects a technical issue where the `TaxBase` element was missing from FAIA XML reports for invoices with multiple taxes. This ensures compliance with Luxembourg tax reporting requirements and prevents potential errors when submitting reports to tax authorities. The fix was triggered by a specific test case.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This update fixes an issue where the 'Next Milestone' display in the Project list view was missing the deadline date alongside the milestone name. The fix ensures that milestone names now accurately show both the name and its associated deadline, improving project visibility and tracking. This enhancement provides clearer information for project managers.
Original PR description
**Steps to Reproduce:** - Install the Industry FSM module. - Navigate to Project Configuration. - Enable Milestones. - Go to the Project list view. - Observe that the Next Milestone does not display the deadline along with the milestone name. **Issue:** The milestone display name is incomplete and does not include the deadline date. **Cause:** The required context was not passed in the action, so the display_name computation did not add the deadline to the milestone name. **Fix:** Pass the appropriate context in the action to correctly compute and display the name along with its deadline. Task: 5255295 Forward-Port-Of: odoo/enterprise#103160
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to employment bonuses. The changes ensure that bonus calculations accurately reflect the latest tax regulations up to March 2026, improving payroll accuracy for Belgian businesses using Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update corrects a calculation error in the l10n_be_hr_payroll module, ensuring that 3000 deductions for Belgian employees are accurately reflected up to the year 2026. This ensures compliance with Belgian tax regulations and accurate payroll reporting for our Belgian customers.
Original PR description
Forward-Port-Of: odoo/enterprise#103824
This update resolves an issue where payment reports were inconsistently using different export formats (NACHA or localization-specific). The fix ensures that payment reports always use the correct format based on the company's localization, improving data accuracy and reliability for financial reporting. The changes have been backported to version 18.0.
Original PR description
\* = l10n_{ae, au, ch, in, sa, us}_hr_payroll + hr_payroll_account_iso20022
Issue:
The current behavior looks deterministic: when clicking on "Create Payment Report" it -sometimes- shows the current company's export format by default, other times it shows the "NACHA" type. Or it could be the last installed module's export format value for the other companies.
Solution:
I fixed it in this PR: https://github.com/odoo/enterprise/pull/93683 and now backporting the changes to version 18.0
task-5189295
Forward-Port-Of: odoo/enterprise#100126This update resolves a technical error that occurred when selecting a customer in the Ecuadorian Point of Sale (POS) system. The fix ensures a customer is always selected, specifically 'Consumidor Final,' which is required for compliance with Ecuadorian tax regulations. This prevents tracebacks and ensures accurate reporting.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570 Forward-Port-Of: odoo/enterprise#102221
1 change
Resolved issues and error corrections
This update resolves a technical error that prevented users from opening the Trial Balance report when no report lines were available. The fix adds a check to avoid an error when report lines are missing, ensuring the report can always be generated correctly. This improves the reliability of a key financial reporting tool.
Original PR description
Currently, An error is generated while a user is trying to open the 'Trial Balance' report when report lines are not available. Steps to reproduce: - Install an `account_reports` module (without demo). - Go to Accounting / Configuration / Management / Accounting Reports, and open the `Trial Balance` report. - Open the `Trial Balance` line and delete all (Expressions)lines from it. - And Open Accounting / Reporting / Audit Reports / Trial Balance. `IndexError: tuple index out of range` An error occurs when the system tries to access report lines at [1], but no lines are available. Link [1]: https://github.com/odoo/enterprise/blob/c54267a89fb5013138abffdb03a456da2b8a7938/account_reports/models/account_trial_balance_report.py#L428 To resolve this, add a condition to check that if the report has no lines then skip the process of adding a `Total` in the report lines. Sentry-6286872462
1 change
Resolved issues and error corrections
This update automatically adjusts the salary certificate period based on data entered in the Odoo system. Previously, this period was static, which could lead to inaccuracies. This change ensures that salary certificate reporting aligns with the correct timeframe, improving compliance and accuracy for Swiss businesses using the Odoo Enterprise module.
Original PR description
make Period until and from dynamic from data
8 changes
Enhancements to existing features
This update modifies the Vietnamese chart of accounts to align with recent accounting regulations (Circular 99/2025). This change is necessary to ensure compliance with updated Vietnamese accounting standards, taking effect in January 2026. It impacts financial reporting for Vietnamese businesses using the Odoo Enterprise system.
Original PR description
Update the COA for the vietnamese localization, which is based on the circular 200/2014 by the new one based on the circular 99/2025. This new COA applies starting in Jan. 2026 task-5357470 Forward-Port-Of: odoo/enterprise#103823 Forward-Port-Of: odoo/enterprise#102843
This update adds tests to ensure users can successfully attach documents from the Documents app directly into Chatter via the Powerbox command. The previous issue prevented the 'Add from Documents' option from appearing, due to an incorrect check for new records. This fix ensures the feature functions correctly and reliably.
Original PR description
Add Tests for the recently added documents feature, where in Chatter, The user can attach a file directly from the Documents app, either using a button or the powerbox cmd. REF: https://github.com/odoo/enterprise/pull/72806
This update enhances the skills evolution report by comparing each employee's last appraisal for every year, providing a more complete historical view. If a specific year lacks an appraisal, the report now defaults to the previous year's data, ensuring a more robust and accurate report. This change improves reporting accuracy and provides more comprehensive insights into employee skill development.
Original PR description
Repurposed the report, to compare the last appraisal per year for each employee, instead of only the last two appraisals. In case some year does not have an appraisal, fallback to the previous appraisal. Task-5106696
Resolved issues and error corrections
A bug was causing errors when switching between the Timesheet grid view and stopping timers, due to sample data incorrectly reflecting running times. This update ensures all sample timesheets have their timers paused, resolving the issue and improving the stability of the Timesheet grid.
Original PR description
Steps to reproduce: - Open Timesheets app, - Click on search(magnifying lens) to open on cell with no records. - Let sample record be loaded. Issue: - Timer is already started. If you switch back to grid view and stop the time it throws traceback as it has data of sample records. Reason: - The sample records can have record states that are running. Fix: - Make sure all the sample records created have their timer paused using field `is_timer_running`. - Update condition in time display to check if time is running instead using `is_timer_running` not using `time_start` and `time_pause` as `time_pause` is not an active field. task-5267303 Forward-Port-Of: odoo/enterprise#102035
This update corrects a display issue on the website related to subscription products. Previously, the delivery period was shown in English, regardless of the user's language setting. This fix ensures that the delivery period is now correctly translated into the user's preferred language, improving the customer experience.
Original PR description
This commit[^1] introduced a "Deliver Every [period]" text on the website for subscription consumable products, but used the raw selection key that was not translated. As a result, people would see only the "Deliver Every" part in their language, and the period in English. To fix this, we added a computed field with a properly translatable string that is used on the website. Issue reported by support. [^1]: https://github.com/odoo/enterprise/commit/beb7238882eda1fd36aa22bdb6441b8bd5556ef3 Forward-Port-Of: odoo/enterprise#103645
This update prevents users from deleting visitors who are currently Checked-In or Checked-Out, safeguarding visitor tracking data and ensuring accurate records. The system now displays a 'Set as Planned' button for these visitor states and provides a clear error message if deletion is attempted. This improves data integrity and operational efficiency.
Original PR description
Purpose: - The purpose of this change is to prevent accidental deletion of visitors who are currently Checked-In or Checked-Out, ensuring data integrity and proper tracking of visitor activity. This PR includes: - Prevented deletion of visitors unless they are in Planned or Cancelled state. - Added a clear error message when deleting Checked-In or Checked-Out visitors. - Displayed the 'Set as Planned' button for Checked-In, Checked-Out, and Cancelled states. - Added test cases for visitor deletion restrictions. task-5380323
This update resolves a technical error that was preventing users from correctly accessing and editing sign templates linked to certain templates. The fix corrects record rules within the sign.item.role module, ensuring proper access rights are enforced. This improves the usability and reliability of the sign template functionality.
Original PR description
Fix record rules on sign.item.role that prevented users from reading and creating item roles linked to accessible templates, causing access errors when opening or editing sign templates. task-5428886
This update corrects a problem with importing WinBooks tax data. Previously, the import process incorrectly included tax tags with signs, leading to inaccurate tax reporting. This change removes the sign from tax tags during import, ensuring correct tax calculations and reporting.
Original PR description
Import a WinBooks file on a fresh database (a sample can be found in the test files of test_winbooks_import). In the imported taxes, we can see that the tax_tags contain signs. However, since https://github.com/odoo/odoo/pull/225252 , tax tags should no longer store a sign. This causes issues with imported entries in the tax reports: they are not included. This commit adapts the import for WinBooks tax_tags to remove their sign before importing them. opw-5345933 Forward-Port-Of: odoo/enterprise#103691 Forward-Port-Of: odoo/enterprise#101459
14 changes
New functionality added to Odoo
This update adds missing templates for Equity and Government checks within the Odoo Enterprise accounting reports. This ensures accurate and comprehensive reporting, fulfilling a key requirement for financial compliance and providing complete data for analysis.
Original PR description
Completes the work started in odoo/enterprise#88360. The Equity and Government check templates were missing and are added here to fully complete the data. task-5365677
Resolved issues and error corrections
This update fixes an issue where the timesheet timer wasn't correctly associated with the task being worked on. The fix ensures the timer uses the correct task or project from the list view, providing a more accurate and user-friendly timesheet experience. This improves the reliability of time tracking.
Original PR description
### Issue: When looking at the list of timesheet for a task, we can start the time but the timer have default values that don't correspond to the task. ### Cause: `startTimer` in the `timesheetTimerService` is called from the timesheet timer hook without vals. It then makes an orm call to `action_start_new_timesheet_timer` to retrieve the fields (project or task) but as nothing is given in the vals, the selected project is the one returned by `_get_favorite_project_id()`. ### Solution: Get the context of the list view to retrieve the task or the project and input it in `vals`. opw-5342525
This pull request includes updates to translations for various languages and addresses several bug fixes across different modules. Specifically, it fixes issues with address formatting in the contact module, improves printer linking in the inventory app, and resolves a problem preventing ticket creation from email aliases.
This update resolves a minor typo within the Odoo Enterprise system. The change ensures the naming of attachment files accurately reflects their associated external IDs and intended functionality. This improves data consistency and reduces potential confusion.
Original PR description
Fix typo – Correct the ir_attachment file name to match the external ID and its functionality. OPW-5428700
This update fixes an issue where Odoo was incorrectly selecting DIAN number ranges, leading to upload errors. The system now consistently uses the highest available number range returned by the DIAN service, ensuring successful document uploads. This improves the reliability of our integration with DIAN.
Original PR description
**PROBLEM** The GetNumberRange service of DIAN used to retrieve the attributed number ranges can return multiples ranges for the same prefix. In odoo, for each prefix, we only store the last range we encountering in the xml the service respond with. This means there is a chance we select a number range that is already full. This cause an error when trying to upload a new document to DIAN. **STEP TO REPRODUCE** Not reproducible on runbot since this need a production DIAN setup (GetNumberRange service is only available in prod). 1. In DIAN portal, have two valid numbering ranges for the same shortcode. 2. In Odoo, go to Accounting > Configuration > Journals, select the journal, and click "Reload DIAN Configuration" 3. Only one of the NumberRangeResponse is pulled into Odoo, and it may not be the correct one **FIX** For each prefix, we keep the highest range we find in the DIAN response. opw-5086590
This update resolves an error that occurred when creating attendance records using the 'Planning' work entry source. The fix corrects issues with how the system calculates working time and handles partial day allocations, ensuring attendance creation now functions correctly.
Original PR description
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to…
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):** - Install the `hr_work_entry_planning_attendance` module. - Go to `Employees` and create a `new employee` or open an `existing one`. - In the `Payroll` section, set `Work Entry Source` to `Planning`. - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%. - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates. **Error 1:** `AttributeError: 'method_descriptor' object has no attribute 'min'` **Error 2:** `TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given` **Cause:** When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot. If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples. **Fix:** This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format. [1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57 [2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60 **No Task ID**
This update fixes an issue where the Helpdesk return wizard incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operation for multi-step deliveries. The fix ensures the wizard now correctly selects the customer-facing 'OUT' operation, streamlining the return process and improving data accuracy.
Original PR description
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a Helpdesk ticket for that customer. 4. From the ticket, click the "Return" button to open the wizard and select the sales order. Issue: - The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation. Cause: - Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary. Fix: - The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order. task-4948134 Forward-Port-Of: odoo/enterprise#93154
This update corrects a technical issue where the test button on the IoT device interface incorrectly reported successful status even when errors were occurring. The fix standardizes the data format used for IoT device communication, ensuring accurate status reporting and improved reliability of the device testing process. This prevents misleading feedback for users.
Original PR description
This commit fixes several situations where a positive status would be given by the test button despite the presence of an error: - If the websocket connection was used but there was a timeout - If the websocket connection was used but there was any other error - If any 6-digit error code was returned when using the stable IoT box To fix these issues, we stop using the `data['message']` field, since it gets ignored by the websocket confirmation controller. We now use the same result format as the other requests (and the stable IoT box). We also add a check for the `"timeout"` that we receive when a websocket request times out. Forward-Port-Of: odoo/enterprise#103817
This update ensures the employment bonus calculations in the l10n_be_hr_payroll module accurately reflect bonus amounts up to March 2026. This fix addresses a recent adjustment to Belgian tax regulations regarding employment bonuses, maintaining compliance and accurate payroll reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#103820
This update corrects a bug in the l10n_lu reports that prevented the `TaxBase` element from being included in FAIA XML reports when invoices had multiple taxes. This ensures compliance with Luxembourg tax regulations and accurate reporting to tax authorities, resolving a potential data discrepancy.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103543 Forward-Port-Of: odoo/enterprise#101178
This update fixes a minor issue in the SendCloud integration where the product ID was incorrectly accessed. The change ensures the system reliably retrieves product information using the correct 'id' key, preventing potential data retrieval errors. This improves the accuracy of SendCloud order processing.
Original PR description
Same fix as d4fae97, the id was retrieved by doing `[0]` but the proxy object has changed so we need to use the `id` key to get the value instead. ----- Ticket: opw-5433254
This pull request addresses several critical issues impacting payroll processing for Australian businesses using the Odoo Enterprise system. Specifically, it resolves errors related to Medicare calculations, STP reporting accuracy, and rounding discrepancies, ensuring more reliable and compliant payroll operations. The fixes improve data integrity and reduce the risk of financial inaccuracies.
Original PR description
Tracebacks on zeroing Medicare computation to require the variation form Rounding error on STP reporting of Additional withholding task-5416549
This update restores automatic follower copying from parent sale orders for subscription renewals and upsells, aligning with expected business processes. Previously, this feature was removed for all users, but this change specifically addresses the needs of subscription-based sales. It maintains the existing restrictions for other record types.
Original PR description
[FIX] sale-subscription: Restore automatic follower copying from parent SO In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181
This update corrects a calculation error in the Belgian payroll module (l10n_be_hr_payroll) related to the 3000 deduction. The change ensures the deduction accurately reflects tax regulations up to the year 2026, improving payroll accuracy for Belgian businesses. This fix addresses a previously identified discrepancy.
Original PR description
Forward-Port-Of: odoo/enterprise#103824
8 changes
Enhancements to existing features
This pull request introduces basic testing for the Odoo runbot. It's a foundational step to ensure the runbot's reliability and stability, which is crucial for automated processes within Odoo. This change primarily focuses on internal testing and doesn't directly impact user-facing features.
Original PR description
using this commit we are just checking the odoo runbot
Resolved issues and error corrections
This update ensures that branch names on Thai tax invoices are displayed in the correct language based on the customer's language settings. Previously, all invoices used English regardless of the partner's language. This improves the accuracy and professionalism of invoices for Thai customers.
Original PR description
Currently, l10n_th_branch_name is not translatable. Regardless of the language setting, it is printed in English on the tax invoice. This PR addresses that. Task-5438534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue where logging was incorrectly triggered when viewing sales quotes within the Odoo portal. The fix prevents unnecessary requests to the quote URL, ensuring accurate logging and a smoother user experience. This improves system stability and reduces potential performance impacts.
Original PR description
Steps: - Install sales app. - Copy portal of an SO. - use it in editor link or somewhere where preview_url is used. Issue: - Quotation viewed log note adding on the SO. Cause: - `get_link_preview_from_url` method do request on the url that's why it calling it's controller and adding log note. Fix: - Add check for uid in session or `Sec-Fetch-Site` in request header to ensure request is actually coming from user not from some method. opw-5409727
This update ensures that eTIMS configuration warnings are displayed only for companies operating in Kenya. Previously, these warnings appeared for all companies, causing confusion. This change improves the accuracy and relevance of the warnings, streamlining the user experience.
Original PR description
Before: In multi-company setups, the eTIMS configuration warning was shown even when working in companies that are not based in Kenya. This resulted in confusing and irrelevant warnings for users using other localizations. After: The eTIMS configuration warning is now limited to Kenyan companies only. Non-Kenyan companies are no longer impacted, keeping the validation relevant while preserving the intended eTIMS behavior. task-5462334
This update prevents a problem where users in different branches could accidentally create duplicate tax names. Previously, Odoo only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to ensure each tax name is unique, avoiding errors and streamlining accounting processes for companies with multiple locations.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the year field in certain payroll reports was incorrectly displaying a comma. Removing the comma ensures accurate reporting and consistent data presentation for Belgian payroll calculations. This change improves the reliability of financial reports.
Original PR description
. Remove the comma on the year filed on the crossponding reports task-5417861
This update corrects a bug where admin users could inadvertently change the default options for course ratings. The fix ensures that existing ratings and reviews remain unchanged, regardless of edits or deletions made by administrators. This maintains the integrity of course feedback data.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273
This update corrects a bug that occurred when a leave request was linked to a refused allocation and the 'Time Off: Cancel invalid leaves' cron job ran. The fix prevents an error caused by accessing an empty data structure, ensuring the system handles refused allocations correctly.
Original PR description
When a leave is linked to a refused allocation and the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs. Steps to reproduce the error: - Install ``hr_holidays`` without demo data -…
When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.
Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
- Allocation Type: Accrual Allocation
- Set the Time Off Type and Accrual Plan created above
- Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``
Traceback:
``IndexError: list index out of range``
https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.
sentry-6874651972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr8 changes
Resolved issues and error corrections
This update prevents a bug where clicking on list view group headers while in edit mode would trigger incorrect 'required field' error messages. The fix ensures that edit mode calls complete before other actions are taken, eliminating data inconsistencies and improving the user experience.
Original PR description
Steps to reproduce: - Have a record where modifying a field triggers another field to be required in the frontend only - Apply a group by on a list view of this record - Edit a record and modify that field - While still in edit mode, click on another group header Before: Clicking on the group header triggers both `onGroupHeaderClicked` and `onGlobalClick` simultaneously, causing `leaveEditMode` to call `save` twice. The `save` mutex prevents duplicate API calls, but the second call then runs `checkValidity` with stale data, raising a false "required field" error. After: While clicking on the group header still triggers both `onGroupHeaderClicked` and `onGlobalClick` simultaneously, each `leaveEditMode` call waits for any ongoing call to complete before executing. No "required field" error is raised. opw-5388825
This update corrects a validation error within Odoo Studio that occurred when users attempted to add help tooltips to fields in the Contacts list view. The issue stemmed from a missing 'help' attribute in the field definition, which Odoo Studio was incorrectly interpreting. This fix ensures proper functionality and compatibility with Odoo Studio customizations.
Original PR description
Steps to reproduce ================== - Install web_studio,contacts - Go to Contacts - Open the list view - Click on a field - Set a "Help tooltip" => Validation Error Invalid view Odoo Studio: res.partner.tree customization Cause of the issue ================== The help attribute is missing from the field definition opw-5379357
This update corrects a bug in the purchase stock module that was causing incorrect journal entries when returning items with different currency values. The fix ensures that compensation account moves are only triggered when necessary, preventing inaccurate accounting records. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** - enable automatic accounting - set dollars as the main currency - activate euro and set a rate of 10 euro -> 1$ - create a storable product with category fifo/ automated -…
**Steps to reproduce:** - enable automatic accounting - set dollars as the main currency - activate euro and set a rate of 10 euro -> 1$ - create a storable product with category fifo/ automated - create and confirm a PO for 1 unit for 10 euros (no tax) - validate the receipt - return the product and validate return - return the return and validate - open journal items and search your product **Current behavior:** - there is 6 correct lines (those with credit or debit of 1$) - there is two incorrect extra lines one with credit 9$ and one with debit 9$ **Expected behavior:** those two extra lines should not be there **Cause of the issue:** those lines are compensation account move lines for the case where the price of the product returned is different than the price of the product initially received, in the cases of: - a return: compensate the difference. - the return of a return (our case): de-compensate the difference. (see PR https://github.com/odoo/odoo/pull/162697 and more specifically test test_fifo_return_twice_and_bill). But in this case, the compensation is wrongly triggered because the difference comes from the fact that the currency is not taken into account. https://github.com/odoo/odoo/blob/c89d109c460d51fc90b6b13d5f6bc114c7316e42/addons/purchase_stock/models/stock_move.py#L208 **Fix:** we use the original svl instead of the PO because it avoids currency problem. If we wanted to convert the currency of the PO, we would need to find the date that was used to convert the value at the creation of the first svl. And that date came from _get_currency_convert-date() https://github.com/odoo/odoo/blob/d3599e70973e27ed17e403cf498f76bd31e9c236/addons/purchase_stock/models/stock_move.py#L97 which can take the date of the last invoice (if product was invoiced before the move was validated). https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/purchase_stock/models/stock_move.py#L123-L125 We can not use this method because we're doing the return of a return and if the first return also has an invoice, the return value of the method could be the date of this invoice (which is not the date we're looking for). Furthermore there is no way to know if the date returned by _get_currency_convert_date() at the time of the creation of the first svl is the date of the time of the creation of the svl or the date of an invoice previously confirmed. opw-5179239
This fix prevents the 'Update Prices' button from appearing on sales orders when a pricelist hasn't been configured. Previously, the button was incorrectly displayed, potentially leading to users manually adjusting prices without using the standard pricelist system. This change ensures a cleaner user experience and enforces the correct pricelist workflow.
Original PR description
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is…
**Steps to produce:** - Install the `Sales` module. - Enable `Pricelists` in settings and set the `default quotation template`. - Create a new Sales Order. **Issue:** - The `Update Prices` button is visible even when no pricelist is set on the sales order. **Root cause:** - In the onchange logic (see [1]), show_update_pricelist is set to True based solely on the presence of order lines, without checking whether a pricelist is defined. **Solution**: - Update the condition so that button is shown only when sale order line is present and the current pricelist value is not the previous one. [1]: https://github.com/odoo/odoo/blob/849ec71acbaea0061fd4b13888a486e4aebb6463/addons/sale/models/sale_order.py#L801-L803 Before: <img width="1215" height="466" alt="image" src="https://github.com/user-attachments/assets/f29b1ccf-eec8-4114-b4c9-a8083947ad28" /> After: <img width="1207" height="428" alt="image" src="https://github.com/user-attachments/assets/e358b633-d11b-413d-94c4-3837c430eac4" /> opw-5414897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request addresses a small error in the French tax reporting (l10n_fr) module. Specifically, a mistake was identified and corrected within a specific tax box (15_2). This ensures accurate tax calculations and reporting for French businesses using Odoo.
Original PR description
During this commit: 869f80b we made a mistake in the box 15_2. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects minor errors in the 2026 balance sheet and profit & loss reports for the Danish localization. These changes involve adjusting formulas and text within the reports, likely due to an oversight during development. This ensures accurate financial reporting for Danish businesses using Odoo Enterprise.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/0d431fe2cc6556a040888ecc5d6a71be4a435447 we introduce a new balance sheet report for 2026 but there was a mistake in the sign of a formula and in the text of a line. Same for the profit and loss, some errors in sign of accounts and naming. The errors don't come from a ticket but more of a logical fix, those errors were probably an oversight during development. no task id
This update fixes a bug in the payroll system that incorrectly reversed employee first and last names when generating legal name reports. The change ensures that employee names are consistently formatted as 'FirstName LastName' for SwissDEC reporting, aligning with legal requirements and improving data accuracy. This ensures accurate reporting for payroll and tax compliance.
Original PR description
* Fix _compute_l10n_ch_legal_name method to correctly assign first_name and last_name from employee name (was previously reversed) * Update all SwissDEC test data to use correct "FirstName LastName" format instead of "LastName FirstName" to match the corrected computation logic task-5102851
This update resolves an issue where the 'Validate' button in the barcode app became disabled after an error occurred during barcode scanning. The fix reverts a previous attempt to manage concurrency, relying instead on the framework's mutex mechanism for reliable validation processing. This ensures the button remains functional and prevents duplicate validation attempts.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on…
### Steps to reproduce: - In the settings enable: Multi-Steps route - Create a product tracked by SN - In the barcode app > Operations > Internal transfers > New - Scan you tracked product - Click on Validate > Invalid operation - Scan a Serial number #### > You can not click on validate anymore ### Cause of the issue: The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since orm call returns an error the the call the validate method is interupted at this orm call and the line https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133 ### Fix: We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 : https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135 we have the guarantee that the records will not be validated twice. opw-5388297