This update adds support for Belgian ONSS (Organisatie Ondernemers Samenwerking) payroll categories and rates within the Odoo Enterprise system. This enhancement ensures accurate calculation of social security contributions for employees in Belgium, aligning with local regulations and improving payroll reporting.

Task: 5447645

This update establishes the core framework for Kuwait payroll, ensuring compliance with local labor laws. It includes automated Social Security calculations, tiered leave deductions, and the setup of a demo company for testing. This lays the groundwork for future enhancements to the Kuwait payroll system.

Introduce the foundational setup for the Kuwait payroll localization, serving as the base for subsequent enhancements, and implement core legal requirements including Social Security, End of Service (EOS), and leave logic.

The goal of this change is to establish a functional payroll framework compliant with Kuwait Labor Law. It provides a consistent baseline by:
1. Setting up demo data and standard working schedules for immediate testing.
2. Automating Social Security calculations for employee deductions and company contributions.
3. Handling specific leave computations, including tiered deductions for sick leave and monthly provisions for accounting accuracy.

Technical summary:
- Added demo company: "My Kuwaiti Company" and linked employees.
- Defined standard working schedule (9:00–17:00, Sunday–Thursday).
- Introduced Kuwait salary structure "Kuwait: Monthly Pay".
- Added Rule Parameters for Social Security:
  - Basic Pension: Employee (10%), Company (15%).
  - Unemployment: Employee (0.5%), Company (0.5%).
- Added Salary Rules for:
  - Social Security deductions and contributions.
  - End of Service Benefit: Logic for "Resigned" (<3y: 0%, 3-5y: 50%, 5-10y: 66%, >10y: 100%), "Fired" (0%), and standard calculation (15 days/year first 5 years, 1 month thereafter).
  - End of Service Provision: Monthly accrual calculation.
  - Annual Leave Provision and Remaining Leaves Compensation.
- Added "Kuwait Annual Leaves" Accrual Plan (2.5 days/month, starts after 6 months) and linked it to the Annual Leave type.
- Overridden `_get_worked_day_lines` in `hr.payslip` to implement tiered deduction logic for Sick Leaves (15 days full pay, 10 days 75%, etc.).
- Added `NET_COST` salary rule to correctly aggregate all employer costs for the Employee Cost Dashboard.
- Extended `hr.employee` to include Kuwait-specific Annual Leave Eligibility (default 30.0 days/year) displayed on the employee form.
- Extended `res.config.settings` to allow defining the default Annual Leave Time-off type for the company.

task-5116274

This update introduces the foundational localization package for North Macedonia within the Odoo Enterprise platform. This addition enables basic reporting and accounting features tailored to North Macedonian business requirements, expanding Odoo's reach to this market. It represents a key step in supporting local regulations and user needs.

This commit will add the basic package for north Macedonia

task-5253778

This update allows HR users to manually add and edit lines on payroll payslips while they are in Draft mode. This provides greater flexibility in adjusting calculations and ensures accurate payroll processing. A warning indicator is displayed for manually added lines to highlight potential discrepancies.

- Allow payroll users to edit payslips / add lines on those payslips when in Draft state

This update adds a 'working schedule' field to the offer form in the Enterprise module, providing more detailed information for contract creation. It also addresses alignment issues and a previous bug where data couldn't be correctly populated after signing, ensuring a smoother and more accurate process for managing employee offers.

-Add the working schedule field to form view
-Fix alginment of group car
-it was possible to fill data from the template after signing now it's fixed

Task#6158425

This update introduces the ability to print reports directly from Obox devices, mirroring functionality for IoT printers. The system now presents a popup allowing users to select a printer for each report, ensuring reports can be printed regardless of network connectivity. Currently, this implementation is simplified with limitations on printing multiple documents at once.

This commit adds report printing support for Obox printers, similarly to what already exists for IoT printers. A report can be linked to a printer, and then when printing a popup is shown to select from the linked printers.

For now the implementation is intentionally simpler than the IoT equivalent, in the following ways:

- Only one printer can be printed to at a time, not multiple.
- The user cannot save preferences for which printer is selected, instead the popup to select a printer is shown every time.
- There is no option to disable duplex (this will require an Obox change first).

The print job uses a queue action so it does not rely on the user being on the same network as the Obox.

task-6241709

This update hides the 'Targeted Job' field on the appraisal form for appraisees when no target job is set. This simplifies the form and reduces confusion for users, making the appraisal process more intuitive. The existing read-only behavior for non-managers remains unchanged.

