Point of Sale receipts now show items priced at zero as “Free” instead of displaying “0.00”. This makes receipts easier for customers and staff to understand when complimentary items or promotions are included.

For orderlines with a price of 0, the receipt will now display the price as 'Free' instead of '0.00'.

Enterprise PR: odoo/enterprise#51338
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This update removes an internal workaround used when creating chat channel members and replaces it with a cleaner approach. It improves maintainability in the mail/discuss area without changing the expected user experience.

Relying on such a hack, checking a sentinel against a value in the context to check from where the method was called is really not a good practice.

Especially when there is a nicer way to do it.

Free items on receipts will now display "Free" instead of "0.00" for better clarity and professionalism. This improvement applies to point-of-sale systems in Belgium and Sweden, making receipts more user-friendly and easier to understand at a glance.

pos*: pos_blackbox_be, pos_l10n_se

For orderlines with a price of 0, the receipt will now display the price as 'Free' instead of '0.00' and will remove the tax letter following this price.

Community PR: odoo/odoo#143285

Added validation checks to a menu editing test to catch timing issues where dialogs weren't closing properly. This improvement helps prevent intermittent test failures and makes it easier to identify similar issues in the future.

The test "edit/delete menus" sometimes failed on runbot (error 23054) because there're 3 .btn_primary in the footer, whereas only one is expected. When this happened, it was because the second dialog wasn't closed yet. This commit adds assertions on the number of dialogs, which helped to understand and reproduce the issue, and which can also help in the future.

Related to PR odoo/odoo#143813 which fixes the issue.

Forward-Port-Of: odoo/enterprise#51587

This update gives businesses more control over automatic data predictions when importing electronic invoices (EDI). Instead of automatically overwriting imported values, companies can now opt-out of automatic predictions and customize how products, accounts, and taxes are predicted based on their specific needs. This is particularly useful for Italian invoice imports where different fields require different prediction rules.

Odoo may allow prediction to occur when importing an EDI.
i.e. predicting the product, account and taxes of each line.
By default, those predictions will overwrite the actual value.

Though it may be helpful in some cases, there should be a way
to opt-out of the this automatic overwrite and to have a more
flexible way to do those predictions.

Here is how this is now possible:
1. With `disable_onchange_name_predictive` one can
indicate their desire to opt-out of the prediction overwrite
(i.e. the default behavior).
2. They can then use the `_predict_product`, `_predict_account`,
`_predict_taxes` methods to create their own way of prediction.
Placeholders for those were created to allow their use even if the
prediction module isn't present.

NB: As the module in charge of predictions (`account_accountant`)
is not always installed the `edi_prediction_enabled` context key is
used to indicate whether the prediction methods can be used or not.
In the case of this fix, the key is setup in the `l10n_it_reports`
module, as this module is always installed if `account_accountant`
and `l10n_it` are installed.

This way of predicting is useful for cases demanding a less generic
approach to prediction. e.g. For the Italian EDI module the account
of a line can be predicted without any limitation as it is not a value
imported by the EDI. Whereas, its product and taxes should be predicted
only if none were imported.

opw-3201391
opw-3172035

Community PR: https://github.com/odoo/odoo/pull/144437

Forward-Port-Of: odoo/enterprise#51835
Forward-Port-Of: odoo/enterprise#38079

This update refreshes the Spanish language translations for the Mexican Electronic Invoice (EDI) module. The changes ensure that users in Spanish-speaking regions see accurate and up-to-date text throughout the invoicing system, improving the user experience and maintaining compliance with regional requirements.