This update fixes a spelling error in the Belgian localization module where the French abbreviation for the National Social Security Office was incorrectly spelled as "ONNS" instead of the correct "ONSS". This ensures accurate account naming and compliance with official Belgian terminology in the system.

Office National de Sécurité Sociale (ONNS) should be (ONSS).

This update removes an outdated requirement for Norwegian Bronnoysund field data when creating electronic invoices. The system now uses the newer, more flexible Peppol endpoint fields that were introduced in version 16.2, making it easier for businesses to configure their invoice routing without needing localization-specific fields.

In saas-16.2, the `peppol_endpoint` and `peppol_eas` fields were added on the partner. These fields are used to fill the `<cbc:EndpointID` node.

Before that, we had to map every localization specific field to this node. For instance, with the norvegian "Bronnoysund" field (see: [1]). To ensure the node was filled, a constraint was checking the existence of this field.

Now that we have the `peppol_endpoint` and `peppol_eas`, we no longer have to require the bronnoysund to be filled.

[1] https://github.com/odoo/odoo/blob/saas-16.1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L119

opw-3763725

Forward-Port-Of: odoo/odoo#155604

This update fixes a problem where Raspberry Pi 5 devices were generating excessive error messages in system logs when trying to detect connected displays. The fix adds better error handling to prevent these messages from cluttering the logs, making the system more stable and easier to monitor. Once devices receive this update, they will handle display detection issues gracefully without filling up the logs with errors.

Currenlty, on raspberry pi 5 our dislay interface is invading the logger with errors due to the absence of both tvservice and the required vcgencmd methods to identify the connected displays

The goal of this PR is to avoid this

![displayinterface](https://github.com/odoo/odoo/assets/36443074/6c9876f2-7efd-4c54-ad8e-fdf35c0953b3)

While searching for a solution to properly detect displays on a raspberry pi 5 we can avoid the excessive log errors by protecting the subprocess calls.

When used with vcgencmd, the python wrapper of 'vcgencmd' bash utility is missing the 'Vcgencmd().display_power_state()' method on raspberry pi 5, which causes a subprocess.CalledSubprocessError because the wrapper itself is missing a try/except block arount its subprocess call [here](https://github.com/sushantnadkar/vcgencmd/blob/68578dd887f2e0f62c1e8bf95323574cfc489be0/vcgencmd/vcgencmd.py#L18)

Tvservice is not used on new rpi models so there is no need to protect it

While the errors will still be present in the logs for a fresh image at the moment,
once an rpi5 is connected to a database, it will receive the code from this PR and will handle the exceptions more gracefully

[task-3771334](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=1428&model=project.task&view_type=form&id=3771334)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#155615

This update fixes an unreliable automated test for scheduling activities in the mail module. The test was failing inconsistently across different build environments because it relied on a fixed timeout that wasn't long enough. The fix replaces the timeout with a more reliable check to ensure the activity type data is ready before proceeding, making the test more stable across all builds.

Since PR #154105, `mail_activity_schedule_from_chatter` test was failing on some runbot builds. The problem is, the `timeout` to make sure the activity type input is ready (has its data) to click again, is not enough for all builds.

Instead of using timeout (which is not same for different builds), we can add an extra step to check if the activity id input has its data after clicking on dropdown, to proceed to the next steps.

fixes runbot-57738

This update corrects an inventory testing issue where the system properly handles annual inventory dates that fall on days that don't exist in certain months (like February 29th in non-leap years). The test was updated to properly verify this safeguard works correctly across leap years and regular years.

When a company's annual inventory day is selected which is higher than the number of days in that month, there are already safeguards in the feature to ensure the latest day possible for that month is selected. Unfortunately the related test forgot to take this into account for leap years, so this commit modifies it to test for this expected safeguard.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#155841