**Steps to reproduce:**
- Install `point_of_sale`.
- Go to POS -> configuration -> settings
- Search 'Operation type' -> open picking type -> Disable `Create new`
- Create a storable product 'test' with serial tracking.
- Add on-hand quantity with serial numbers.
- In POS, select the product and choose one SN,
- Select it again and choose another SN.

**Observation:**
- The order line should have 2 quantities with a list of Serial numbers chosen by the user. For one quantity, it's working fine, but for multiple quantities, an issue occurs.

**Issue:**
- While confirming edit serial numbers popup for multiple quantities, it checks whether each selected SN is valid or not.
- The condition is that the entered SN is in the existing available SNs option. But the already chosen SN is not in the existing SN option,
- Also, creating a new SN is disabled, so it's considered an invalid input.
https://github.com/odoo/odoo/blob/876b7337eb689e0682ab48e9e833f9f0dc6bb8d2/addons/point_of_sale/static/src/app/store/select_lot_popup/select_lot_popup.js#L190-L193

**Solution:**
- Added a condition to allow SNs that are already selected (matched by name and ID) to be considered valid inputs.

opw-4865902

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

Forward-Port-Of: odoo/odoo#221058
Forward-Port-Of: odoo/odoo#219205

**Before this commit:**
When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed.

**Steps to Reproduce:**
1. Enable "Automatic Invoicing" from Sales settings.
2. Enable and publish any payment provider (e.g., Demo) in test mode.
3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner.
4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm.
5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment.

**Fix:**
This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4850293)
opw-4850293

Forward-Port-Of: odoo/odoo#221997
Forward-Port-Of: odoo/odoo#221587

**Step to reproduce:** 
1. Install purchase and account module. 
2. Enable the uom option (Purchase > Configuration > Settings).
3. Create a vendor (partner).
4. Set up companies (have at least two companies).
5. Create a product (Vendors bills > Product) that is shared across two companies.
6. Go to Vendors > Product : in the product’s Purchase tab:
                    - Add the same vendor twice - one line for each company.
                    - Assign different UoMs (e.g., “Unit(s)” for US company and “Kilogram(s)” for AT company).
7. Switch to one company. 
8. Create a vendor bill in one of the companies using that product and vendor.

**Issue:** 

A ValueError is raised when creating the vendor bill:

`ValueError: Wrong value for account.move.line.product_uom_id: uom.uom(1, 2)`

https://github.com/odoo/odoo/blob/0e23327c322acbdf6acfecd52385ffee0266220c/addons/account/models/account_move_line.py#L806-L807

**Cause:** 

During the computation of product_uom_id  where retrieves all seller records
matching the partner_id  but fails to limit the result.

**Solution:** 

To fix this, retrieve sellers by both partner_id and company_id and first matching 
seller is used. This ensures the UoM is correctly set according to the company also.

opw-4877577

Co-authored-by: PIYUSH <pish@odoo.com>

Forward-Port-Of: odoo/odoo#217137

## Short functional explanation of the error
When clicking on "create and edit" on a Sales Order Item field in a task, the company field is left blank. As a result, the taxes linked to the product don't appear.

## Reproduction Steps
1. Install the modules sales, timesheet and project.
2. Make sure that you have at least 2 different companies in the settings.
2. Click on the project app and create a new project. Check the Billable and Timesheets boxes.
3. Create a task and click on it. Set a customer: the field "Sales Order Item" should appear.
4. Click on the "Sales Order Item" field. Type random letters and click on "create and edit".
5. Select a product that has at least one tax.

### Expected behavior
The company field should be filled as soon as we click on the create and edit button, and the taxes field should be filled with the taxes of the
 product as soon as we select said product.

### Unexpected behavior
The company and taxes field remain empty.

## Origin of the issue
Some fields were set at "default_."

__
opw-4904861

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

Forward-Port-Of: odoo/odoo#221342

**Before this commit:**
When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed.

