When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt:
- An Exchange diff account move would be created, and the Stock Input Account would not be balanced

This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rate journal entry is created, and a discrepancy in the Stock Input Account balance is introduced.

When the bill is posted before the receipt is validated, we want the receipt to have the value of the bill, and there is no reason to have only the balance or the amount in currency from the bill, so we can take both of them.


https://github.com/user-attachments/assets/c6dc5e72-8f5b-4c0f-99fa-c5e98a9574ff


## How to reproduce:
- Install stock_account,purchase
- Create product P:
    * Valued in AVCO automated.
    * Control Policy to 'On ordered quantities'
- Add currency rates for the EUR currency:
    * 2.0 on the 2025-01-01
    * 2.1 today
- Create and Confirm a new purchase for 1 unit of P and a price of 100 Euros
- Create the Bill:
    * Set the bill's accounting date & bill date to the 2025-01-01
    * Confirm the bill
          => Amount in Currency: 100 Euros - Balance: $50 USD - Rate used: 2.0
- Go back to the PO and receive the product.
          => Amount in Currency: 105 Euros - Balance: $50 USD - Rate used: 2.1
- Check the created Journal Entries:
          => Currency exchange rate difference: $2.38
          => (105 - 100) / 2.1

OPW-4631348

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

Forward-Port-Of: odoo/odoo#209667
Forward-Port-Of: odoo/odoo#209118

# Context

Building on a recent PR (https://github.com/odoo/odoo/pull/188697), we introduce multiple small tweaks to enhance the life of support agents and system admins that work a lot with the log files in the the context of email related issues.

# Changes

* A given `mail.mail` record being processed by the `_send` method can end up sending multiple emails under the hood ( if `recipient_ids` points to muliple ids). This means that the ratio between one `mail.mail` record and the number of email sent through SMTP is not always 1:1. We added a new log line that counts the total emails processed in the loop which should give a more precise estimation of the real number of emails attempted through SMTP

* Given the above, we the usual log line was not reporting all the (redacted) list of email addresses but only the `email_to` of the last `msg` value created during the inner loops. We now correctly show a comma seperated list of all recipients in a given batch.

* The historical log line `Sent batch %s emails via mail server ID #%s` could be missleading as it was not counting the number of emails but the number of `mail.mail` records processed. It was reformulated to account for this.


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

Forward-Port-Of: odoo/odoo#206657

**Steps to reproduce:**
- Install l10n_it_edi_ndd
- Switch to an Italian company (e.g. IT Company)
- Create an invoice
- Confirm the invoice
=> Document Type (in "Electronic Invoicing" tab) is computed
- Create a credit note from the invoice
- On credit note wizard, click on "Reverse and Create Invoice"
- Check the created credit note

**Issue:**
The credit note is posted but its Document Type field (l10n_it_document_type) is empty.
l10n_it_document_type should be computed when it doesn't have a value already and the state of the move is "posted".
The credit note will be rejected when sent to SDI because this field is empty.

**Cause:**
In the reverse method, the field is set to False in order to be recomputed.
However, the compute method is triggered when the state changes, but the credit note not is already posted.
Therefore the field will not be recomputed.

**Solution:**
Set the value to False before the creation of the credit note.
So that, the field will be recomputed when posting the credit note.

opw-4689755




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

Forward-Port-Of: odoo/odoo#208654

When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder.

Steps to reproduce:
-------------------
* Create 2 products, one with a cost of 20 and one with a cost of 0
* Create a PoS order with 2 lines, one for each product
* Validate the order using the shiplater option
* Close the session and go to the picking created
* Validate the delivery only for the product with a cost of 20 and make a backorder for the product with a cost of 0
* Go to the session accounting entries and check the COGS entries, you should see one entry for the product we just processed
* Validate the backorder
> Observation: A second COGS entry is created for the product with a
  cost of 20

Why the fix:
------------
Instead of creating the COGS entries based on the PoS order lines, we now create them based on the stock move lines. This way, we only create the COGS entries for the stock move lines that are actually processed. We also avoid creating COGS entries for the stock move lines that have no cost.

opw-4597430

Forward-Port-Of: odoo/odoo#207075

Step to reproduce:

- install accounting
- in the dashboard searchbar, add a `Group By` with value `type`
- go to vendor bills view from the dashboard
- upload any file

Error:

Wrong value for `ir.attachment.type`: 'purchase'

Expected:

The upload process should go on without any error

Explanation:

in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earlier are thus also added as `default_type` in the context.

But when creating a record, the ORM checks for all `default_*` key in the context and try to use it as additional values for the created record. Since the key-value combination `type` and `purchase` is not valid in an `ir.attachment` record, it throws this error.

Solution:

Before passing the context, we have to make sure to clean all the `default_*` contexts to avoid these kind of behaviors. In python, usually we use `clean_context` method before calling `create`. But since this is in JS, we manually filter all key-value item that starts with "default_" in the context object.

opw-4512697

Forward-Port-Of: odoo/odoo#201628

The aim of this commit is to:
    - avoid reporting negative amount in a 281.50 form which are rejected by the administration.
    - avoid reporting form with 0 value everywhere which are rejected by the administration.
    - avoid reporting a form with an amount < 250 EUR

Context:
The administration stated that we don't need to make any report that would be above 250 EUR.
(art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92)

https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50 https://travaillerensociete.indicator.be/main/newsadvice/52784/news/52785/news_story/533/ https://www.monastucesetconseils.be/2025-04/fiches-fiscales-281-50-pour-le-29-juin-2025-WAACPCAR_EU33150802

Before this commit:
Odoo could create a form with a negative amount as commission/fee/... This could result in the administration software converting the xml into a BOW file to generated an error and a file that will be rejected by Belcotax.
Same for form with 0 everywhere.

Also, accountants always end up deleting the 281.50 form below 250 EUR as those don't need to be reported.

After this commit:
Odoo don't report negative or null total amount as commission/fee/... and doesn't create any form if the total amounts are below 250 EUR saving accountants the burden to remove them.

task-id: None
This was discussed and done with TSB and DELC and is also the result of our past experiences reporting 281.50 forms which also involved CAHE, MAKR and CAL.

Forward-Port-Of: odoo/enterprise#85508

Steps to reproduce:
(thanks to TBS for investigating + writing the test)

1. Have a MX company with Quadrum or SwSapien
2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN`
3. Create a USD invoice for `13220.00 USD` and send CFDI
4. Reconcile transaction and invoice
5. Click "Update payments" on the invoice => CRP20211

Looks like it comes from this rounding difference

Rate is computed by odoo using
`305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`

PAC verify the amount paid using
`13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN`

Solution:
There is no solution by adapting the rate:
- quadrum restricts the rate to 6 decimals;
- rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`.

So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly
`round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`.

In tests, both Quadrum and SwSapien seem to accept this.

We don't perform the modification for Solucion Factible (the other PAC).

opw-4222310

Forward-Port-Of: odoo/enterprise#83499