**Steps to produce:**
- Install `website_sale` with demo data.
- Go to the shop page.
- Select product `Customizable Desk` > click `Add to cart`.
- In the wizard, change the quantity to 100 and directly click `Checkout`.

**Issue:**
- The cart shows the product with quantity = 1 instead of the edited value.

Root cause:
- When the user clicks Checkout, both `setQuantity` and `onConfirm` are triggered
  almost simultaneously.
- At [1], the `_setQuantity` method is called, but due to the await before the
  quantity update is completed, the update may not finish in time. As a result,
  the previous quantity is sometimes used during checkout instead of the
  newly selected one.

Solution:
- we can update the quantity immediately before awaiting `_updateCombination`,
  ensuring that the correct quantity is already set when onConfirm runs.

[1]: https://github.com/odoo/odoo/blob/f4eabe47a602301013afa63da6bdf87809903d29/addons/sale/static/src/js/product_configurator_dialog/product_configurator_dialog.js#L225

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

Forward-Port-Of: odoo/odoo#247866
Forward-Port-Of: odoo/odoo#241424

If provided a `datetime.time`, `babel.dates.time_format` needs to complete it to a datetime in order to resolve timezone offsets (and legacy names). In order to do that, it ultimately uses "now" as the reference: [`format_time`] calls [`DateTimePattern.apply`] which calls [`DateTimeFormat.__getitem__`] which calls
[`DateTimeFormat.format_timezone`] which calls [`get_timezone_gmt`] which calls [`_get_datetime`], which for a `datetime.time()` input resolves:

    return datetime.datetime.combine(datetime.date.today(), instant)

This means DST changes impact the timezone being resolved timezone (offset or legacy name), which is what occurred here: S summer time starts on the second sunday of March at 0200 local which for 2026 is 2026-03-08 0200, faketime builds started failing with a virtual time of 2026-03-08 12:00 UTC which is well past 0200 local in America/New_York, and thus into the summer timezone, with an offset of -0400, thus different from the reference offset of -0500.

The reference date can be fixed to anything which results in standard time in all the timezones being checked, so between the first sunday of november (end of DST in the US) and the last sunday of march (start of DST in Europe), in the past (to ensure no DST rules change). Just use the reference date of the test itself as it's fine enough.

Now why did this test pass before #236660? This was hinted at when I needed to fix the offset from -0504 to -0500 but it didn't register as it was a minor edit: because the timezone was associated via `tzinfo` rather than `localize`, `pytz` was not able to select the correct timezone so would just select some prehistorical timezone, which doesn't have DST rules associated, and so would remain on standard time year round.

With the switch to zoneinfo the timezone can be interpreted dynamically, leading to the timezone offset varying when the reference date changes, and thus the issue revealing itself.

And `odoo.misc.format_time(datetime)` has a similar issue, because it strips out the `date` part of a `datetime` input, so similarly babel itself receives a lone zoned time, which it resolves using the date at the time of the test running. Which is funny because `babel.dates.format_time` itself can take a `datetime` and will use that directly for its timezone resolution, so on this bit we shot ourselves in the foot.

https://runbot.odoo.com/odoo/runbot.build.error/238900

