This commit fixes an issue from report_invoice_document.
In the “show_payment_term_details” t-if, there was a single td
containing the `invoice_payment_term_id`.

In another module, `l10n_gcc_invoice`, we use this td in the following
xpath:
```xml
<xpath expr="//div[@id='total_payment_term_details_table']//td" position="before">
```
The problem is that a td cannot be used outside of a table, which will
cause incorrect HTML to be generated and therefore prevent Studio from
working on it.

One solution would be to replace the incorrect td with div, add a class
`early_payment_discount` to it, and create a new customization that
would target this time
```xml
<xpath expr="//div[@id='total_payment_term_details_table']//div[@id='early_payment_discount']" position="before">
```

In order not to break the current customization targeting the old
incorrect td, we keep it but this time in a correct `table/tbody/tr/`
and we do not display it in the final report.
This will be removed in master.

A new `oe_structure` has also been added below the Terms to allow people
who want to add a field below to do so, as this is currently not
possible. The only way to do this is to add a modification to the terms,
which will only be displayed if this field is not empty because it is in
a t-if.

opw-5248145
opw-5879285
opw-5410727
opw-5476981
opw-5381578
opw-5369618
opw-5485437
opw-5498946
opw-5331519

When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with the 'once per order' enabled, the values should be used and propagated directly on the created event.registration records, with precedence over other answers given to individual questions (not once per order)

STEPS
=====

1. Create a new event with name, email questions, once per order ticked.
2. Go to POS (reload data if needed)
3. Register and answer both questions
4. Continue the pos flow until both registrations are created
5. Go to backend > your event > registrations
6. You can see that even if the answers are propagated in the o2m field registration_answer_ids, which is expected, the attendee's name and attendee's email fields are empty. They should contain the values of step 3.

FIX
===

Align the website_event flow and precedence of OPO questions over
individual answers in pos_event. Now, the first non-null answer of an OPO
question will be used for each of the question_type values listed above,
if any, over answers to individual questions.

Also align the fact that after OPO answers, precedence should be given
to the first non-null answer to a given question type for identification
questions, and not the last as it is currently.

Task-4919080

Forward-Port-Of: odoo/odoo#231502

Bring back all tests temporarily disabled by [1]. Below are the
explanations about the needed changes in the code.

---
Change in `/project_mrp_account:MrpProduction.write`
Tested by `/project_mrp_account.test_changing_mo_analytic_account`

In the test, when changing the project of the MO:
https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/project_mrp_account/tests/test_analytic_account.py#L211-L212
We reach the override in `project_mrp_account`. On Odoo 18.0, a line
calls the method `_account_analytic_entry_move`:
https://github.com/odoo/odoo/blob/706431510110a005618a2acaf6566f2bb61d5114/addons/project_mrp_account/models/mrp_production.py#L31
This line is in charge of creating AA/AAL related to the SM. However,
the commit [1] has removed `account_analytic_entry_move` and all its
calls. This is why the test fails in the first assert:
https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/project_mrp_account/tests/test_analytic_account.py#L210
It doesn't find anything. However, the commit [2] brings the method
back with a brand-new name: `_create_analytic_move`. We therefore
need to connect it again where it is needed.

---
Change in `/stock_account:StockMoveLine.write`
Tested by `/project_mrp_account.test_update_components_qty_to_0`

Quite the same as above. Commit [1] removes this while it's actually
needed. One difference, a `sudo` call, because a stock user doesn't
have any access to analytic world.

---
Change in `/stock_account:StockMoveLine.unlink`
Tested by `/project_mrp_account.test_mo_qty_analytics`

Same as above, also with a new `sudo`.

---

[1] https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229
[2] 35db55618fa70146afc89e662410aca95947e17b

Steps to reproduce:
- Choose France as the company location, and download "France - Work Entries Time Off" module.
- From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off.
- Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025.
- While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone.
- From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025.
- From the employee's profile > Time Off, try to take a Monday off.

Issue:
- The user gets a Validation error stating that the "start date" is later than the "end date".

Fix:
- In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off.
- Add a check to remove lines from calendar that are just there for display purposes.

opw-5387347

Forward-Port-Of: odoo/odoo#246094

Steps to reproduce:
-------------------
1. Install sale_management with demo data
2. Create a new quotation/order and add a section and a subsection
3. Drag the subsection line above the section line
4. Confirm it and click on Preview

Issue:
------
```python
Traceback (most recent call last):
The error occurred while rendering the template sale_subscription.subscription_portal_content and evaluating the following expression: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>

Error while rendering the template:
    AttributeError: 'NoneType' object has no attribute 'collapse_prices'
    Template: sale_subscription.subscription_portal_content
    Reference: 1713
    Path: /t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]
    Element: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
    From: (1712, '/t/t', '<t t-call="portal.portal_layout"/>')
          (1712, '/t/t/body/div[1]/div/div[2]/div[11]/div/t', '<t t-call="#{sale_order._get_name_portal_content_view()}"/>')
          (1713, '/t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]', '<t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>')
```

