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

Versions
--------
- 17.4+

Steps
-----
1. Configure UoM decimal accuracy to be 0 digits;
2. create, confirm a SO;
3. create a downpayment invoice;
4. go back to the SO;
5. modify the product line's price.

Issue
-----
> AssertionError: precision_rounding must be positive, got 0.

Cause
-----
When checking for quantity changes to log on `write`, a fallback rounding value is retrieved using `precision_get`. This returns a `precision_digits` value, but is being used as a `precision_rounding` value, resulting in an error when it is 0.

In previous versions, this fallback value was never used, as `display_type` lines were skipped, and any other line is guaranteed to have a `product_uom.rounding` value.

As of 9aa52dd6418e, the constraint was changed for `is_downpayment` lines not having to be of `display_type` nor require a `product_uom` value, meaning the faulty fallback value now gets used.

Solution
--------
Remove the fallback value, and only log lines with a `product_uom` value.

opw-4566621

Forward-Port-Of: odoo/odoo#205581

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#209255
Forward-Port-Of: odoo/odoo#207635

Some views use a domain widget to edit/save a domain and use it afterwards in several places where domains must have literals only. Typically, a literal_eval is used to evaluate the (string) domain. Thus expressions like "uid" or "context_today()"" should not be used in those contexts.
Here we introduce an option "allow_expressions" (default False) for the domain field and use it to mark as invalid domains that contain expressions when the option is set to False. A notification is displayed when a domain contains an unwanted expressions.

Since we cannot expect modules like base to be updated, we have to find another system to allow the usage of expressions in the form views for the models ir.filters and base.automation: we simply hardcode those models as allowing expressions. Since for these models, the evaluation of domains is done via safe_eval but with a restricted evaluation context, we also display a notification that alerts the user that the evaluation of expressions (although accepted by the domain field) can fail.

We revert the recent commit https://github.com/odoo/odoo/commit/a6787552150434d4366e30cbeb6f6d309c2c6cb9 that introduced potentially problematic calls to safe_eval in order to allow evaluation of expressions.

Forward-Port-Of: odoo/odoo#210145
Forward-Port-Of: odoo/odoo#208876

Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the order.

Steps to reproduce:
-------------------
* Create 2 pricelists, A and B, let's say A always adds a 10$ fee
* Set both as available in the POS, with A being the default one
* On the contact "Simplified invoice parner", set the pricelist A
* Open pos
* Change pricelist to B
* Pay and validate order
> Observation: Order is not validated, 10$ left to pay

Why the fix:
------------
Prior to the use of `set_partner`, we used to simply write the partner field of the order when using the simplified invoice partner.

Now we are using `set_partner` which is a generic function that handles everything related to changing partners, such as updating pricelist. https://github.com/odoo/odoo/blob/69057e41fb4cd800d23401ead8ae11bf7cba7c64/addons/point_of_sale/static/src/app/models/pos_order.js#L941-L948

In our example since the default pos pricelist was manually changed it means that the intention was to use this set pricelist.

What we do now in this case is to check if the pricelist was purposefully changed (it differs from the default pricelist), and in this case we want to use this pricelist on the order.

opw-4662248

Forward-Port-Of: odoo/odoo#208624

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

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

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

## Version:
17.0+

## Issue:
Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal.

## Steps to reproduce:
Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer:
- Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date;
- Confirm and create regular invoice:
  - Set `Invoice Date` to the same date as the subscription;
  - Confirm and go to the invoice's preview and start payment process:
    - Use a new card for payment;
    - Check `Save my payment details` checkbox and pay.

## Cause:
The Stripe mandate needs to be filled with a start date at least equal to yesterday (https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-mandate_options-start_date). Subscription app sets the start date to the SO's `start_date` via https://github.com/odoo/enterprise/blob/5642ad28919081a44bb47c0d936aa51980178d09/sale_subscription/models/payment_transaction.py#L51-L52. The values are retrieved by `_stripe_prepare_mandate_options()` via https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L206 and sent to Stipe under a new structure given by https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L209-L220

## Fix:
Initial suggestion made in the `payment_stripe` module (https://github.com/odoo/odoo/pull/207451), but later moved to the origin of the issue. As of 2025-05-12, Stripe seems to have fixed the issue, but this patch is still applied as a safety measure.

opw-4654142

Forward-Port-Of: odoo/enterprise#85635
Forward-Port-Of: odoo/enterprise#85314