[`format_time`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L841
[`DateTimePattern.apply`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L1424
[`DateTimeFormat.__getitem__`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L1487
[`DateTimeFormat.format_timezone`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L1675
[`get_timezone_gmt`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L459
[`_get_datetime`]: https://github.com/python-babel/babel/blob/56c63caf50b18b152541b5dcafd51f645d867074/babel/dates.py#L158

**Steps to reproduce:**
- Go to the current user preferences
- Go to its signature field
- The current state should be something like:
```
--
Mitchell Admin
```
- Apply bold formatting on the text
- Save the changes
- Refresh
- Remove the bold formatting
- Press enter between the two lines (at the end of `--`)
- Save the changes
- Go to the Contact app
- Select any record
- Go to its chatter
- Click on `Send Message` and then the `Full Composer` expand button
- Send the mail
- In the chatter multiple `Read More` are added for the same signature

(I think it can appears in multiple operations,
this is just an example related to the `<strong>`
element becoming `<span>` on removal)

**Issue:**
Playing with the html editor on the signature field can break the `tag_quote` flow due to the added elements.

**Fix:**
Explicitly add `"data-o-mail-quote"` to the signature container which is added when opening the `fullComposer`.
It could also be an issue related to the html_editor but this seems cleaner to fix it here.

This issue was fixed in 19.0 in a similar way by adding a common div around the signature and adding the same attribute.

related: https://github.com/odoo/odoo/commit/6eb55c42158b08652c4c533bf56b5333c162bd3a

opw-5149505

Forward-Port-Of: odoo/odoo#247560
Forward-Port-Of: odoo/odoo#231954

Currently, accessing the Forecast report on a Product Template causes a crash if the template contains an archived variant that still has active stock moves (e.g., a pending delivery).

## **Steps to Reproduce:**
1) Install `stock` with demo data.
2) Create a Delivery orders(stock picking) for product `conference chair(E-COM12)`
   with demand of 40 qty, click on `Mark as todo`.
3) Navigate to `stock>products>products` and open `conference chair` product form
   view.
4) From the variant smart button archive `E-COM12` variant.
5) Navigate back to product form view and click on `forecast` smart button.

## **Error:**
`TypeError: Cannot read properties of undefined (reading 'free_qty')`

## **Root Cause:**
`this.props.docs.product[line]` at [1] is undefined because the server did not
include an entry for that product id in the report header.

### **Complete Flow:**

On clicking the Forecast button an ORM call is made to [_get_report_values](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L512-L519),
which calls [_get_report_data](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L156-L172) to build the report data.

#### **Header Part:**
- [_get_report_header](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L112-L144) returns metadata only for active variants because,
  [_get_product_quantity](https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/report/stock_forecasted.py#L69-L72) is called which calls _get_products(see[2]), and _get_products only
  returns active variants for the product template.

#### **Lines Part:**
- [_get_product_lines](https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L239) iterates over products coming from the move search
  and it includes both archived and unarchived variants.
  [_move_confirmed_domain](https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L55-L56) calls _move_domain(see[3]), which searches stock.move using
  product_tmpl_id when given a template id and therefore returns moves for
  every variant of the template (archived or not).

#### **Why the mismatch happens:**
- `_get_products` fetches variants using `browse()` which by default excludes archived variants.
  `_product_domain`(see[3]) uses product_tmpl_id when given product_template_ids,
  which matches moves for all variants of the template. As a result, moves can reference
  archived variant ids that the header never listed.

[1]- https://github.com/odoo/odoo/blob/0dd40ede75f68b18192738f0d20aadaac9f348c7/addons/stock/static/src/stock_forecasted/forecasted_details.js#L188

[2]- https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L61-L67

[3]- https://github.com/odoo/odoo/blob/82fe034509a6b401e86c345a82aa7b8948294e52/addons/stock/report/stock_forecasted.py#L25-L31

## **Fix:**
- This commit ensures that archived product variants are excluded directly
  at move search level by appending `('product_id.active', '=', True)` to
  the product domain used by the forecast report. This ensures that only
  active product variants are considered when fetching stock moves.

### **opw-5440872**

Forward-Port-Of: odoo/odoo#245852

Currently, an error occurs when a user changes the stage of lead.

**Steps to Reproduce:**
 - Install the `crm` module.
 - Go to `crm` and switch to `List view`.
 - Click `New` and then click on any `stage`.

`AssertionError: Invalid falsy real id`

This error occurs because, after the recent commit [1], falsy IDs are no longer allowed.
When the user changes the stage without creating the record, the record ID is passed
as False when it goes to calculate the rainbowman message [2]. Browsing the record with
a falsy ID [3] then raises this error.

This commit ensures that if a record has no ID and the stage ID is changed, the rainbowman
message is not calculated.

[1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f

[2]: https://github.com/odoo/odoo/blob/6bce0128fdd5176c55ac9ed5af1922c1f6f97da5/addons/crm/static/src/views/crm_form/crm_form.js#L51

[3]- https://github.com/odoo/odoo/blob/403f3cf8d291ff2023fc4c5d3631a01465f292c3/odoo/orm/models.py#L5200

sentry-7207509338


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

**Problem:**
the cogs do not take into account lot valuation and the standard 
price of the form is not updated after a move out.

**Steps to reproduce:**
- create storable avco perpetual product, tracked and valued by lot
- confirm a purchase order for 2 qty at price 10
- in the receipt add 'lot 1' for the lot
- validate
- confirm a purchase order for 2 qty at price 16
- in the receipt add 'lot 2' for the lot
- validate
- confirm a sale order for a qty of 1, validate the move
- invoice the sale order, and confirm the invoice

**Current behavior:**
1) the cogs line (stock valuation and expenses) have a value of 13
(the avco value)
2) the standard price on the form view is still 13