Purpose:
- Improve appraisal form usability by hiding the Targeted Job field for the appraisee when the field is empty and not editable.

This PR includes:
- Updated Targeted Job field visibility logic in the appraisal form.
- Hidden the field for appraisees when no target job is configured.
- Kept the existing readonly behavior unchanged for non-managers.

task-6254850

This update simplifies the process of creating payroll records. Instead of immediately starting a new pay run, users now have a dropdown menu to select whether they want to create a new payslip or a pay run. This offers a more intuitive workflow for managing payroll data.

Updates the 'New' button behavior to show a dropdown menu instead of immediately triggering a new pay run, allowing users to create a payslip or a pay run.

taks:6222553

This update enhances the Odoo website generator's ability to manage images by introducing a new attribute, 'data-ws-preserve'. This allows for customized image settings like shape and loading behavior, improving flexibility and control over how images are displayed. The underlying code has also been modernized for better clarity and maintainability.

Added the special attribute 'data-ws-preserve' on <img> that allows to set specific attributes despite the replacement with the regex. It is used to be able to add attributes like data-shape="..." or loading="eager".

This update improves payslip generation by automatically tailoring language versions based on an employee's location and preferences. Employees will now receive payslips in their preferred language, or a translated version if the location doesn't offer that language. This ensures accurate and localized payroll information.

This commit introduces dynamic payslip language generation based on the DMFA work location's configured languages and the employee's language.
Key changes:
- Introduced payslip_language_ids in l10n_be.dmfa.location.unit, a many2many relation with res.lang.
- Enhanced the payslip PDF generation logic to follow these rules:
1. If the employee's language is listed among the DMFA location preferences, generate a single payslip in that language.
2. If the DMFA location has a single preferred language that differs from the employee's, generate:

One official payslip in the preferred language.

One translated payslip in the employee's language, with a warning stating it is for reference only.
3. If the DMFA location has multiple preferred languages, generate:

One official payslip in the first (French has a higher priority than Dutch, PM request) language.

A second version in the user language.
Overrode the PDF attachment generation method in l10n_be_hr_payroll to implement this behavior.
Related task: 4936594.

This update allows users to proactively address payroll warnings that were previously hidden after 25 days. Now, users can easily reset the warning by deleting or setting a past date, ensuring they remain aware of outstanding issues. This improves compliance and allows for quicker resolution of potential payroll discrepancies.

Previously, payroll warnings were snoozed for 25 days and there was no way for the user to show it again until the unsnoozing date.
Now, users can decide to unsnooze the warning through its form just by deleting the date or putting a date in the past.

task-6240586

This update enhances the functionality of pivot tables within the Enterprise edition of Odoo. It introduces new filter options, allowing users to more precisely analyze and segment their data. This improves data reporting and decision-making capabilities.

Task: 4273959

This update enhances the Odoo Enterprise system to better support internal transfers between warehouses. Previously, generating delivery guides for these internal transfers was limited. Now, users can easily create delivery guides for transfers within their own warehouses, streamlining operations and improving efficiency.

Although less common than outgoing pickings, users sometimes need to generate it for transfers between their own warehouses.

task-6107987

This update enhances the user experience within the Manufacturing, Quality, and Shop Floor apps by refining the Gantt view scales and improving the Quality Point form. Specifically, the Quality Check form now allows easy access to worksheets and attachments, streamlining the inspection process and aligning the Shop Floor card layout for a more consistent user interface.

This PR improves the user experience in the Manufacturing, Quality and Shop Floor app and adds the worksheet to the quality check form.
Task-id: 6164381

This update enhances payroll calculations for CP302 and CP200 by allowing direct wage adjustments and displaying employees below the minimum scale. It also improves the handling of seniority changes, ensuring accurate wage versioning and updates.

In this commit, we introduced some improvements to the wage scale for CP302 and CP200.
- The warning action will display the list of employee below the minimum scale wage.
- We added an issue in the employee form view to adjust directly the wage to the minimum value.

task-6112647

This update simplifies WhatsApp template setup by automatically detecting the recipient's phone number based on available fields. Previously, users had to manually configure the recipient's phone number for each template. This change offers greater flexibility and reduces configuration effort, ensuring messages are sent to the correct contact.

PURPOSE:

The purpose of this commit is to introduce the default recipient feature in WhatsApp templates.

SPECIFICATION:

A `use_default_recipient` boolean field has been added to the WhatsApp template model. When enabled, the system will automatically compute the `phone_field` as follows:

- First, it checks for available phone fields defined on the model.
- If none are found, it falls back to the linked partner's phone number via any partner-related field.

This improves flexibility and reduces manual configuration when defining WhatsApp templates.

Related Upgrade PR: https://github.com/odoo/upgrade/pull/9477

Task-4213035

This update adds a smartbutton that dynamically lists employees eligible for the DFMA (Declaration for Monthly Fiscal Accounting) calculation. Users can now easily manage this list, removing employees to ensure accurate reporting. This change streamlines the process of determining which employees contribute to the DFMA calculation.

Adds a smartbutton automatically updated with the list of employees that will be considered in the DFMA for that time period (year / quarter)
If you delete a line from this list, employee will not be counted in the DMFA

task-6215776

This update simplifies the shift map view by filtering shifts to display only those for a specific day. Previously, the map cluttered with outdated or irrelevant shifts, making daily planning cumbersome. This change supports future shift optimization features, streamlining scheduling and routing.

Currently, the map view displays all shifts without distinction. This quickly clutters the list with records from two years ago or recurring shifts scheduled months in advance, which aren’t relevant in the moment.

If a user wants a clear view of their shifts for a specific day, they need to open the search, go to custom filters, and select a date - which is cumbersome.

Looking ahead, we would like to give users the option to automatically plan and optimize the routing of their shifts. Doing so would be much simpler and more efficient if these calculations were based on a specific day.

task-6176635

This update refreshes the visual appearance of snippet thumbnails in the web editor, enhancing their design and clarity. The new thumbnails provide a more modern and intuitive representation of each snippet category, improving the overall user experience.

*: website_sale_renting

This commit updates the snippet thumbnails in the web editor with new
more modern designs. The updated thumbnails are more visually appealing
and provide a clearer representation of each snippet category.

task-5868664

Requires:
- https://github.com/odoo/odoo/pull/246564

This update ensures that draft manufacturing orders (MOs) are now correctly considered as incoming supply when calculating replenishment needs in the MRP MPS. Previously, draft MOs were excluded, leading to unnecessary and incorrect replenishment suggestions. This change improves the accuracy of the system and prevents over-replenishment.

Draft MO moves were previously excluded from MPS incoming quantity, causing unnecessary replenishment suggestions even when an MO was already created from the replenish action. This change updates the domain to consider draft moves as incoming supply to avoid duplicate replenishment.

Community PR: odoo/odoo#249809
TaskID-5877241

This update ensures salary attachments are correctly linked to payslips and processed in the correct order (rule sequence, priority, creation date). The system now prorates deductions accurately when funds are limited, providing a more precise calculation of employee compensation.

With this commit , salary attachments will have there proper payslip lines. 

They would be display in this order :  Type rule sequence -> priority -> creation date .

We completely compute the deductions from a specific salary attachment before moving to the next one.
If the available money isn't enough to take back all the attachments of a type , we prorate it.

task - 5480184

This update ensures that the l10n_id_reports module is properly configured for translation management within Odoo. By adding the module to the .weblate.json file, the system can now track and manage translations for this reporting module, improving its usability for users in countries that speak Icelandic.

Enable translation management by adding the
module entry to .weblate.json.

task-6239169

Forward-Port-Of: odoo/enterprise#118931

This update corrects a technical oversight where a new module for the Hungarian reports (l10n_hu_reports_a60) was developed but not properly integrated into the Weblate translation system. This ensures accurate translations are available for users in Hungary, preventing potential communication issues.

We added a new module here 379c5e9611f1f1c242027c1c134219966474de16
but forgot to add it to weblate.json for
translation.

no-task

Forward-Port-Of: odoo/enterprise#118932

This update resolves an issue where the ellipsis indicator for long text messages didn't always update correctly in the Enterprise version of Odoo. The change utilizes a more efficient, reactive approach (signals) to ensure the indicator resets immediately when new text is added, improving the user experience.

This update corrects a problem where Odoo reports were displaying incorrectly when all company journals were assigned to a single ledger. The change removes the 'Local GAAP' implicit ledger from report selections, ensuring accurate reporting regardless of ledger configurations. This improves the reliability of financial reports.

When all journals of the company are in a ledger, the implicit ledger 'Local GAAP' is empty, so we remove it from the ledger selection in the reports.

task-6260588

Forward-Port-Of: odoo/enterprise#118927

