**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