**Expected behavior:**
1) it should be 10 (the value of lot1)
2) it should have been updated to 14 (weighted average of the lots value)

**Cause of the issue:**
1) get_cogs_price_unit() is taking standard price of the product
if the product is not fifo.
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/stock_move.py#L245 
In case of avco lot valuated product, this is not correct, the value should be 
the sum of (the value of each lot * the number of product from this lot in the 
moves) divided by the total quantity. 
this value can be obtained be dividing the total value of the moves by the total 
quantity. 

2) after the move is validated, the standard price should be updated because 
for lot valued product, the avco value can change after a move out. 
Currently it's only updated for fifo products.
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/stock_move.py#L172

**fix**
For the diff inside _update_standard_price() for problem 2,
I use avg_cost instead of doing the computation directly in 
_update_standard_price() to not duplicate code logic
 because the computation logic for lot valued products is 
already inside _compute_value()
https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_account/models/product.py#L152-L157

The extra dependency on compute_value on the stock.lot model 
is needed because otherwise total_value of the lot is not 
invalidated in the cache after an out mouve is validated
(in our steps it will stay in cache with a value of 20 even 
after the out move is validated). 
With our steps this does not cause problem because when we use 
the avg_cost value for the product,  \__get__() is called on total_value of the lots, 
but it was not in cache because we didn't compute it before in 
this environment , so it will be recomputed with correct current value . 
But in other cases where the action_done is called on 
the move and there is already a value in cache for total_value 
of the lots (like in the test of this commit for instance), 
this value will become wrong after the move is validated 
and the cache won't be invalidated which will lead to 
incorrect computation of avg_cost because it will use the 
wrong cache value of total_value for the lots.

the test needs to be in sale_stock because the moves used 
for the cogs are being returned via the sale_stock override 
of _get_stock_moves()
https://github.com/odoo/odoo/blob/7ae112acd0c333f09c54e4eabbd22bcef72c32a7/addons/stock_account/models/account_move_line.py#L67

opw-5459082

Forward-Port-Of: odoo/odoo#246821

Steps to reproduce on runbot
------------------
Select a product with several variants and a Bill of Materials
(e.g. Stool).

Change the variants order so that their ids are not ordered, this can
be done by modifying the default_code for example (e.g. Internal
Reference for variant "Color: Green" set to "A").

When accessing the BoM report, you won’t be able to switch to one of
the possible variants (in the example the Dark Blue variant).

Why it is happening
------------------
The default variant to be displayed when opening the report is selected
in the backend using the product_variant_id field. This field is
computed as the first element in product_variant_ids as they are
ordered in the model.

We then send this variant’s information to the frontend and a
dictionary containing every variant (key= id and value = display_name).
In the serialization process, the object is reordered based on the
keys. Thus, if the variants were not ordered based on their ids in
python, the order will change.

The displayed variant is correct as it has been passed directly but the
frontend also computes the currentVariant attribute. This is computed
as the first element in the dictionary but in this case, it is not the
one that has been selected in the backend, as the order changed.

As a result, you see the report for a variant A but the frontend
considers you are on the report for variant B so you cannot switch to
variant B as you are supposed to be already on it.

The fix
------------------
I propose to use the explicitly passed id as the currentVariantId.

opw-5409493

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

Forward-Port-Of: odoo/odoo#248009
Forward-Port-Of: odoo/odoo#241603

