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#209961
Forward-Port-Of: odoo/odoo#207075

In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...).

This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values.

However, before this commit, the logic was incorrect. It didn't take into the account the fact that date and time formats are language dependant. It assumed that the required space for the english formats (+ a bit of security margin) was enough. Moreover, the fonts may obviously has an impact as well (some fonts requiring more space to display the same text, than others).

As a consequence, on macos and, for instance, in deutch, date and datetime values were trimmed, which is something we never want: dates and datetimes should always be fully displayed. This is even worse in some languages, like arabic, basque or chinese, in which the month and/or the day of week is displayed in letters.

This commit comes with a more elaborated solution to deal with those variable date and time formats + fonts. We no longer hardcode the ideal widths of dates and datetimes, but instead compute it (lazily) once, by rendering values in the DOM.

This commit also improves the datetime and daterange cases with option "show_time" set to false: in that case, we know those fields only require the width of date values, not datetime, so we can shrink their columns.

Task~4801116

Forward-Port-Of: odoo/odoo#210300

Steps to reproduce:
- Install accounting, Sales apps
- Setup two companies for the current user with two diff currencies
- In company A, make a SO on a product and create an invoice
- Validate and confirm the invoice.
- Go to accounting, reporting, invoice analysis, and add group for the product
- Select the report of that specific invoice posted
- Observe the values untaxed_total, avg_price, inventory_value and price_margin
- Switch to company B, and add a currency rate between both currencies to observe a difference
- Make sure that you are selecting both companies, but B as the main company
- Go again to the report of the same Invoice.
- Observe the values again.

Issue:
When changing the currency, the fields untaxed_total and
price_avg are updated using the currency rate of the current
main company. However, inventory_value is not updated.

This inconsistency affects the calculation of price_margin,
which relies on both untaxed_total and inventory_value.
As a result, price_margin is computed incorrectly.

opw-4582973

Forward-Port-Of: odoo/odoo#206582

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

Steps to print the check:
1. Ensure l10n_us_check_printing is installed
2. Set the check layout to Print Check (Middle) - US
3. Create a PO and a bill from it.
4. Create a payment for the bill using checks as your payment method
5. Click Print Check on the payment

Current behavior before PR:
The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number.

Description of the issue/feature this PR addresses:
The checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas.

Desired behavior after PR is merged:
The printed check will now match the format and alignment of the templates used here:
https://checkdepot.net/collections/odoo-checks/products/odoo-checks-top- format. 

Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number.

opw-4557006
opw-4738359
Enterprise PR: https://github.com/odoo/enterprise/pull/84644
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#210074
Forward-Port-Of: odoo/odoo#208357

- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment.
- Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account.
- Make a purchase using the `"demo"` payment method with the new partner.

The generated invoice and its corresponding journal entry do not share the same `account_id` (Account Receivable).

The invoice uses the `account_id` computed in `_compute_account_id` of `account.move.line`, which is not necessarily the same as the `account_id` set on the partner.

After this commit, the payment uses the same `account_id` as the related invoice, (same as _create_payment_vals_from_wizard)  avoiding any discrepancy.

opw-4669927

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#208790
Forward-Port-Of: odoo/odoo#204489

Description:
---
The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes.

Steps to Reproduce:
---
1- Create a 21% tax and another 6% tax, both are included in price
2- Create a fiscal position that will map the 21% tax by the 6% tax
3- Create a product with Price = 121€, and Tax = 21%
4- Create an invoice with this product.
5- On the (Other info) tab, set the Fiscal Position to the one created (from 21 to 6).
6- Click on update taxes and accounts: 
The price will still be 121 while the taxes will change to 6%, and total = 121.
7- Then if you added a new line with the product now after setting the fiscal pos , you will get
price= 106, tax=6%, total = 106. which are the right values.

Cause:
---
The action created for updating taxes and accounts didn't consider price changes for price included taxes.

Fix:
---
Add call to _compute_price_unit()

opw-4672466

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

Forward-Port-Of: odoo/odoo#208780

This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868.

Before the commit (1)
We would iterate through the possible items and see if the partner has the field. As the partner in the test setup does not have `company_registry`, it will iterate on the second value, `vat`, which is set on the partner https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 which will be the key `0198`

For this key, we have mocked the response:
https://github.com/odoo/odoo/blob/e62a86939b0b327e2c16a82b0829dac80ef1ff32/addons/account_peppol/tests/test_peppol_messages.py#L153-L155

After the commit (1), we stop at the first iteration since `vat` is defined on the partner's fields. The key is `0184` -> we don't have any mocked response for this key, we we wazt to load the response's body which does not exist -> kaboom

I'm not sure that we wanted to change this value in the first place as from Julien, we wanted the company registry https://github.com/odoo/odoo/commit/ad37ebefb9fb7cb3c9593730f174dd6f1d73a31e https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/DK-R-014/

+ the company registry == the vat for the danish localisation https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18

---
commit (1) https://github.com/odoo/odoo/commit/7ce1ba9f29f9

runbot-163142

Forward-Port-Of: odoo/odoo#209498

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

Currently an error occurs during post-processing of a payment transaction.

Steps to Reproduce:

 - Install the `website_sale` module.
 - Open `Reports > Quotation / Order` and enable the Invoice report option.
 - Go to the Website, place an order using the Wire Transfer payment provider.
 - Open `Scheduled Actions`.
 - Find and manually run the `Payment: Post-process transactions action`.

`MissingError: Record does not exist or has been deleted. 
(Record: account.move(22,), User: 1)`

This issue was generated because the user clicked on the invoice report option on the report 
Quotation / Order as a result, when we try to print qutation /order it tries to browse the sale.order
 with id 22 as an account.move.

This commit ensures that the is_invoice_report field is only visible when the model is account.move. 
Additionally, the_is_invoice_report method has been modified to return True only when the model is 
account.move, thereby preventing a MissingError during scheduled actions.

Sentry-6563415103


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

Forward-Port-Of: odoo/odoo#207635

Steps to print the check:
1. Ensure l10n_us_check_printing is installed
2. Set the check layout to Print Check (Middle) - US in the settings
3. Create a PO and a bill from it.
4. Create a payment for the bill using checks as your payment method
5. Click Print Check on the payment

The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number.
Before the fix, the checks printed the vendor's name in the stubs, and the date alignment in the (middle) format overlapped with the check number.

After the fix, the checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas.

opw-4557006
opw-4738359
odoo PR: https://github.com/odoo/odoo/pull/208357

Forward-Port-Of: odoo/enterprise#85578
Forward-Port-Of: odoo/enterprise#84644

This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f.

This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.

The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.

Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0

Forward-Port-Of: odoo/enterprise#85736
Forward-Port-Of: odoo/enterprise#85446