**Steps to reproduce:**
- Install Website/Event/Sales apps
- Create a new event and set a ticket price
- Create a fiscal position (with specific tax) for a country with `auto_apply` enabled
- Publish the event
- Register to the event as a anonymous user
- The process bypasses the address form and goes directly to payment
- The resulting sale order will have no fiscal position
- Prices won't be impacted by taxes related to the user billing address

**Issue:**
Address form is skipped before payment for event registration of a public user as `_needs_customer_address` is not overwritten properly in some module. This is probably due to a refactoring that changed how the required information is evaluated in the payment flow (see related commit).

**Fix:**
Set `_needs_customer_address` to `True` by default to avoid such issues in
dependant modules. Might need to remove this feature in master as the workarounds are
not that clean (geo_ip, check on fiscal position enabled, overwrite everywhere, others ?).

Similar fix is done for appointments with payment enabled.

related: https://github.com/odoo/odoo/commit/d43f0423667835512e16c3fd3474328da63a948d
original-task: https://www.odoo.com/odoo/project/49/tasks/4307281

opw-5143124

Forward-Port-Of: odoo/odoo#248291
Forward-Port-Of: odoo/odoo#247054

Steps:
- Install `website_slides`
- Edit a course
- Add a section in the slides
- Save
- Section is automatically changed into document slide

The problem stems from the fact that the widget that manages sections in website_slides uses the `is_category` field to function (display certain fields in the list view).

