**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
 - The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice is automatically created and amount_paid is also updated.
- At [1], the logic subtracts both the total invoice amount and amount_paid from the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is encountered again, it should be skipped to avoid double-counting.

[1]https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

**Steps to reproduce:**
- Install Email Marketing app
- Create a new campaign with Subject and Recipients
- Set plain text mail body
- Add one image using /img or /image command
- Save the template
- Remove the image
- Save the template
- Try to re-add an image, on save it will be deleted everytime

**Issue:**
During `commitChanges`, the history of the editor is in a wrong state which triggers a cleanup on
`this.wysiwyg.odooEditor.historyRevertCurrentStep();`.

This is caused by the `await saveCallback(element);` of `_onMediaDialogSave` which never resolve and never call its follow-up:
```js
this.odooEditor.historyUnpauseSteps();
this.odooEditor.historyStep();
```
The resolve is event-dependent and doesn't seem to be triggered in current versions:
`const event = $.Event("image_changed", {_complete: resolve});`

**Fix:**
Check that the current element is listening to the given event.
Might not be the proper fix as I wasn't able to reproduce the expected behavior with `image_changed` event.

related PR: https://github.com/odoo/odoo/pull/205594

opw-5245367

Steps to reproduce:
-------------------------
1. Install Timesheets and Time Off.
2. Create an employee and create a Time Off in the past week, then approve it.
3. Open All Timesheets for that employee and observe the overtime indicator.
4. Enable a multi-company environment by creating another company.
5. Remove the `company_id` from the employee’s working schedule (40h/week).

Issue:
----------
The overtime indicator shows an incorrect value.
It displays 40h instead of the expected 32h.

Cause:
----------
Since there is no company defined on the working schedule, `self.company_id.id` becomes False.
The actual leave records are linked with the employee’s company, so the search results
in an empty recordset. As a result, the employee leave is ignored.

Solution:
--------------
Take the resource company into account when building the domain,
before falling back to the calendar company.

opw-5499737




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

#### [FIX] account_edi_ubl_cii: `DeliveryParty` export

Follow-up to commit 0b3c12670e5f606a36e7d94982656ed998d67322

In the aforementioned commit we added the `DeliveryParty` node under
the `Delivery` tag.

But there are 2 remaining issues with it.
- In BIS 3.0 the `DeliveryParty` tag has only one child `PartyName` (which is mandatory)
  https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-Delivery/cac-DeliveryParty/
  This was done for the version with the new helpers (`account_edi_ubl_cii.use_new_dict_to_xml_helpers`)
  but not the version without the helpers.
- For UBL 2.0 the `DeliveryParty` tag was added for the version
  without the new helpers but not the version with the helpers.

That is fixed in this commit.

#### [FIX] account_edi_ubl_cii: export intrastat commodity code

Currently we do not export the intrastat commodity code of products.
But a field for it is available after installing `account_intrastat`.

After this commit the intrastat code is exported in the tag
`cac:CommodityClassification/cbc:ItemClassificationCode[@listID="HS"]`.

#### [FIX] account_edi_ubl_cii: update AllowanceChargeReasonCode for EPD

Currently we are using the code `66` ("New outlet discount") as
`AllowanceChargeReasonCode` for early payment discounts.
After this commit we use `64` ("Special agreement") since it seems
more fitting / general.

#### [FIX] account_edi_ubl_cii: BEG test cases: minimal invoice

This commit adds a test corresponding to the test case "Testcase01" / "Minimal invoice"
from the business expert group.

https://efacture.belgium.be/fr/article/business-expert-group-ressources

#### [FIX] account_edi_ubl_cii: BEG test cases: multi-currency

This commit adds the following nodes to the BIS 3.0 XML in case
the document currency is different from the company currency.
- `cbc:TaxCurrencyCode`: gives the company currency (it is supposed to
  be the currency in which the taxes for the invoice will be paid)
- A second `cac:TaxTotal` node that only contains a `cbc:TaxAmount` node
  giving the total tax amount in company currency / the currency specified
  by `cbc:TaxCurrencyCode`.

