This fixes an error that could occur when Viva Wallet payment responses were sent to the point of sale. The change helps ensure payment updates reach the POS reliably without disrupting the cashier workflow.

With commit [1], we removed the method ``_get_bus_channel_name``, but at
line [2], it's still referenced, which causes an error.

AttributeError:
``'pos.session' object has no attribute '_get_bus_channel_name'``

This commit will fix the issue by using ``_notify`` for calling the notification
bus.

[1]-https://github.com/odoo/odoo/commit/3836aad466c6c111f0f0d33c357a1c7a5150f3fd
[2]-https://github.com/odoo/odoo/blob/5633d590decc6e8989c0f454a355e965f072f967/addons/pos_viva_wallet/models/pos_payment_method.py#L133

sentry-5562979975

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

This fix prevents manufacturing order overviews from crashing when the same product is configured as both a component and a by-product in a bill of materials. Users will now be protected from a setup that could trigger an endless processing loop, improving reliability when reviewing manufacturing orders.

Steps to reproduce:
- Manufacturing > Products > Bills of Material > New
- Add any item as component then the same item as by-product
- Confirm
- Operations > Manufacturing Order > New
- Pick the product associated to your newly created BoM
- Confirm > Overview

What happens and why:
Odoo raises an RPC error due to an infinite recursion between _get_components_data and _get_replenishment_lines. Both calls are made before the manufacturing order line is flagged as processed so the functions are mutually dependent on the other finishing first.
The looping call is conditionally called when document_in and document_out are the same, which seems to be why the stock moves 'move_in' (component) and 'move_out' (by-product) need to be configured this way on the BoM.

Why is this an error:
This prevents the user from accessing the overview of a valid MO.

What this fix does:
Moves the flag to before the looping call can be made, so the recursive call does not propagate infinitely.

opw-4013371

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

This fix ensures that sales order totals are correctly recalculated whenever tax rounding method settings are changed. Previously, the total amount displayed in list views would not update to reflect the new rounding method, even though the order form would show the correct amount. This resolves inconsistencies in how order totals are displayed across different views.

Steps to reproduce:
- Install "Sales" and "Accounting"
- Make a sale order with two order lines:
    - Product with price of 10.5 and tax of 7%
    - Product with price of 10.99 and tax of 7%
- Total will now depends on rounding_method used (22.99 as total or
  23.00)

Issues:
If you change the settings the total will be updated on the sale order
since it's computed by JS code however on the list view the field
`amount_total` will show the previous value. This is because the compute
is not triggered after changing the rounding method as it's missing in
it's dependencies.

opw-4035724

This update corrects how service accounts and export accounts are categorized in Chile's F29 tax report. The fix ensures services are properly included in the VAT base calculation and exports are correctly mapped to the exempt base, improving the accuracy of tax reporting for Chilean businesses.

vat base and change exempt base to exports account.

Fixed an issue in the Barcode app where scanning GS1 barcodes containing both packaging information and weight was calculating incorrect quantities. When a product uses Units as its measurement, the weight information is now properly ignored and only the packaging quantity is used, preventing incorrect multiplication of quantities.

Issue
=====

When a GS1 barcode contains both a packaging and a weight, the quantity is wrong because we use the weight as the quantity and multiply it by the packaging quantity.

How to reproduce
================

- Enable "Product Packagings" and "Units of Measure";
- Select GS1 nomenclature as the Barcode Nomenclature;
- Create a product with a packaging for multiple quantity (e.g.: 4 Units) and with a valid GTIN (e.g.: 12345600012349);
- In the Barcode app, create a new receipt;
- Scan a GS1 barcode containing both the packaging barcode and a weight (e.g.: 10123456000123493103001500) => The scanned weight is used as the quantity and is multiplied by the packaging quantity (in this example, the quantity will be 6, because 4 units x 1.5 kg = 6 units)

Expected Behavior
=================

Since the associated product uses Units as UoM, the scanned weight can't be converted into quantity (we can't convert g or kg into units), so this information should be ignored and the packaging quantity should be used alone instead.

Note that the packaging quantity will still multiply the scanned quantity if the share the same UoM category. This behavior is still supported to be able to scan multiple packagings at once. That said, this use case make sense for products using Units only.

[OPW-3988826](https://www.odoo.com/odoo/11258/tasks/3988826?cids=1)

Forward-Port-Of: odoo/enterprise#65073

Updated the accounting module's test procedures to comply with German audit trail requirements, which mandate that financial moves cannot be deleted. The fix ensures that only moves associated with the specific test company are removed during testing, while preserving the audit trail integrity required by law.

Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related.
We only need to remove the moves linked to the company of the tour.

This update removes action buttons that were incorrectly appearing on grouped summary lines in financial reports. When reports use prefix grouping to organize data, buttons now only appear on actual data lines where they can perform meaningful actions, preventing errors or unintended record creation when users click buttons on group headers.

*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports

Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record.

This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doesn't render the buttons if it is.

All other reports were adapted to use this hook now.

task-3932945

Fixed an issue where sample values in the WhatsApp Composer were not updating when users changed the WhatsApp template. Previously, the composer would display sample values from the initially selected template instead of reflecting the newly chosen template. This fix ensures that sample values now correctly update whenever a different template is selected, improving the user experience when composing WhatsApp messages.

## Before this PR
In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template.

## After this PR
The Sample Values will now update according to the selected WhatsApp Template.

Task-3996935

This update ensures Belgian payroll calculations remain compliant with 2024 regulations by updating ONSS social security rates effective April 2024, implementing new reorganization measures, and correcting maternity/paternity reporting codes for DMFA submissions. These changes are essential for accurate employee payslips and proper statutory reporting to Belgian authorities.