**Steps to Reproduce:**
1. Enable "Automatic Invoicing" from Sales settings.
2. Enable and publish any payment provider (e.g., Demo) in test mode.
3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner.
4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm.
5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment.

**Fix:**
This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard.

opw-4850293

Forward-Port-Of: odoo/enterprise#91761
Forward-Port-Of: odoo/enterprise#91570

When tax integrations are sent from a credit note (of a vendor bill) they should have a negative value, as it is the reversal operation. However, currently the amounts are positive, so it appears to be a second Bill rather than its reverse.

**Steps to reproduce (with an IT Company)**

- Create a non-eu [PARTNER] with complete address and VAT
- Create a Vendor Bill with:
  - Partner: [PARTNER]
  - Electronic Invoicing > Document Type set to TD18
  - A line having Reverse charge tax (ie. 22% G RC)
- Confirm and send tax integration
- Reverse move
- Ensure the document type is set to TD18 as well
- Confirm and send tax integration
- Check the generated xml

**Issue**

Credit note tax integration will have a positive amounts, while being a credit note it should have negative amounts This occurs because when generating the xml, the document type is recomputed from the invoice features, even if the user set it manually

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4788529)
opw-4788529

Forward-Port-Of: odoo/odoo#221672
Forward-Port-Of: odoo/odoo#220878

**Before this commit:**
When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed.

**Steps to Reproduce:**
1. Enable "Automatic Invoicing" from Sales settings.
2. Enable and publish any payment provider (e.g., Demo) in test mode.
3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner.
4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm.
5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment.

**Fix:**
This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4850293)
opw-4850293

Forward-Port-Of: odoo/odoo#221997
Forward-Port-Of: odoo/odoo#221587

**Step to reproduce:** 
1. Install purchase and account module. 
2. Enable the uom option (Purchase > Configuration > Settings).
3. Create a vendor (partner).
4. Set up companies (have at least two companies).
5. Create a product (Vendors bills > Product) that is shared across two companies.
6. Go to Vendors > Product : in the product’s Purchase tab:
                    - Add the same vendor twice - one line for each company.
                    - Assign different UoMs (e.g., “Unit(s)” for US company and “Kilogram(s)” for AT company).
7. Switch to one company. 
8. Create a vendor bill in one of the companies using that product and vendor.

**Issue:** 

A ValueError is raised when creating the vendor bill:

`ValueError: Wrong value for account.move.line.product_uom_id: uom.uom(1, 2)`

https://github.com/odoo/odoo/blob/0e23327c322acbdf6acfecd52385ffee0266220c/addons/account/models/account_move_line.py#L806-L807

**Cause:** 

During the computation of product_uom_id  where retrieves all seller records
matching the partner_id  but fails to limit the result.

**Solution:** 

To fix this, retrieve sellers by both partner_id and company_id and first matching 
seller is used. This ensures the UoM is correctly set according to the company also.

opw-4877577

Co-authored-by: PIYUSH <pish@odoo.com>

Forward-Port-Of: odoo/odoo#217137

**Steps to reproduce:**
1. Install Inventory > Go to Inventory > Configuration > Tick Storage Locations.
2. Go to Operations > Deliveries > create a new delivery.
3. Add two products: one with on-hand quantity, one without.
4. Set demand quantities > mark as To Do, check availability, and try to print.

**Issue:**
- A traceback (IndexError: tuple index out of range) occurs when printing picking report if a product has 
  no reserved quantity, due to missing move lines.

**Cause:**
- The template attempts to access `move.move_line_ids[0]` without checking if `move_line_ids` is non-empty. 
  This raises an IndexError if there's no move lines.
https://github.com/odoo/odoo/blob/f539705023993e284dce5dc1027c3c3af9c42d75/addons/stock/report/report_stockpicking_operations.xml#L143-L146

- Also, move lines with zero quantity are displayed in the picking operation report.
<img width="529" height="94" alt="image" src="https://github.com/user-attachments/assets/61c439a2-16c4-44aa-a664-fbec672f6226" />