**Issue**
When producing a large number of serial-tracked products, a RecursionError can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Go to the MO C and split into 100 mo
- Go to the MO B and split into 100 mo
-> RecursionError: maximum recursion depth exceeded.

**Cause**
While splitting, this method is called:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError.

opw-5265424

Forward-Port-Of: odoo/odoo#247839

### Steps to reproduce:

1. In the settings enable: Multi-steps route
2. Put your warehouse in 2-step deliveries
3. Create a kit product:
   - With one component
   - There is one component in the stock
4. Create and confirm a SO with 1 x K
5. Process the pick and ship
6. Return the delivery
7. Set the sol qty to 0
#### > Two unexpected pickings are created to put the kit in output

### Cause of the issue:

Decreasing the sol quantity to 0 will call the `_action_launch_stock_rule` in order to create and run procurements related to that quantity change. However, the quantity currently handled by other procurements is determined here by the `_compute_kit_quantities`:
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_mrp/models/sale_order_line.py#L154-L166 https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/mrp/models/stock_move.py#L578-L580
Now, the issue is that `_compute_kit_quantities` does not handle move chains properly, as all delivery moves contribute to the `incoming_qty` and all return moves contribute to the `outgoing_qty`. This results in an `incoming_qty` of 1 (for the pick) + 1 (for the ship) and an `outgoing_qty` of 1 (for the 1-step return), that is a `qty_processed` of 1. As a result, the procurement will be generated for a quantity of `0 - 1` (rather than 0):
https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/sale_stock/models/sale_order_line.py#L388-L402 
which leads to the unexpected picking creations.

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

Forward-Port-Of: odoo/odoo#246141

**Steps to produce:**
- Install `mrp` with demo data.
- Inventory > Configuration > Settings > Warehouse > enable `Multi-Step Routes`.
- Go to Configuration > Warehouse Management > Warehouses.
- Open `YourCompany` record.
- Click on Routes > open `Manufacture` > enable `Products`.
- Return to `YourCompany` and disable `Manufacture to Resupply`.

**Issue:**
- After disabling `Manufacture to Resupply`, the option is automatically re-enabled.

**Root cause:**
- In [1], `manufacture_to_resupply` is set to true if either
  `manufacture_route.product_selectable` is true OR the current warehouse
  is included in `manufacture_route.warehouse_ids`.
- In the `_inverse_manufacture_to_resupply` method, unchecking the flag only
  unlinks the warehouse from the route. However, if `product_selectable` is
  still enabled, the compute logic will continue to set the field back to true.

**Solution:**
- Now, when we uncheck `manufacture_to_resupply` then also made manufacture
  route non-selectable on products. As a result, manufacture_to_resupply
  will no longer be set to true again.

[1]https://github.com/odoo/odoo/blob/4f5594a911c1960f620d902d507e563cdab167b9/addons/mrp/models/stock_warehouse.py#L48

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

Forward-Port-Of: odoo/odoo#239217

This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines.

Steps to reproduce:
1. Create payment with x amount and validate it.
2. Open the payment journal entry.
3. Reset to draft and update the liquidity line amount from x to (x - y)
4. Create another liquidity line with amount y to balance entry and post it.
5. Draft the payment and try to update the amount.

A traceback will appear. `ValueError: Expected singleton`

Cause:
The lines for payment JE are prepared for the case assuming that there will be only 1 liquidity line, but since we have more than 1, we get a Singleton error.

Description of changes made:
While preparing values for move in `synchronize_to_moves()` check for multiple liquidity lines and append all values to write.
Further, the `_prepare_move_line_default_vals()` is also improved in order to manage different type of move lines individually.

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

Forward-Port-Of: odoo/odoo#246675

**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

Forward-Port-Of: odoo/enterprise#104162

Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made.

### **Steps to reproduce:**
1) Install `l10n_gt_edi` and switch to a GT company. 
2) Create a branch of the GT company.
3) In the parent company, go to Accounting Settings, set the Guatemala
   Localization to 'Demo', and save.
4) Switch to the branch company.
5) Open Accounting Settings and click Save.