Cause:
------
Since current_section is None in this case, it leads to the
above traceback when trying to fetch the collapse_prices value.

Solution:
---------
Convert subsection lines without a parent_id into section lines
to prevent the traceback.

Related enterprise PR: https://github.com/odoo/enterprise/pull/103686


opw-5367739





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

**Problem:**
when there is multiple pages for the avco reports
the total value and quantity are not correctly computed

**Steps to reproduce:**
- create an avco storable product with a cost of 10
- create and validate 3 in moves for a quantiy of 1 each
- navigate to Inventory/ Stock and search your product
- click on the unit cost
- (see how the total quantity is 3 and total value is 30)
- change the view to display only the first 2 records
(write 1-2/4 on the top write)

**Current behavior:**
the total quantity is now 2 and total value 20

**Expected behavior:**
it should still be 3 and 30

**Cause of the issue:**
inside _compute_cumulative_fields, we start with a 
total_value and total_quantity of 0, then those variables 
are increased or decreased by each record in records
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L94-L104
but records is computed based on self which contains
the lines displayed on the view
https://github.com/odoo/odoo/blob/89cc95266fa0d9a0fd4caae9abe1effbfea1a41a/addons/stock_account/report/stock_avco_audit_report.py#L91

**fix**
I need to add an if statement to avoid writing on the records
not displayed on the view because this causes an access_error

opw-5421925

### Steps to reproduce:

- In the settings enable: Multi-Steps route
- Create a product tracked by SN
- In the barcode app > Operations > Internal transfers > New
- Scan you tracked product
- Click on Validate > Invalid operation
- Scan a Serial number
#### > You can not click on validate anymore

### Cause of the issue:

The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since  orm call returns an error the the call the validate method is interupted at this orm call and the line
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133

### Fix:

We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 :
https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135
we have the guarantee that the records will not be validated twice.

opw-5388297

Forward-Port-Of: odoo/enterprise#104963
Forward-Port-Of: odoo/enterprise#103835

Current behaviour:
Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup.

Expected behaviour:
Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume).

Steps to reproduce:
1. Create new delivery method
2. Configure Starshipit API credentials.
3. Attempt to select a service.
4. Observe that not all service is shown from the available options.

Cause of the issue:
Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods.

Fix:
Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.

Forward-Port-Of: odoo/enterprise#103316

**Steps to reproduce:**
* Install the **Accounting** and **partner_commission** modules.
* Create a contact and set a **commission plan (e.g. 50%)** in the *Partner Assignment* tab.
* Create and confirm a customer invoice with multiple lines (e.g. 750, 750).
* Then go to **Dashboard → Transactions**, create a new transaction (e.g. 750) and reconcile it with the created invoice.
* Create a **credit note** from the invoice and confirm it.
* Open the contact and access **Purchase Orders** from the stat button.

**Observed behavior:**
* Only the commission line from the original invoice appears in the partner purchase order.
* No **negative commission line** is created for the credit note.

**Cause:**
* Credit notes reused the original commission linkage instead of generating a dedicated commission entry.
* This prevented commission reversal from being recorded for refunds.

**Fix:**
* Generate a **separate commission line** with a negative amount for each credit note.
* Assign a dedicated `commission_po_line_id` to credit notes.
* Copy only the `referrer_id` to credit notes, not the original commission line reference.

opw-5357773

Steps to reproduce:
-------------------
1. Install sale_subscription with demo data.
2. Create a new subscription and add a Section and a Subsection.
3. Add a recurring product (Invoice_policy = 'order') and configure a recurring plan.
4. Confirm the subscription and click Preview.

Issue:
------
```python
Traceback (most recent call last):
The error occurred while rendering the template sale_subscription.subscription_portal_content and evaluating the following expression: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>

Error while rendering the template:
    AttributeError: 'NoneType' object has no attribute 'collapse_prices'
    Template: sale_subscription.subscription_portal_content
    Reference: 1713
    Path: /t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]
    Element: <t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>
    From: (1712, '/t/t', '<t t-call="portal.portal_layout"/>')
          (1712, '/t/t/body/div[1]/div/div[2]/div[11]/div/t', '<t t-call="#{sale_order._get_name_portal_content_view()}"/>')
          (1713, '/t/div[4]/section[1]/div[1]/table/tbody/t[4]/t[11]/t[3]', '<t t-set="collapse_prices" t-value="current_section.collapse_prices or line.collapse_prices"/>')
```

Cause:
------
`_get_invoiceable_lines` does not treat subsection lines as children of their parent section.
As a result, `lines_to_report` contains a subsection without its corresponding section,
leaving current_section set to None and causing the traceback when accessing current_section.collapse_prices.

Solution:
---------
Ensure subsection lines are appended together with their parent section
when an invoiceable line is encountered

Related community PR: https://github.com/odoo/odoo/pull/241634

opw-5367739