**Solution:**
- Add a check to ensure `move.move_line_ids` is non-empty before accessing the first element.
- Add filter to avoid rendering move lines with zero `quantity` in the delivery.


**opw-4961985**

Forward-Port-Of: odoo/odoo#220317

**Before this commit:**
When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed.

**Steps to Reproduce:**
1. Enable "Automatic Invoicing" from Sales settings.
2. Enable and publish any payment provider (e.g., Demo) in test mode.
3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner.
4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm.
5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment.

**Fix:**
This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard.

opw-4850293

Forward-Port-Of: odoo/enterprise#91761
Forward-Port-Of: odoo/enterprise#91570

This PR is divided in 2 commits:

A first commit is an implementation AU specific and will create the lines related to tax on
salary in the tax return closing entry. Before this commit, these lines
weren't taken into account in the closing entry.
The condition to select the account.move.line are the following:
- The journal item has a "W2", "W3" or "W4" (Withholding Tax) tax grid 
whose journal entry is linked to an hr.payslip.
- The journal item does not have an originating tax record (i.e.,
tax_line_id is empty).
- The journal item is posted to a tax provision account (i.e., a balance
sheet one) as defined on the salary rule.

A second commit fixes a bug: the manifest of the l10n_au_hr_payroll_account module was having a
'countries': ['au'] dependency, that was adding a condition to the
dependencies to auto install the module: we expect an existing AU
company in DB. But for example if the user installs l10n_au, the
condition is evaluated at the moment he clicks on install, and no AU
company exists at that time.

Task-4921992

Issue:
When the "Lock Confirmed Sales" setting is enabled, adding a product to a Field Service task would lock the associated sales order before its picking could be created. The confirmation process locks the order first , and the subsequent step to create stock moves (`_action_launch_stock_rule`) explicitly skips locked orders.