See here:
- https://docs.peppol.eu/poacc/billing/3.0/bis/#_vat_accounting_currency

Some local formats had this information already. The logic was removed
there. The  affected modules were:
- `l10n_anz_ubl_pint`
- `l10n_jp_ubl_pint`
- `l10n_my_ubl_pint`
- `l10n_ro_edi`

See also here:
- https://docs.peppol.eu/poac/aunz/pint-aunz/bis/#_tax_in_accounting_currency
- https://docs.peppol.eu/poac/my/pint-my/bis/#_tax_in_accounting_currency
- https://docs.peppol.eu/poac/sg/2024-Q2/pint-sg/bis/#_invoice_totals_in_gst_accounting_currency

This is in line with the following test cases from the business
expert group. They were added as tests in this commit
(https://efacture.belgium.be/fr/article/business-expert-group-ressources)
- "Testcase 10": "Invoice in USD and EUR vat"
- "Testcase 11": "Invoice in USD and EUR vat and 2021"kkjkkj

#### [FIX] account_edi_ubl_cii: PaymentMeansCode from payment method

Currently the `PaymentMeans/PaymentMeansCode` node is filled
w/o considering the "Preferred Payment Method Line" (`preferred_payment_method_line_id`)
set on the move.
We choose
- for invoices: 30 ('credit transfer') or ZZZ ('mutually
defined') depending on whether a bank account is set.
- for bills: 57 ('standing agreement')

After this commit we use the Code of the Payment Method of the
"Preferred Payment Method Line" to determine the the PaymentMeansCode

We also add the following Payment Methods so that the user has more choices.
- Credit Card
- Debit Card
- Bankgiro
- Standing Agreement
- SEPA Credit Transfer

#### [FIX] account_edi_ubl_cii: BEG test cases: cash discount

Consier a paid invoice for which we granted an early payment discount.
in case the XML is generated after the invoice is paid (discounted amount)
we do not account for that fact in the XML generation.

The total amounts in the `cac:LegalMonetaryTotal` node are not adjusted
- The `cbc:TaxExclusiveAmount` and `cbc:TaxInclusiveAmount` and
`cbc:PrepaidAmount` should reflect the reduced amounts
- This is i.e. problmeatic for the `cbc:PrepaidAmount`. It would show
  the total (unreduced) amount of the invoice; more than was actually paid.

In the XML for an unpaid invoice there are
The `cac:AllowanceCharge` node(s) representing the potential early payment discount and
`cac:AllowanceCharge` node(s) raising the total back to the unreduced amount.
In case the early payment discount was applied the latter node(s) can
/ should be removed.

This is in line with "Testcase06" from the business expert group.
(https://efacture.belgium.be/fr/article/business-expert-group-ressources)
The following examples were added as tests in this commit
- "Testcase05": "Cash Discount" (not paid yet)
- "Testcase06": "Discount with cash payment" (XML generated after paid
and epd applied)

#### [FIX] account_edi_ubl_cii: sale order discount as AllowanceCharge

Global discounts from sales orders are just displayed as invoice
lines on the inovice.
Currently they are treated the same as any other invoice lines for
the XML generation.

But they should be displayed as an `AllowanceCharge` instead.
After this commit that is the case.
The `AllowanceCharge` node has
- `AllowanceChargeReasonCode`: `95`
- `AllowanceChargeReason`: `Global discount`

To add a global discount follow theses steps
1. Ensure `sales` is installed
2. Go to Settings -> Sales -> Pricing section and enable "Discounts"
3. On a Quotation / Sale Order there should now be a "Discount"
   right above the widget displaying the total amounts.
   Click it.
4. Select "Global Discount" and a percentage.
5. A line using a special discount product is added.
6. Click "Create Invoice"
7. The same line is now on the invoice

#### references
task-4885680

Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.

### Steps to reproduce

1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
   - Expected: The message is blocked.
   - Actual: The message is sent successfully.

### Root cause

The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.

1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.

### Fix

Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.

opw-5401789

Forward-Port-Of: odoo/enterprise#104556