However, this `is_category` field has been removed since saas-19.1 in the following [diff](https://github.com/odoo/odoo/pull/230098/changes#diff-87985c6cb54c5ab6dd4b71da844d0478e70c3c8247d54c943113ba75a4af0188L85 )
with a view to getting rid of invisible fields in views and adding them automatically in `ir_ui_view`.

But in `IrUiView::_add_missing_fields`, this field is added as read-only.

https://github.com/odoo/odoo/blob/02af5899563ddc362d04522339a5bdb793e01b52/odoo/addons/base/models/ir_ui_view.py#L1530-L1545

On the client side, when saving a `web_save` is performed by omitting `is_category`, because we are not supposed to save/write read-only fields.

Since the field has a default value of false, we end up with a slide that is not a section

```py
    is_category = fields.Boolean(`Is a category`, default=False)
```

To fix this problem, we directly correct `slide_category_one2many` which uses is_category without ever checking that the field is available by adding a relatedFields that specifies that we need is_category and not readonly.

Note: we have exactly the same problem with section_and_note in the `account` module, which uses the `display_type` field, but here it works because in its view we kept the field when deleting all invisible fields.

https://github.com/odoo/odoo/blob/8128a1bfbdd7b2f7cdc8ccbf1ddf78219a809e38/addons/sale/views/sale_order_views.xml#L568-L569

opw-5898399

Currently, an error occurs when user tries to create a new warehouse when Inventory loss stock location is not present.

Steps to replicate:
- Install repairs and enable Storage Locations in settings.  
- Go to `Inventory > Configuration > Locations`, open `Inventory Adjustment`.
- Change the `Location Type` to `Internal` (anything other than `Inventory Loss`).
- Navigate to Warehouses and try to create a new one.

Error:
```
  File /home/odoo/src/odoo/19.0/addons/stock/models/stock_warehouse.py, line 142, in create
    new_vals = warehouse._create_or_update_sequences_and_picking_types()
  File /home/odoo/src/odoo/19.0/addons/stock/models/stock_warehouse.py, line 373, in _create_or_update_sequences_and_picking_types
    create_data, max_sequence = self._get_picking_type_create_values(max_sequence)
  File /home/odoo/src/odoo/19.0/addons/repair/models/stock_warehouse.py, line 30, in _get_picking_type_create_values
    scrap_location_id = self.env['stock.location'].search_read([('usage', '=', 'inventory'), ('company_id', 'in', [self.company_id.id, False])], fields=['id'], limit=1)[0].get('id')
IndexError: list index out of range
```

Cause:
- Since the user changed the location type of `Inventory adjustment`, the `search_read()` [1] returned no results and attempting to access its first element causes the error.

Solution:
- Raised a UserError when no Inventory Loss location is found while warehouse creation.

    


[1]: https://github.com/odoo/odoo/blob/62b9f7a81e8d742508d6c80434bb4caf78f9dc65/addons/repair/models/stock_warehouse.py#L30

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

Forward-Port-Of: odoo/odoo#242535

## Issue
When generating multiple serial numbers in a single manufacturing order, interpolations are not replaced. For example, if the sequence prefix is `%(month)s`, the placeholder is not be replaced by the current month, and the generated serial numbers contain `%(month)s` literally.

This issue also impacts the `mrp_subcontracting` serial numbers generation by causing a similar issue as the second bug described by https://github.com/odoo/odoo/commit/20158a1. When creating a duplicate of a subcontracted manufacturing order, the *First SN* field (`lot_name`) is initiated to `1` again, instead of starting from the last SN of the previous MO. This issue was supposedly fixed by https://github.com/odoo/odoo/commit/9cd0c4a, but the issue still occurs when using interpolated prefix.

## Steps to reproduce
1. Install *Manufacturing* (`mrp`)
2. In Settings, enable *Lots & Serial Numbers*
3. In Settings > Technical > Sequences, give a prefix using interpolation to the `stock.lot.serial` sequence. An example of such prefix could be `%(year)s-%(month)s-%(day)s-`
3. Create a product P
    - Tracked *By Unique Serial Number*
    - Create a BoM for the product P
4. Create and confirm a Manufacturing Order for product P
    - Quantity >= 2
5. Click *Generate Serial*
6. **The _First SN_ field uses the interpolation without replacing the placeholders. When clicking _Generate_, more serials are generated where the placeholders are not replaced. If we proceed, the produced serial numbers still contain the placeholders.**

If we generate a MO with a quantity of one, the serial number is correctly generated (the placeholders are replaced as expected). 

## Cause

The method responsible for replacing the interpolation placeholder is `IrSequence._get_prefix_suffix` which is called by `IrSequence.get_next_char`:

https://github.com/odoo/odoo/blob/bf7dee8069f203095c44381708153865d3e8f19e/odoo/addons/base/models/ir_sequence.py#L240-L242

Generating a single serial numbers work as expected because it calls `MrpProduction.action_generate_serial`, which uses `IrSequence.get_next_char` further down the call stack.

When generating **multiple** serial numbers in a single MO, the [`mrp.production.serials` wizard](https://github.com/odoo/odoo/blob/19.0/addons/mrp/wizard/mrp_production_serial_numbers.py) is used. In this flow, `get_next_char` is never called, because the serial number logic is reimplemented using fields (`serial_prefix_format` and `next_serial`) from the `product.product` model.

## Fix
Serial numbers are generated from the *First SN* (`lot_name`) field. Correctly applying the interpolation to that field ensures that all subsequently generated serial numbers also use the interpolated values. Because `mrp_subcontracting` inherits the behavior from `mrp` to generate the lot_name, fixing this issue in `mrp` also solves it in `mrp_subcontracting`.

When initiating the `lot_name` field, we need to take in account cases where the product does not have a `lot_sequence_id`. This can happen if the sequence of the product was deleted. The same check is not required when updating the `number_next_actual`, as if there's no `lot_sequence_id`, there's no `number_next_actual` to update.

The logic updating the `number_next_actual` has also been adjusted to ensure the field is incremented correctly. This was an issue corrected by https://github.com/odoo/odoo/commit/20158a115ef3dfb9fe2dd5103d3bed7e87e37940 and https://github.com/odoo/odoo/commit/3ff0f2e3ef4fbcbf0b0b0ae6db8ff6f52bfdf67a, but without taking interpolated prefixes into account.

opw-5882578

Forward-Port-Of: odoo/odoo#246762

Currently, users can `create` new `Lots/Serial Numbers` directly from the 
Contacts app via the `Lots/Serial Numbers` smart button.

**Steps to reproduce:**
- Install the `stock` and `contacts` modules.
- Enable `Lots & Serial Numbers` from the inventory settings.
- Open the `Contacts` app and open any contact record.
- Click the `Lots/Serial Numbers` smart button.

**Observation:**
The user can `create` a new lot/serial number from the Contacts, even 
though this flow is not supported and results in inconsistent data.

**Root cause:**
After PR [1], `lot/serial number` creation was accidentally enabled from the 
Contact. The intended behavior is that Contacts should only be able to view 
related lots/serial numbers, not create them. (Confirm with PO `crl`)

**Fix:**
This commit disables the creation of Lot/Serial Numbers from the contact by 
`hiding` the New button. This prevents users from creating inconsistent records 
until a complete and correct flow is implemented in a future improvement 
as mentioned at [2].

[1]:
https://github.com/odoo/odoo/pull/184242

[2]:
https://www.odoo.com/mail/message/978482657

opw-5504073

Forward-Port-Of: odoo/odoo#245426

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028

Currently, an `incorrect warning` message is shown when sending an invoice to 
`DIAN`, if the invoice date is 6 days before today, even though this 
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1], the allowed invoice date range is incorrectly computed, using 
`5 days in the past` and `10 days in the future`. This does not match the Colombian 
regulations and triggers incorrect validation errors for valid invoice dates.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to 
`6 days before and 6 days after` the current date, in accordance with the 
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, 
page 59, at [3].

<img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" />

[1]:
https://github.com/odoo/enterprise/blob/62f59f87a513a86a61f871ca743e7f7b04926a82/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1086-L1093

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

Forward-Port-Of: odoo/enterprise#107372
Forward-Port-Of: odoo/enterprise#105763