Reproducible on 17.0~master
[Task](https://www.odoo.com/odoo/action-4043/4633977)
Odoo 17:
https://drive.google.com/file/d/1qmAYhSu6gU91efuJEDF-Irn2cLGUQP0A/view?usp=drivesdk

Odoo 18:
https://drive.google.com/file/d/1x8IeXwT7ZFM7Av9Vp6GSvGIbOaEGfmVx/view?usp=drivesdk


Steps to reproduce:
1. In Sales > Configuration > Settings, enable "Lock Confirmed Sales".
2. Go to a Field Service task.
3. In the kanban view via the "Products" smart button, add a product.
4. Come back to the task, refresh the browser, open the linked Sales Order from the smart button.
5. **Before this fix:** The SO is locked, no picking is created, and SO lines will have delivered_qty set even though we haven't delivered anything.
6. **After this fix:** The SO is not locked, and a Delivery smart button is correctly displayed, linking to the generated picking.

This behavior left the sales order in an inconsistent state: it was locked, but had no corresponding delivery order. As a result, users were blocked from removing or modifying the products added to the task, as the system prevented edits on a locked order with no picking to cancel.

Let's step through what's going on here;

0. We enable "Lock Confirmed Sales" option.
1. Add a product to the Field Service(FS) task https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L19-L42
https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L38
2. set_fsm_quantity() is invoked, which will create a SO for the FS task https://github.com/odoo/enterprise/blob/35e1f47160d5840e8701fc0ad43ec42bbfaf9e36/industry_fsm_sale/models/product_product.py#L144
3. `_fsm_create_sale_order()` will immediately `action_confirm()` the new SO, because of the reasons in the function description. 
( Since we are immediately confirming newly created SO, I think we should consider not applying the "Lock Confirmed Orders" option to FSM SOs.)
https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L124-L134 https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L134
4. `odoo/addons/sale/models/sale_order.py/action_confirm()` will lock SO because we enabled 'Lock Confirmed Sales'
https://github.com/odoo/odoo/blob/863c064fd911cb4eeedad0abec82adb4690128f6/addons/sale/models/sale_order.py#L964
6. `_action_launch_stock_rule()` is invoked, is in charge of creating Pickings for SOs 
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L303
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L343-L344
7. But, since `line.order_id.locked` , the system do not create Pickings for the SOs. https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L315-L316
The line was introduced by
https://github.com/odoo/odoo/commit/17bece3e797913bcba8dd7e07fc8541c0a45e3f7

This commit resolves the issue by passing a context key `fsm_create_sale_order=True` when confirming a sales order that is being created from a Field Service task. The `_should_be_locked` method on the sale order is overridden to check for this context key. If the key is present, it prevents the order from being locked within that specific transaction, allowing the stock rules to execute correctly and create the necessary picking. The order will be locked for any subsequent operations as intended.

Tradeoff here;
We are sacrificing the universal application of one feature (automatic lock on confirmed sales order) to fix a critical bug that makes the entire FSM delivery process unusable.

---
EDIT: 
Without this change, all of [test_fsm_stock](https://github.com/odoo/enterprise/blob/17.0/industry_fsm_stock/tests/test_fsm_stock.py)'s test cases that use `_fsm_ensure_sale_order()` will fail if the setting is on. (around ~20 test cases). 

[In the past, similar issue occurred for Subscription Orders, and the PO confirmed that the "Lock Confirmed Order" setting should never affect the subscriptions. ](https://github.com/odoo/enterprise/commit/e4f9d76c0a58f3cc226a2372f3936cea4547312e). This commit takes the same approach to ignore the setting upon SO confirmation. 

opw-4633977
opw-4749653
opw-4880664

Forward-Port-Of: odoo/enterprise#91563
Forward-Port-Of: odoo/enterprise#88855

The aim of this commit is to keep the original foreign amount currency
if the computation ends up close enough to it.

Before this commit:
The reconciliation process was losing so much precision that it could mess up
the reconciliation of one single invoice.

After this commit:
We keep the original amount as it is most probably the correct one.

Context:
With a rate of 1 US$ = 5.421327349 R$ and an invoice of 143.62 R$, we
convert the amount in US$ which is 26.491668921649627 US$.
As we have to round it for the accounting, we end up with 26.49 US$ as
company currency amount, losing the rest of the decimals.
During the reconciliation process, we convert back the US$ to R$ ending
up with 143.61096147501 R$ that have to be rounded to 143.61 R$.

This creates a difference of 0.01 R$ which surfaces later on.

Chosen solution:
As we still have the original currency amount and the rate, we are able
to recompute the raw numbers and we are able to make "fairer" comparison
between the amounts.
If we can confidently tell that the amounts are close enough, we
can just keep the original amount and prevent all those rounding errors
to be taken into account.

opw-4937508

Forward-Port-Of: odoo/enterprise#91650
Forward-Port-Of: odoo/enterprise#91462

Currently, an error occurs when the user again pays for sale subscriptions.

Step to produce:

- Install the ```sale_subscription``` module.
- Create a new sale order, add a customer name, add a product in the order line that has 'Subscriptions', and add a 'Recurring Plan' with date and confirm the sale order.
- Create an invoice for this sale order and confirm it.
- Back to the sale order, click on 'Renew' button.
- Open a preview of the sale order, and click on 'Sign & pay', and come back to the edit mode of the sale order.
- Again open a preview of the sale order.
- Again click on 'Pay' for this sale order subscription.

```TypeError: unsupported operand type(s) for *: 'NoneType' and 'float'```

An error occurs when the system attempts to compare invoice amounts with the recurring amount at [1], but value of an invoice amount is 'None'.

Link [1]:  https://github.com/odoo/enterprise/blob/df2735cdd067df9ec88cad8202da2314ffd9d65a/sale_subscription/controllers/portal.py#L396

To handle this issue, provide a default amount for an invoice as zero.

Sentry-6014356823