This update resolves an issue where field service orders were incorrectly displaying a delivered quantity of '1' before order confirmation. The fix ensures the delivered quantity accurately reflects stock pickings and purchase order generation, improving order accuracy for dropship products. The original code's logic was causing an incorrect calculation.

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#118131
Forward-Port-Of: odoo/enterprise#115760

This update fixes an issue where the l10n_co_edi type wasn't being imported correctly when importing XML bills through the Purchase journal. Now, bills imported through the Purchase journal will retain their originally specified l10n_co_edi type, ensuring accurate tax reporting.

In l10n_co_edi on bills, the field l10n_co_edi_type can only be changed when the journal is DIAN Support Documents and not purchase. However when importing a XML, the field is not imported and is instead always computed to type 01.

 It should be possible to have imported bills using the Purchase journal and maintain their original type.

(Take the xml on the ticket to reproduce the issue)

opw-6203930

Forward-Port-Of: odoo/enterprise#118533

This update ensures that dates displayed and processed within Odoo reflect the user's local timezone, improving accuracy for critical business processes like deadlines and validations. The changes also streamline date handling by removing redundant code related to currency conversion, enhancing efficiency and stability.

This PR improves date-handling consistency by using `fields.Date.context_today(...)` in date-only flows, where "today" should reflect the current user's local date rather than the server date.

In addition, it removes redundant date arguments passed to `_convert()`, as the method already defaults to `context_today()` when no date is provided. This reduces unnecessary code while preserving existing behavior.

Together, these changes improve timezone correctness for business-critical date logic and simplify currency conversion calls.

Related Community PR: https://github.com/odoo/odoo/pull/264588
task-6228958

This update clarifies how subscription prices are set up. Previously, the system automatically filled in pricelists, leading to user confusion about price scope. Now, users manually select the pricelist, eliminating errors and simplifying the subscription pricing process.

When adding a new pricing rule on a subscription product (either from the product form's Prices tab or from the subscription plan's Pricing page), we was pre-filling the pricelist field with the company's first available pricelist. This caused confusion because users assumed the price would apply to all pricelists, while it was actually scoped to that one pricelist only. This led to broken combinations on the eCommerce product page and required an extra manual step to clear the pricelist for each rule added.

task-6154318

This update automatically fixes formatting issues in the Obox modules, ensuring consistent code style. The changes were made to improve code readability and maintainability, aligning with our development standards. This work is part of an automated process enforced by Odoo's linting system.

This commit fixes all Prettier formatting errors in the Obox modules. The lint check itself is enforced in odoo/odoo#267994.

This update optimizes the way Odoo calculates the display of work orders, specifically within the MRP module. By changing a selector used in the code, the system now recalculates styles more efficiently, leading to faster performance during common actions like resizing windows or scrolling through large tables.

Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior, this reduces work during the "Recalculate Style" phase.

It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class.

Forward-Port-Of: odoo/enterprise#119024
Forward-Port-Of: odoo/enterprise#118618

A test was failing due to a limitation in how the POS system loads partner data. This fix ensures that all partners are properly searched for, resolving the test failure and improving the reliability of the point-of-sale tax functionality. This primarily impacts the US partner search functionality.

**Issue:**
`test_pos_fiscal_position_without_pos_avatax` test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS.
Therefore, he's not found.

runbot-938983

Forward-Port-Of: odoo/enterprise#118345

This update resolves an issue where leave settings were incorrectly available when the time-off application wasn't used. The related code has been moved to a dedicated bridge module for better organization and to ensure functionality aligns with installed applications. This improves the overall stability and accuracy of leave calculations.

Issue:
------

The 'leave' and 'public_leave' values of 'hr.attendance.overtime.rule.timing_type' should not be available when time off app isn't installed. This PR also moves the `leave` and `public_leave` code to the `hr_holidays_attendance` bridge.

odoo/odoo#259386
enterprise-108725
upgrade-9574
task-5942798

This update removes an outdated feature, `onWillUpdateProps`, which is no longer supported in the newer OWL3 version of Odoo. This change ensures the system continues to function correctly with the latest Odoo release, maintaining stability and performance. No functional changes were made.

This update removes an outdated technique (useLayoutEffect) that was causing performance issues in the Gantt chart. The change utilizes modern React signals and useEffect hooks to ensure the chart updates efficiently, aligning with the latest Odoo technology.

Replaces useLayoutEffect with a signal(null) callback ref via t-ref and useEffect, which auto-tracks the signal read inside the callback.

WHY: useLayoutEffect is removed in OWL3