### **Observed Behavior:**
An error occurs because `l10n_gt_edi_service_provider` is empty but required.

### **Root Cause:**
The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails.

[1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22

### **FIX:**
Update the `required` domain to include `l10n_gt_edi_is_root_company`.
This ensures the field is only mandatory in the root company where it
is actually visible and configurable and also set the `l10n_gt_edi_service_provider`
for branch company same as parent company.

**opw-5385819**

Forward-Port-Of: odoo/enterprise#106323

**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

Forward-Port-Of: odoo/enterprise#104162

Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made.

### **Steps to reproduce:**
1) Install `l10n_gt_edi` and switch to a GT company. 
2) Create a branch of the GT company.
3) In the parent company, go to Accounting Settings, set the Guatemala
   Localization to 'Demo', and save.
4) Switch to the branch company.
5) Open Accounting Settings and click Save.

### **Observed Behavior:**
An error occurs because `l10n_gt_edi_service_provider` is empty but required.

### **Root Cause:**
The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails.

[1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22

### **FIX:**
Update the `required` domain to include `l10n_gt_edi_is_root_company`.
This ensures the field is only mandatory in the root company where it
is actually visible and configurable and also set the `l10n_gt_edi_service_provider`
for branch company same as parent company.

**opw-5385819**

Forward-Port-Of: odoo/enterprise#106323

Steps to reproduce:
1. Create a storable product with tracking set to 'By Quantity'.
2. Update the Quantity on Hand (e.g., 100 units).
3. Change the product tracking to 'By Serial Number'.
4. Create a Repair Order for this product.
5. Add a line, select a specific Serial Number, and click Save.
6. Observe that the serial number disappears.

Cause:
When reserving stock that was originally created as 'Generic' (no serial), the `_prepare_move_line_vals` method returns `lot_id=False`. The repair view uses `_compute_lot_ids` to display selected lots, which filters out any move lines where `lot_id` is False. This causes the new line to be effectively invisible to the UI immediately after creation.

Solution:
In the `_set_lot_ids` inverse method, explicitly force the `lot_id` into the create values dictionary (`move_line_vals`). This ensures that even if Odoo reserves generic stock, the resulting move line is born with the correct Serial Number identity, keeping it visible and valid.

opw-5156267

Forward-Port-Of: odoo/odoo#247885
Forward-Port-Of: odoo/odoo#247150

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

This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines.

Steps to reproduce:
1. Create payment with x amount and validate it.
2. Open the payment journal entry.
3. Reset to draft and update the liquidity line amount from x to (x - y)
4. Create another liquidity line with amount y to balance entry and post it.
5. Draft the payment and try to update the amount.

A traceback will appear. `ValueError: Expected singleton`

Cause:
The lines for payment JE are prepared for the case assuming that there will be only 1 liquidity line, but since we have more than 1, we get a Singleton error.

Description of changes made:
While preparing values for move in `synchronize_to_moves()` check for multiple liquidity lines and append all values to write.
Further, the `_prepare_move_line_default_vals()` is also improved in order to manage different type of move lines individually.

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

Forward-Port-Of: odoo/odoo#246675

**Steps to reproduce:**
* Install the *repair* module.
* Create a *storable product* and set some **On Hand** quantity.
* Go to *Repairs* and create a new **Repair Order**.
  Keep the repair order in *draft* state (do not confirm).
* In the **Parts** tab, add the storable product with the operation type set
  to *Add*.
* Open the **Stock Forecasted** report for the added product.
  Note the quantity shown under *Outgoing Draft Transfer*.
* Delete the **Repair Order**.
* Open the **Stock Forecasted** report for the same product again.

**Observed behavior:**
* The quantity still appears in the **Stock Forecasted** report under
  *Outgoing Draft Transfer* even after the repair order is deleted.

**Cause:**
* Deleting a draft repair order triggers `_unlink_except_confirmed`.
* This method prevents related stock moves from changing their state to
cancel when the repair order is deleted.
* The *Outgoing Draft Transfer* value is calculated as the sum of quantities
of stock moves in draft state at draft state.
https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49

https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90

* As a result, deleting a draft repair order leaves related stock moves in
draft state, causing them to appear under *Outgoing Draft Transfer*
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335

**Fix:**
* Ensure that related stock moves are properly cancelled when a draft repair
  order is deleted.

---

opw-5449323

Forward-Port-Of: odoo/odoo#247348
Forward-Port-Of: odoo/odoo#241970

**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

Forward-Port-Of: odoo/enterprise#104162

Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made.

### **Steps to reproduce:**
1) Install `l10n_gt_edi` and switch to a GT company. 
2) Create a branch of the GT company.
3) In the parent company, go to Accounting Settings, set the Guatemala
   Localization to 'Demo', and save.
