Daily updates from Odoo
Friday, July 11, 2025
56 changes
15 changes
Resolved issues and error corrections
The Belgian payroll double holiday pay report now uses the correct payslip-based label instead of referring to the 13th month. This makes generated payroll documents easier to identify and reduces confusion for HR and employees.
Original PR description
Originally, the name structure for double holiday follows "13th Month -[Legal Name] -[year]". It has been renamed to "[Payslip name]- [Legal Name] -[year]" . Forward-Port-Of: odoo/enterprise#88732
Appointment request notifications now include CC contacts when manual confirmation is enabled. This ensures teams or stakeholders copied on an appointment are informed as soon as a request is submitted, reducing missed follow-up and confusion.
Original PR description
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go…
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go to the appointement website (/appointement) - Create an appointement and submit it - Nothing is sent to CC contact when the request is made **Issue:** Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation. This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester). The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment. **Fix:** Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity. related: cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98 opw-4658521 Forward-Port-Of: odoo/enterprise#88042 Forward-Port-Of: odoo/enterprise#86710
Emails sent with attachments to accounting journal aliases now process correctly in multi-company setups with separate alias domains. This prevents errors when accounting attachments are centralized in Documents, ensuring vendor bills and similar records are created and parsed as expected.
Original PR description
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with…
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias. The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question. steps to reproduce: 1. clean DB with documents_account installed 2. create a 2nd company "company 2" 3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com" 4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2 5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company 6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com) 7. send an email with attachment to that alias -> you will get a multi-company error After this commit ------------------ Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected. opw-4727873 opw-4655559 opw-4746321 opw-4766895 Forward-Port-Of: odoo/enterprise#89411 Forward-Port-Of: odoo/enterprise#84997
Subscription pricing or rule conditions that depend on a minimum product quantity now only apply once that quantity is actually reached. This prevents customers from receiving rule-based terms too early and helps keep subscription offers aligned with intended sales policies.
Original PR description
Rules applicable above a specific product quantity should not be considered unless the minimal quantity is reached.
This fix prevents an error when generating Peru Stock Move PLE valuation reports. Users can now run the PLE 13.1 report for Peruvian companies without the report failing due to missing product category data.
Original PR description
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to…
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to `Peru`, and switch to this company. - Go to `Receipts` in `Inventory`, create a `new receipt`, and `validate` it. - Go to `Valuation` and click on `PLE Reports`. - Select the `start date` as the day after today, and click on `PLE 13.1`. `KeyError: 'category'` This error occurs during the valuation of the Stock Move PLE reports. In the query, we retrieve product_template.categ_id as category_id [1], but later category [2] is used to access category_id. Since the category key is not present in the line, this causes the error. [1] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L241 [2] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L303 This commit ensures that category_id is used in place of category for safe evaluation. sentry-6723761615 Forward-Port-Of: odoo/enterprise#89379
Users can now share shortcut folders from the cog menu next to the breadcrumbs in Documents. This fixes a missing sharing option and removes unused code, making folder sharing more consistent.
Original PR description
Before this commit, the share action in the cog menu (next to the breadcrumbs) wasn't available for shortcut folders. This commit fix this issue. This commit also removes some dead code. Task-4897840 Forward-Port-Of: odoo/enterprise#89161 Forward-Port-Of: odoo/enterprise#88512
This update ensures the invoice option is selected before validating Italian point-of-sale orders, preventing a validation error that could block sales completion. It also removes a duplicate line in the UrbanPiper POS integration, with no expected change for users beyond cleaner behavior.
Original PR description
## After this commit: - It ensure invoice checkbox is selected before validation, preventing the error and allowing the order to validate correctly. - Removed repeated line in `pos_urban_piper`. Runbot [link](https://runbot.odoo.com/odoo/runbot.build.error/159985) Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4916349) runbot-159985 task-4916349 Forward-Port-Of: odoo/enterprise#90018 Forward-Port-Of: odoo/enterprise#89486
Spanish Model 349 BOE reports no longer include rectification lines for bills and credit notes that fully cancel each other within the same reporting period. This avoids incorrect tax report entries while preserving expected rectifications for prior-period bills.
Original PR description
# How to reproduce the issue On a **l10n_es** fiscal position: - Create a bill for the current period and then create a credit note for this bill. - In the tax report, under model 349, download the BOE report. Since the bill has been fully canceled within the same period, no rectification line should appear in the BOE report (correct behavior). - Create a bill from a previous period. - Create a credit note for this bill in the current period. - Download the BOE report from model 349. A rectification line appears for the previous period bill, which is expected. However, a rectification line also appears for the current period bill, which is incorrect, as the bill was canceled within the same period. This commit prevents moves from the current period from being included as rectification lines in the BOE report. opw-4895636 Forward-Port-Of: odoo/enterprise#89624 Forward-Port-Of: odoo/enterprise#89382
The India reports now use the official state name “Odisha” instead of the outdated “Orissa”. This keeps tax reporting labels aligned with Government of India terminology and avoids confusion for users reviewing statutory reports.
Original PR description
Issue: As per Government of India guidelines, the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in report. Solution: Updated the records from "Orissa" to "Odisha". opw-4935633 Forward-Port-Of: odoo/enterprise#89947
Salary package offers that start in a future month now generate a payslip beginning on the contract start date instead of the current month. This prevents payroll documents from being created outside the employee's contract period, reducing errors during offer and payroll setup.
Original PR description
When creating an offer with a contract date start in the future, the payslip created is still set at the current month, so the contract is outside the payslip. This is fixed by creating a payslip with date_from equal to the contract_date_start. Task: 4903936
Scanning a product package in the Barcode app now updates the matching open receipt line instead of creating a duplicate line. This helps warehouse teams process receipts more accurately when products are handled in different package sizes.
Original PR description
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable…
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable "Units of Measure & Packagings" - Create a product using the base Unit as uom and allowing pack of 6 aspackaging (optional) - Inventory > Configuration > Product > Units & Pacakagings - Click on pack of 6 > Packaging Barcodes > New - Create a new one for your product - Create and confirma receipt for 6 units of your product - Go to the barcode app and scan a pack of 6 #### > A new line 1 pack of 6 was created rather than updating the already existing one. ### Cause of the issue: When the packaging is scanned, we will call the `findLine` of the `BarcodeModel` in order to determine if there is already an existing line that could absorb the scanned qty. However, this call currently requires the uom of the barcodeData to coincide either with the line uom or its referred packaging to be a valid candidate: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1748-L1753 ### Note: This additional check was added in a9a20f8ec5a7883a08eb4bea15dbf3c4cc97caac when the uom and packagings were refactored and merged together. However, it is really unecessary since the system can handle different uoms via these lines: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1450-L1466 ### opw-4866981 Forward-Port-Of: odoo/enterprise#89453 Forward-Port-Of: odoo/enterprise#88494
This fix stops Point of Sale auto-configuration from automatically assigning a newly detected scale device when an IoT Box may have misidentified a connected Blackbox terminal during first startup. This prevents incorrect store settings and avoids manual cleanup after the IoT Box restarts and recognizes the device correctly.
Original PR description
If on first boot after flashing the iot box a blackbox is connected the iot box doesn't have the blackbox driver so it's identified as Adam scale With the pos_iot auto configuration we would first send it as a scale to the database and it would be set as a scale to the selected pos config. After odoo restart on the iot box it gets detected as blackbox correctly and its name changes. Now after it's sent to the db the user ends up with a blackbox in the scale field in PoS config. This PR removes the automatic scale configuration so that doesn't happen Forward-Port-Of: odoo/enterprise#89888
Manufacturing orders can once again be closed directly from the Shop Floor after their operation is marked done. This prevents completed work from getting stuck in the interface and helps production teams keep order statuses accurate without switching screens.
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f Community: https://github.com/odoo/odoo/pull/212885 opw-4800147 Forward-Port-Of: odoo/enterprise#88525 Forward-Port-Of: odoo/enterprise#86905
This update documents hidden fields across several localization and payroll screens so automated checks pass consistently in stable versions. It reduces maintenance risk while preserving current behavior for customers and custom views.
Original PR description
Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. Forward-Port-Of: odoo/enterprise#88643 Forward-Port-Of: odoo/enterprise#83421
Offer processing for applicants now creates only one salary contract version when a new employee record is created. This avoids duplicate versions at the end of the signature process, making employee offer records cleaner and easier to manage.
Original PR description
Current Behavior: When you send an offer to an applicant it will create two versions at the end of the process: https://tinyurl.com/253j3683. Behavior after PR is merged: When you send an offer to an applicant it will only create one version* for the employee created from the applicant. Change: Removed the unnecessary initial version created for fresh employee records coming from applicants' offers. *: note that this new version will be active, even when awaiting full signature, this might be acceptable since the fresh employee record would be archived, which is different from existing employees offers, where the employee remains active, and the new version is archived till full signature. Task-4903960
16 changes
Resolved issues and error corrections
This fix ensures WhatsApp messaging features load consistently across all relevant Odoo pages, including backend, public discussion pages, live chat, and portal chatter. It prevents message updates from failing when broadcasts are received in tabs outside the main backend interface.
Original PR description
`common` folder should be included in all bundles. This is especially necessary when broadcasting messages on the bus, because these messages will be received in all tabs, including those potentially not in the back-end, such the discuss public page, any page where a live chat is opened, or a portal page with a chatter. This is also necessary just to have all features properly working in all context, there is no reason that a whatsapp viewed in the public page should not have its features working as intended. runbot-223082 Forward-Port-Of: odoo/enterprise#89847
This fixes an issue that could prevent payslips from being created for Belgian employees when a work entry covered a long period, such as a full month. Payroll teams can now process these payslips without encountering the error.
Original PR description
There is a bug in the module that made the creation of payslip triggers an error. Steps to reproduce it :
1) Use a Belgian company and an employee with a contract;
2) Create a work entry for a whole month (from 05/01/2025 09:00:00 to 06/01/2025 17:00:00 for example);
3) Try to create a payslip for this employee.
Error :
File "/data/build/enterprise/l10n_be_hr_payroll/models/hr_contract.py", line 517, in _get_work_hours_split_half
work_data[('half', work_entry.work_entry_type_id.id)] += dt.days * 24 + dt.seconds / 3600 # Number of hours
TypeError: 'float' object is not iterable
[opw-4752109](www.odoo.com/odoo/project/49/tasks/4752109)
Forward-Port-Of: odoo/enterprise#89039
Forward-Port-Of: odoo/enterprise#84810This fixes an error that could block draft accounting entry creation when a payroll batch contained payslips from more than one company. Payslip company selection is now protected from manual changes, and older inconsistent records show a clear validation message instead of a system traceback.
Original PR description
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account…
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6) Now, try to click on the Create Draft Entry **Error:** A traceback will occur. ``` ValueError: Expected singleton: res.company(1, 2) ``` **Cause:** When the user created multiple payslips with multiple companies containing the same batch and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, and try to change the state to Done using the action_payslip_done method. https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70 So the self will contain multiple payslip recordsets with different company in each payslip. This leads to the above traceback when accessing company_id from self https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61 **Solution:** In payslips, the company_id field should be in readonly state, since the value of the company_id will computed from the employee_id which is a required field. Also raised a validation Error for the previously created record to handle the traceback. Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763 opw-4797089 Forward-Port-Of: odoo/enterprise#89085 Forward-Port-Of: odoo/enterprise#86628
VoIP error messages now show line breaks and formatting as intended instead of displaying HTML tags as plain text. This makes error information easier for users to read and understand when using the softphone.
Original PR description
`<br>` tags in VoIP error messages are rendered as text. This is because the code uses t-esc instead of t-out, and t-esc never renders inner HTML. This commit just replace t-esc with the proper t-out directive. |Before|After| |-|-| ||| Forward-Port-Of: odoo/enterprise#88431 Forward-Port-Of: odoo/enterprise#88355
Bank reconciliation now avoids matching statement lines when a reference or move name only appears as part of a longer value. This reduces incorrect automatic matches, especially for invoice or journal references that resemble dates or prefixes.
Original PR description
Actually, we are matching to blindly for full matches. We only check if aml.move_name or aml.ref is present in st_line label.
But this cause issues with move names like dates, where you could have :
- move_name = 2025/123
- label contains 2025/1234567
In this case, we don't want to match, as 2025/123 is not perfectly present in the label.
So this commit update the condition so we need now to have a perfect full match between st_line label and aml.ref or aml.move_name.
no-task
Forward-Port-Of: odoo/enterprise#89248This fixes a Point of Sale issue where employees with minimal permissions could enter negative quantities during refunds when the UrbanPiper integration was installed. The change helps ensure refund handling follows the intended permission controls and reduces the risk of incorrect order adjustments.
Original PR description
Fix issue where when `pos_urban_piper` was installed, minimal right employee were able to set negative orderline qty with a refund through the ticket screen. task-id: 4922318 community PR: https://github.com/odoo/odoo/pull/217774 Forward-Port-Of: odoo/enterprise#89669
Appointment requests now avoid linking a new opportunity to a customer record from a company the appointment staff cannot access. This prevents multi-company booking submissions from failing with company compatibility errors, making online appointment lead creation more reliable.
Original PR description
**Steps to reproduce:** - Set up CRM / Appointment / Website apps - Create new company (2) - Create partner contact with specific email and the new company - Create appointment type linked to a staff…
**Steps to reproduce:**
- Set up CRM / Appointment / Website apps
- Create new company (2)
- Create partner contact with specific email and the new company
- Create appointment type linked to a staff user of another company (1) who has no access to the new one
- Enable `Create Opportunities` on the new appointment type
- Go to the website as an anonymous user
- Submit an appointment request using the partner's email
- `Incompatible companies on records:` error
**Issue:**
Previous solution (17.0) was trying to use existing partner if the email was provided and existed in the database
`customer = request.env['res.partner'].sudo().search([('email_normalized', '=', email_normalized)], limit=1`
This means that, in a multi-company environment, the lead created by the new appointment for the appointment user of company 1 can be linked to the partner contact of company 2 and throw an error on validation.
**Fix:**
Restricted partner search domain using current allowed companies using the `staff_user` or the user which created the `appointement_type`.
opw-4713060
Forward-Port-Of: odoo/enterprise#89196
Forward-Port-Of: odoo/enterprise#84006Manufacturing orders created or opened in the barcode app now handle bill of materials lines that use units different from the product default. This prevents errors when unit settings are disabled and ensures component quantities use the intended units, reducing mistakes in production operations.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196)
This fixes an issue where payment references ending with a backslash could break bank statement reconciliation matching. The change helps accounting users process such payments without unexpected errors.
Original PR description
If a payment ref end with '\\', this '\\' will be interpreted as an escape operator in the query, which leads to an error. This commit add the '\\' to the list of char to escape. no-task Forward-Port-Of: odoo/enterprise#89659
This fixes how monthly payroll summary data is grouped for Swiss ELM transmissions. It helps ensure payroll reports sent through the Swiss payroll process contain complete and accurately aggregated information.
Original PR description
Forward-Port-Of: odoo/enterprise#89914 Forward-Port-Of: odoo/enterprise#89839
Fixes an issue where clicking “Close Production” from the Shop Floor did nothing after an operation was marked done. Manufacturing orders now close correctly from the Shop Floor, helping operators keep production status accurate without switching screens.
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f Community: https://github.com/odoo/odoo/pull/212885 opw-4800147 Forward-Port-Of: odoo/enterprise#88525 Forward-Port-Of: odoo/enterprise#86905
This fix stops Point of Sale IoT setup from automatically assigning a newly connected device as a weighing scale when it may be misidentified on first startup. It prevents businesses from ending up with the wrong device configured in their PoS settings after the IoT box restarts and correctly recognizes the device.
Original PR description
If on first boot after flashing the iot box a blackbox is connected the iot box doesn't have the blackbox driver so it's identified as Adam scale With the pos_iot auto configuration we would first send it as a scale to the database and it would be set as a scale to the selected pos config. After odoo restart on the iot box it gets detected as blackbox correctly and its name changes. Now after it's sent to the db the user ends up with a blackbox in the scale field in PoS config. This PR removes the automatic scale configuration so that doesn't happen Forward-Port-Of: odoo/enterprise#89888
The VoIP softphone interface now works better on smaller screens by adding scrolling where content was previously cut off and improving spacing and alignment. This helps users access call controls and transfer options more reliably on compact displays.
Original PR description
This commits fixes minor layout issues: - It adapts some views that had no scroll bar when the viewport was small. This prevented access to part of content. - It revises some spacing and alignment on…
This commits fixes minor layout issues: - It adapts some views that had no scroll bar when the viewport was small. This prevented access to part of content. - It revises some spacing and alignment on small screens. - It defines small transfer buttons in "outline" style to maintain consistency with the others tabs. task-4908502 | Before | After | |--------|--------| |  |  | |  |  | |  |  | |  |  | |  |  | |  |  | |  |  | Forward-Port-Of: odoo/enterprise#89679 Forward-Port-Of: odoo/enterprise#89005
Indian reports now use the official state name "Odisha" instead of the outdated "Orissa". This keeps report labels aligned with Government of India terminology and avoids confusion for users reviewing tax reporting information.
Original PR description
Issue: As per Government of India guidelines, the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in report. Solution: Updated the records from "Orissa" to "Odisha". opw-4935633 Forward-Port-Of: odoo/enterprise#89947
Users can now share shortcut folders from the cog menu next to the breadcrumbs, matching the behavior available for regular folders. This removes a small usability gap in Documents and includes cleanup of unused code.
Original PR description
Before this commit, the share action in the cog menu (next to the breadcrumbs) wasn't available for shortcut folders. This commit fix this issue. This commit also removes some dead code. Task-4897840 Forward-Port-Of: odoo/enterprise#89161 Forward-Port-Of: odoo/enterprise#88512
This fix prevents HR jobs from being linked to contract templates belonging to a different company. It also updates Belgian salary package demo data so examples follow the same company-alignment rule, reducing setup errors in multi-company environments.
Original PR description
task-4885755
25 changes
Resolved issues and error corrections
The mail module now warns when activity types reference invalid models instead of automatically clearing those values. This avoids unintended data changes in stable versions while still flagging inconsistent configuration for follow-up.
Original PR description
Just warn models are invalid, but do not reset for stable. Data is not enforced hence no real issue with wrong models. Followup of odoo/odoo#156731 Forward-Port-Of: odoo/odoo#218549
Marketing cards now display date and time fields using the timezone most relevant to the record, such as an event's local timezone, instead of defaulting to UTC. This makes shared event and marketing information clearer and less likely to confuse recipients in different regions.
Original PR description
When possible we want to fetch a date field in its relevant timezone not in UTC. As that is generally what you want people to share. task-4936298
This fix makes cash rounding details optional during electronic invoice generation. It prevents errors when the information is not provided, helping invoice exports continue reliably.
Original PR description
Recently in commit b033a87bbf38ed12364ebf2e3ce0cefb2670470f the UBL generation was improved to handle cash rounding better. I.e. a new key 'cash_rounding_base_lines' was introduced to the `vals` used in the generation. This commit makes it optional to avoid tracebacks in case it is forgotten to be added. task-None
This fixes an accounting issue that allowed users to create invoices containing a line without an item identifier. After the change, empty invoice items are blocked, helping keep invoice data complete and reducing billing errors.
Original PR description
Description of the issue/feature this PR addresses: Creating an invoice with an empty item is possible. Current behavior before PR: Creating an invoice with an empty item is possible. Desired behavior after PR is merged: A line with empty item identifier should not be possible. opw-217383 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet component up to its latest version, fixing several issues around pivot tables, date handling, row sizing for links, and demo actions. It also improves performance when importing Excel files and when working with pivot table caches, making spreadsheet workflows more reliable and responsive.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bc6f00d82 [REL] 18.0.37 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bc6f00d82 [REL] 18.0.37 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/816a13960 [PERF] pivot: don't invalidate cache needlessly [Task: 4933971](https://www.odoo.com/odoo/2328/tasks/4933971) https://github.com/odoo/o-spreadsheet/commit/05feba730 [FIX] pivot: don't aggregate calculated missing value [Task: 4933818](https://www.odoo.com/odoo/2328/tasks/4933818) https://github.com/odoo/o-spreadsheet/commit/c8b32d783 [FIX] Cells: newline is not a valid date separator [Task: 4910327](https://www.odoo.com/odoo/2328/tasks/4910327) https://github.com/odoo/o-spreadsheet/commit/edc7cab1e [PERF] import xlsx: avoid reading all cells multiple times during table_conversion [Task: 4699860](https://www.odoo.com/odoo/2328/tasks/4699860) https://github.com/odoo/o-spreadsheet/commit/c4eeba37e [FIX] Config: remove eslint [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f77fe7015 [IMP] config: ignore .DS_Store file from mac os [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/39f760127 [FIX] header_size: resize row based on link label instead of full link [Task: 4886598](https://www.odoo.com/odoo/2328/tasks/4886598) https://github.com/odoo/o-spreadsheet/commit/d4eca5564 [FIX] pivot: allow to group by error [Task: 4886041](https://www.odoo.com/odoo/2328/tasks/4886041) https://github.com/odoo/o-spreadsheet/commit/c799ddb6d [FIX] demo: fix `clear` action again [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/54ec6d405 [FIX] demo: Fix new `clear` action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix restores an optimized database lookup for attachment relationships used by the HTML editor. It helps large Odoo databases delete attachments much faster, reducing delays for users and administrators managing high volumes of files.
Original PR description
On a DB with 15M+ attachments, deleting a single attachment takes several seconds. Most of the time is spent on the circular `original_id` foreign key.
We add back the index which was removed in [1]
```
Delete on ir_attachment (cost=0.43..8.45 rows=0 width=0) (actual time=0.274..0.274 rows=0 loops=1)
-> Index Scan using ir_attachment_pkey on ir_attachment (cost=0.43..8.45 rows=1 width=6) (actual time=0.252..0.253 rows=1 loops=1)
Index Cond: (id = 82807)
Planning Time: 0.049 ms
Trigger for constraint ir_attachment_original_id_fkey: time=2330.796 calls=1
```
[1] https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prCreating an invoice from a sales order for certain service products could fail if the automatically created project had been deleted first. This fix prevents that error by safely ignoring missing linked accounting records, allowing invoicing to continue as expected.
Original PR description
When creating an invoice from a sales order linked to a service-type product that auto-generates a project, deleting the project before invoicing caused an error: "Record does not exist or has been deleted." This fix filters `browse()` result using `exists()` to ensure that the linked distribution account still exists. Steps to reproduce: - Create a service product that creates a project on order - Add it to a sales order and confirm - Delete the project - Try to create an invoice → error occurs opw-4891937
Industry apps now show a clearer “Reset” action instead of a misleading “Upgrade” label. Users are also warned when a major version change could affect existing records, helping them avoid unexpected data issues.
Original PR description
### Before this commit: Activated industry apps had an "Upgrade" button with was slightly misleading, since the button was actually reseting the module regardless if there is a new version or not. ### After this commit: The "Upgrade" button has been named "Reset" for better clarity. Additionally in case of a major change in module version a warning will be raised to signal to users potential record breakage in case of upgrade. - Lines flagged by ci/security should be safe because it only reads zip imported file paths and extracts module names if they exist. task-4752273
The India state list now uses the official name “Odisha” instead of the outdated “Orissa”. This keeps contact address data aligned with current government naming and avoids confusion for users selecting Indian states.
Original PR description
<b>Steps to reproduce:</b> 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country "India", then open the State dropdown. 4. Observe that "Orissa" appears instead of the updated name "Odisha". <b>Issue:</b> As per [Government of India guidelines](https://www.mha.gov.in/sites/default/files/2022-08/odishaAlterationAct2011%5B1%5D.pdf), the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in the state selection. <b>Solution:</b> Update the name of the state from "Orissa" to "Odisha" in state records. <b>opw-4935633</b> Forward-Port-Of: odoo/odoo#218342
Customers will no longer see delivery as free when the final shipping cost is only known after delivery. The checkout now shows a clear notice that the delivery charge will be calculated later, reducing confusion and incorrect expectations.
Original PR description
Issue: If the delivery invoice policy was set to "real" (meaning that we'll invoice the real delivery cost, after delivery), the delivery was shown as being free on eCommerce (since we don't know the cost yet). Fix: Show a disclaimer indicating that the cost will be computed after delivery. opw-4779059
This change makes an automated mail test more stable by blocking external online and offline network signals during the test. It helps reduce false failures in Odoo's validation system, improving confidence in release checks without changing user-facing behavior.
Original PR description
Before this commit, the `show warning when bus connection encounters issues` test was sometime failing. [1] attempted to fix this issue and seems to have greatly reduced its frequence. However, the bus monitoring service still listens to the "offline" event. As a result, the test can still fails according to the runbot network condition. This commit fixes the issue by preventing the "online"/"offline" events during this test. fixes runbot-226443 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how outgoing product quantities are calculated in Manufacturing. It helps ensure users see more accurate stock availability and demand information when planning or managing production.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a regression that prevented users from using menu icons in formats other than PNG. After the change, common formats such as GIF, ICO, JPEG, SVG, and WebP work again, restoring expected flexibility for customizing menus.
Original PR description
Description of the issue/feature this PR addresses: PR #135607 breaks support of image types other than `png` for menu icons. This puts back the support for previously supported image types. Current behavior before PR: You can't use a menu icon which has a type other than `png`. Desired behavior after PR is merged: You can use `gif`, `ico`, `jfif`, `jpeg`, `jpg`, `svg` and `webp` files like version `16.0`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218131
This fix removes a default grouping setting from attendance reports that caused spreadsheet pivot views to duplicate grouping information. As a result, users can insert attendance reporting data into spreadsheets without the previous integration error.
Original PR description
The attendance reporting action had search_default_groupby_name in its context, causing duplicated group_by entries in pivot views used in spreadsheets. This breaks spreadsheet insertion. We removed the default groupby to restore compatibility. Related Task: 4897934. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Colombian electronic invoicing integration now formats invoice type codes with the two characters required by DIAN. This helps prevent invoice submissions from being rejected due to incorrectly formatted document types.
Original PR description
The DIAN endpoint only accepts Electronic Invoice types with a length of 2 characters. This fix adds zero-padding to the problematic edi types. task: 4882683
When Peppol document reception is configured to use only a Documents folder, Odoo will no longer automatically select a purchase journal. This keeps the setup aligned with the user's chosen routing option and avoids unintended accounting configuration.
Original PR description
In the Peppol settings, you can choose to receive your documents in an accounting journal, a documents folder, or both. However, when we only select a folder, the compute method of the journal field will still choose a purchase journal by default. We don't want that. This fix makes sure that we only compute the journal when no folder has been set. no-task
Rental combo products now correctly show available booking dates when stock limits are enabled. This prevents customers from seeing all rental dates as unavailable and helps preserve online rental sales.
Original PR description
Issue: - Create a rental product (with a rental pricing), - Make it storable and don't allow out-of-stock orders, - Now make it a combo product, - Add a rental combo choice (to be able to save it), - Go to the product's page on eCommerce, - Issue: all dates are unavailable. Cause: The date range picker only relies on `allow_out_of_stock_order` to know whether to compute rental availabilities (but not on `is_storable`). Fix: Also rely on `is_storable` to know whether to compute rental availabilities. opw-4846084
The Peru stock reporting module now uses the correct product category reference when generating Stock Move PLE valuation reports. This prevents an error that could block users from opening PLE 13.1 reports after creating inventory receipts.
Original PR description
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to…
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to `Peru`, and switch to this company. - Go to `Receipts` in `Inventory`, create a `new receipt`, and `validate` it. - Go to `Valuation` and click on `PLE Reports`. - Select the `start date` as the day after today, and click on `PLE 13.1`. `KeyError: 'category'` This error occurs during the valuation of the Stock Move PLE reports. In the query, we retrieve product_template.categ_id as category_id [1], but later category [2] is used to access category_id. Since the category key is not present in the line, this causes the error. [1] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L241 [2] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L303 This commit ensures that category_id is used in place of category for safe evaluation. sentry-6723761615 Forward-Port-Of: odoo/enterprise#89379
This fixes a rental checkout issue where manually entered rental dates were not properly confirmed unless the full input flow was simulated. Customers can now save rental date selections more reliably, reducing checkout friction for rental products.
Original PR description
## Version 18.0 saas-18.1 Non existing test from saas-18.2 ## Issue Commit a16a25b6023d2d48ad5c00853728c1498509b5a5 introduced a bug while not simulating the entire flow allowing to save a rental date input. runbot-229659 runbot-229660
This fixes an issue where failing part of a quality check during a receipt could incorrectly mark related product movements as picked. Warehouse teams now get more accurate receipt statuses after quality inspections, reducing confusion and preventing premature processing.
Original PR description
Steps to reproduce the bug:
- Create two storable products: "P1" and "P2"
- create a quality control point:
- operation: receipt
- products: “P1” and “P2”
- Failure location: any one
- Create a receipt for 1 unit of P1 and 2 units of P2
- Pass the quality check for P1
- For P2, pass 1 unit and fail the other
Problem:
A new move for P2 is created to the failure location, but as a result, both moves for P2 are marked as picked, whereas the move for P1 is not. Solution:
We shouldn’t mark any move as picked during the quality check.
Partial backport of: https://github.com/odoo/enterprise/pull/77985/commits/48bfc8a860fa4b5b5e9ea153932f34b47bdcec6c
opw-4902059Fixed an error that could block users from failing a quality check on manufacturing orders for multiple serial-number-tracked products. This lets production and quality teams continue processing affected orders without an unexpected system crash.
Original PR description
Steps to reproduce the bug: - Create a storable product: - Tracking: By Serial Number - BoM: - component: C1 - Create a Quality Point: - Measure by: Quantity - Operation: Manufacture - Failure…
Steps to reproduce the bug:
- Create a storable product:
- Tracking: By Serial Number
- BoM:
- component: C1
- Create a Quality Point:
- Measure by: Quantity
- Operation: Manufacture
- Failure Location: Any (e.g., WH/Input/Order Processing)
- Create a Manufacturing Order for 2 units of P1
- Confirm
- Assign serial numbers
- Try to fail the quality check
Problem:
A traceback is triggered:
```
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(234, 235)
```
When validating a manufacturing order for a serial-number-tracked
product in multiple units, the order must be processed unit by unit.
However, when failing the quality check, the code tries to access and
assign all finished move lines to the quality check, which causes an
error because multiple records are returned
(and a singleton is expected).
At this stage, since the serial numbers are not yet assigned,
the finished move lines are still indistinguishable. Therefore, we can
safely use the first record to proceed with the quality check.
opw-4874199
Forward-Port-Of: odoo/enterprise#89430Indian tax reporting now uses the official state name "Odisha" instead of the outdated "Orissa". This keeps reports aligned with Government of India naming guidelines and avoids confusion in compliance documents.
Original PR description
Issue: As per Government of India guidelines, the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in report. Solution: Updated the records from "Orissa" to "Odisha". opw-4935633 Forward-Port-Of: odoo/enterprise#89947
This fixes a company consistency error that could block Inventory installation after generating Belgian 281.50 tax forms. Businesses using Belgian accounting reports can now complete the workflow without unexpected setup failures.
Original PR description
### Steps to reproduce: - Install l10n_be_reports & account_accountant. - Switch to "BE Company CoA" company. - Add "281.50" tag to "YourCompany" contact. - Accounting > Configuration > Accounting >…
### Steps to reproduce: - Install l10n_be_reports & account_accountant. - Switch to "BE Company CoA" company. - Add "281.50" tag to "YourCompany" contact. - Accounting > Configuration > Accounting > Chart of Accounts > Add "281.50 - Commissions" tag to 600000 account in CoA. - Create a Vendor Bill for partner "YourCompany" selling "[E-COM11]". Date it sometime in 2024 and confirm. - Go to Accounting > Reporting > Open 325 Forms. - Create a new form for 2024. - Verify that there is a line for "YourCompany" in the form and generate the XML. - Try to install Inventory. #### > Traceback due to a company inconsistencies. ### Cause of the issue: When creating the new `l10n_be.form.281.50` form for 2024, we create a record for "BE Company CoA" and which `partner_id` is the `res.partner` "YourCompany" which does not belong to any company (and hence is accessible from any). However, on the `forms_281_50` related field of the `res.partner` model is `check_company=True`: https://github.com/odoo/enterprise/blob/bc36a68b68c3d0296ee18c3a121b029dd418f430/l10n_be_reports/models/res_partner.py#L15-L23 Currently, this did not matter because we did no call of the `_check_company`. But if we where to launch a call of the `_check_company` on "YourCompany" `res.partner` we would raise a company error. Now, when you install stock 2 things happen and provoke this call: 1) The `res.partner` model becomes `_check_company_auto`: https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/res_partner.py#L8-L10 2) We create a warehouse for "Your company and update the `partner_data` https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/stock_warehouse.py#L143-L145 https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/stock_warehouse.py#L315 However, the `property_stock_customer` and `property_stock_supplier` are `check_company` related fields: https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/addons/stock/models/res_partner.py#L12-L17 Therefore, writing on them for a `_check_company_auto` record will launch a call of the `check_company` for all the fields of the record (including the already inconsistent `forms_281_50`): https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/odoo/models.py#L3780-L3781 https://github.com/odoo/odoo/blob/b7dbf15aa8116e51708bd51b8dda9bd12bba0a9e/odoo/models.py#L3867-L3868 ### Fix: We loosen the company check on the `forms_281_50` to not rely on the `_check_company` since the current workflow lead functionally to valid record data's that will always be considered invalid by this method. opw-4845434
This update removes an outdated payment filter that could no longer work after related search logic was removed. It helps prevent errors when handling online payment batch records, keeping payment workflows more reliable.
Original PR description
The aim of this commit is removing account_online_linked from the last domain which uses it. It couldn't work as we removed the search method. no task id
This update aligns Belgian payroll reporting with the 2025/2 DmfA requirements. It helps ensure payroll declarations remain compliant with the latest Belgian social security reporting rules.