4) Switch to the branch company.
5) Open Accounting Settings and click Save.

### **Observed Behavior:**
An error occurs because `l10n_gt_edi_service_provider` is empty but required.

### **Root Cause:**
The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails.

[1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22

### **FIX:**
Update the `required` domain to include `l10n_gt_edi_is_root_company`.
This ensures the field is only mandatory in the root company where it
is actually visible and configurable and also set the `l10n_gt_edi_service_provider`
for branch company same as parent company.

**opw-5385819**

Forward-Port-Of: odoo/enterprise#106323

**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

Forward-Port-Of: odoo/enterprise#104162

Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made.

### **Steps to reproduce:**
1) Install `l10n_gt_edi` and switch to a GT company. 
2) Create a branch of the GT company.
3) In the parent company, go to Accounting Settings, set the Guatemala
   Localization to 'Demo', and save.
4) Switch to the branch company.
5) Open Accounting Settings and click Save.

### **Observed Behavior:**
An error occurs because `l10n_gt_edi_service_provider` is empty but required.

### **Root Cause:**
The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails.

[1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22

### **FIX:**
Update the `required` domain to include `l10n_gt_edi_is_root_company`.
This ensures the field is only mandatory in the root company where it
is actually visible and configurable and also set the `l10n_gt_edi_service_provider`
for branch company same as parent company.

**opw-5385819**

Forward-Port-Of: odoo/enterprise#106323

Purpose: Exogenous information is the set of data that individuals and
legal entities must periodically submit to the DIAN, with different deadlines
depending on the taxpayer's characteristics, regarding transactions with clients
or users of their products or services. DIAN requires exogenous information reports
to be delivered as an XML file. The goal is to generate the most important formats
(1001, 1003, 1005, 1007, 1008 and 1009) as a CSV, so the user can submit it to the
DIAN for the XML generation.

Key Aspects of the reports:
- Each report has a set amount of columns(including categories) that must be displayed
and the columns are position dependent.
- The rows of the report can be categorized accordingly
	- Header
	- AMLs grouped by partner that are not considered minor amounts
	- AMLs grouped in a minor amount row based on the report's minor amount rule
- The minor amount rules are dependent on the exogenous categories

Additional Changes:
Models:
- l10n_co.exogenous.category:
	- Displayed as columns on the report
	- Used as a basis for the minor amount rules in the report
		- sequence: the column position of the category on the report
		- report_type: the report the category is applicable to
		- name: name of the category displayed on the report
- l10n_co.exogenous.config:
	-Defines how each report is used per chart of account
		- report_type: determines which report the config is for
		- exogenous_category_id: the exogenous category used
		- value_to_report: the type of amount to aggregate for said category,
		such as credit, debit, balance
		- concept: the concept if required by the report
		- account_ids: a many2many relationship to chart of accounts the config is applicable to
Relations:
- account_account_exogenous_config:
	-the Many2many relation table between
		- account.account
		- l10n_co.exogenous.config
Currency:
- l10n_co.reports.uvt:
	- Used to compare amounts in minor amount rules
	- A tax value unit used by the Colombian government to standardize tax values
Wizard:
- l10n_co_reports.exogenous_report.wizard: Allows the user to generate the CSV based on the report

Function Workflow:
- Generate account moves using the accounts that are mapped to
exogenous configs
- Navigate to the General Ledger report
- Click on the action cog to dropdown the button, `Exogenous Report CSV`
- A wizard will pop-up to allow the user to select the type of exogenous
report they want to export
- A CSV file will be downloaded onto the user's machine so they can
import the file into the DIAN pre-validator tool

task-5061117

**Steps to reproduce:**
* In **Accounting**, create a new accounting report.
* Set **Root Report** to **Profit and Loss**.
* Add a report line with **Figure Type = Percentage**.
* set **Computation Engine = External Value** and **Formula = 0** on report line.
* Add a report column with **Figure Type = Monetary**.
* Create a menu item for the report.
* Open the report and click **Budget**.
* Create a new budget filter and click **Create**.

**Observed behavior:**
* The system crashes with `TypeError: 'NoneType' object is not subscriptable`.
* The error occurs while accessing budget column values.

**Cause:**
* Budget comparison logic assumes required budget columns always exist.
* When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway.

**Fix:**
* Add a safety check to skip budget comparison when required columns are missing.
* Prevents the crash and allows budget filters to be created safely.

opw-5357339

Forward-Port-Of: odoo/enterprise#104162

**Steps to reproduce:**
* Install the *repair* module.
* Create a *storable product* and set some **On Hand** quantity.
* Go to *Repairs* and create a new **Repair Order**.
  Keep the repair order in *draft* state (do not confirm).
* In the **Parts** tab, add the storable product with the operation type set
  to *Add*.
* Open the **Stock Forecasted** report for the added product.
  Note the quantity shown under *Outgoing Draft Transfer*.
* Delete the **Repair Order**.
* Open the **Stock Forecasted** report for the same product again.

**Observed behavior:**
* The quantity still appears in the **Stock Forecasted** report under
  *Outgoing Draft Transfer* even after the repair order is deleted.

**Cause:**
* Deleting a draft repair order triggers `_unlink_except_confirmed`.
* This method prevents related stock moves from changing their state to
cancel when the repair order is deleted.
* The *Outgoing Draft Transfer* value is calculated as the sum of quantities
of stock moves in draft state at draft state.
https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L49

https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/addons/stock/report/stock_forecasted.py#L90

* As a result, deleting a draft repair order leaves related stock moves in
draft state, causing them to appear under *Outgoing Draft Transfer*
https://github.com/odoo/odoo/blob/20d96c54b795b8d617776afe9877fb5c6632c666/addons/repair/models/repair.py#L332-L335

**Fix:**
* Ensure that related stock moves are properly cancelled when a draft repair
  order is deleted.

---

opw-5449323

Forward-Port-Of: odoo/odoo#241970

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

Forward-Port-Of: odoo/odoo#236276

**Steps to reproduce:**
- Install Accounting and l10n_de
- Switch to a German company (e.g. DE Company)
- In Accounting settings, activate Peppol

- Create an invoice:
  * Customer: [a German customer with VAT]
  * Invoice Lines: [a line with a tax]
- Confirm the invoice
- Send the invoice via PEPPOL

**Issue:**
A UserError is raised:
"You cannot remove parts of the audit trail.".

**Cause:**
The audit trail prevent modifying an attachment.
When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment.
During the process, "res_model" and "res_id" fields of the attachments are set to the message record.
Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error.
However, it fails because the value is still in cache.

**Solution:**
Invalidate these fields as it is done when sending the invoice without PEPPOL.
https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20

opw-5916696




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

Forward-Port-Of: odoo/odoo#247949

**Steps to reproduce:**
- Install Accounting and l10n_de
- Switch to a German company (e.g. DE Company)
- In Accounting settings, activate Peppol

- Create an invoice:
  * Customer: [a German customer with VAT]
  * Invoice Lines: [a line with a tax]
- Confirm the invoice
- Send the invoice via PEPPOL

**Issue:**
A UserError is raised:
"You cannot remove parts of the audit trail.".

**Cause:**
The audit trail prevent modifying an attachment.
When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment.
During the process, "res_model" and "res_id" fields of the attachments are set to the message record.
Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error.
However, it fails because the value is still in cache.

**Solution:**
Invalidate these fields as it is done when sending the invoice without PEPPOL.
https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20

opw-5916696




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