Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure

According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:
CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value)
CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE

Steps to reproduce:

Install l10n_ec_edi module
Go to Settings > Invoicing > Ecuadorian Localization
In Electronic Invoicing > Regime, select rimpe_emprendedor
In Electronic Invoicing > Regime, configure a SRI Connection
Post an customer invoice

**Validation error occurring during the electronic signing process (using .p12 certificates):**
`35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR `

Forward-Port-Of: odoo/enterprise#109147

There is an inaccuracy in the steps of the tour:
- test_basic_sale_flow_with_minimal_access_rights Indeed, in this test a new line is added on the order and a product is selected but the next step confirms the order without waiting for all the associated onchanges to be taken into accounts: https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale_management/static/tests/tours/sale_flow_tour.js#L14-L20 https://github.com/odoo/odoo/blob/b5511e5ebb919c2c506131bf9e2a4196dac25f79/addons/sale/static/src/js/tours/tour_utils.js#L27-L47

In the case where the confirmation happends before the product edition is taken into account, the order fails to confirm and stays in draft which makes the rest of the tour fails.

Note:

The same issue could happen at some point on the equivalent purchase test, so that we also modify the test:
- test_basic_purchase_flow_with_minimal_access_rights

runbot-241198

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

Forward-Port-Of: odoo/odoo#252154

Issue:
---
Due to this issue, generating PDF Quote using Quote Builder leads to traceback.

Steps to reproduce:
---
1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0)
2- Enable Quote Builder.
3- Create a SO and in quite builder tab, select a document.
4- Print -> PDF Quote.

This will lead to traceback.

Cause:
---
There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be
supported in future. Instead we use pypdf==5.4.0.

In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0):
https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061

FIX:
---
We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`:
https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370

Note:
---
In this fix, we replace `is_upper_version_pypdf2` with specific version comparison.
To be precise `getNumPages` is depreciated in version 1.28.0 [2].

References:
---
[1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0
[2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514

opw-5784464

Forward-Port-Of: odoo/odoo#250329

### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.

### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style

### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.

### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.

### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout: 
```
<small t-if="combination_info.get('base_unit_price')"
    class="ms-1 text-muted o_base_unit_price_wrapper d-none">
    <t t-call="website_sale.base_unit_price">
        <t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
    </t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />

After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />

opw-5920598


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

Forward-Port-Of: odoo/odoo#250319

**Steps to reproduce:
1. Create DE company (EUR currency)
2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month)
3. Install l10n_de_reports
4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank]
5. Create USD invoice for XX/02/26 and confirm it
6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment)
7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data

**Description of issue:
The currency exchange rate difference entries in the exported file are shown as 0

**Expected behavior:
The actual currency exchange difference values should be displayed

**Why this happens?
The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export.

**The fix:
Updated the logic to use the line balance when the entry is identified as a currency exchange difference.

opw-5358954

Forward-Port-Of: odoo/enterprise#109655
Forward-Port-Of: odoo/enterprise#107268

Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error

The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.

This commit improves error handling for both public and internal AI chat
by:

- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.

The following behavior will now be observed during error in the UI.

- Public AI chat:
  - Initial fetch failed: shows "oops" message
  - Stream interrupted:
    - Server handled: shows "oops" message
    - Server stopped: shows "Connection Interrupted" dialog

- Internal AI chat:
  - Initial fetch failed: show RPCError dialog
  - Stream interrupted:
    - Server handled: shows RPCError dialog
    - Server stopped: shows "Connection Interrupted" dialog

We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.

TASK-ID: 5886825

# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt

# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.

# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12

# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />

There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
    get phoneText() {
        return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
    }
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />

**Drawback:**
- The inconsistency between how the number is stored and how we view it.

# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+    get direction() {
+        return localization.direction;
+    }
```

**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
                <t t-if="props.data.company.phone">
-                    <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                    <t t-if="direction == 'ltr'">
+                        <div>Tel:<t t-esc="props.data.company.phone" /></div>
+                   </t>
+                    <t t-elif="direction == 'rtl'">
+                       <div><t t-esc="props.data.company.phone" />Tel:</div>
                    </t>
                </t>
```

**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability


opw-5881503

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

Forward-Port-Of: odoo/odoo#252348
Forward-Port-Of: odoo/odoo#249060

**Issue**
Computing the price from BOM can be incorrect when the BOM is defined on a multi-variant product.

**Steps to reproduce**
- Create a product with several variants
- Create a BOM for that product without specifying the product variant
- Define an operation restricted to a specific variant V
- Associate the operation with a workcenter with:
    - Non-null cost per hour (e.g. 100)
    - Time efficiency lower than 100% (e.g. 50%)
- Go to the product page > Variants > variant V
- Click on "Compute price from BOM"
-> The result will be 100 instead of 200 in this example.

Please notice that the price is correctly computed in the BOM overview

**Cause**
Accessing the BOM triggers a `web_read` including `operation_ids`,
which requires computing `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L77

During this computation, the associated product is retrieved:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L106

But since no product is given in the context and the BOM has been created without specifying the product variant
(`bom_id.product_id` is empty), then it retrieves all the product variant associated to the BOM, which leads to
arbitrary default value that ignores work center efficiency:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L107-L111
While clicking on "Compute price from BOM":
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L33
it will ultimately needs to compute the cost:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp_account/models/product.py#L74
which relies on `time_total`:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/models/mrp_routing.py#L131
and since no context is provided, `time_total` is already in the cache, so the default value is used.
Please notice that in BOM overview, the problem does not occur because the provided context retriggers the compute method:
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L806
https://github.com/odoo/odoo/blob/233316f322d891ebaadb51412ea0df039bfd312a/addons/mrp/report/mrp_report_bom_structure.py#L835

opw-5909570

Forward-Port-Of: odoo/odoo#248758

## Issue
When setting up a product with both the MTO and the *Dropship* routes, the *Purchase Order* genereated when confirming a *Sales Order* does not contain a *Dropship Address* (`purchase.order.dest_address_id`). It is problematic because that field is both readonly and required to confirm the order.

## Steps to reproduce
1. Install *Stock* (`stock`), *Purchase* (`purchase`) and *Sales* (`sale_management`)
2. In Settings, enable *Dropshipping* and *Replenish on Order (MTO)*
3. Create a Product P
    - Set a vendor in the Purchase tab
    - Enable the *Buy*, *Dropship* and *Replenish on Order (MTO)* routes
4. Create a Sales Order
    - Any Customer
    - Product P
    - Confirm the Sales Order
5. Click on the *Purchase* smart button
6. Set the *Delivery To* (`purchase.order.picking_type_id`) field to *"Dropship"*
7. **The _Dropship Address_ (`purchase.order.dest_address_id`) field appears, but it's empty and readonly. The purchase order cannot be confirmed, as the field is required and cannot be updated.**

## Cause
When confirming a Sales Order, the created Purchase Order has a `dest_addres_id` set by `StockRule._prepare_purchase_order`:

https://github.com/odoo/odoo/blob/19.0/addons/purchase_stock/models/stock_rule.py#L350

At that point, the `picking_type_id` of the PO is set to `"Receipts"`, which `default_location_dest_id` is the user's Stock, and the `usage` of that location is set to `"internal"`. When `_compute_dest_address_id` is triggered, it starts by calling the method in `sale_purchase`:

https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/sale_purchase/models/purchase_order.py#L25-L30

Which calls the one in `purchase_stock`:

https://github.com/odoo/odoo/blob/9d96a8a4ae23bd331296ee0fd628c2be3de4bfe3/addons/purchase_stock/models/purchase_order.py#L80-L82

Which sets the `dest_address_id` to `False`. This impacts the rest of first `_compute_dest_address_id`, as the PO does not have a `dest_address_id` anymore, its value will never be updated by the `_compute_dest_address_id` methods.

## Fix
The `dest_address_id` should only be set when dropshipping. The easiest way to do so is to override the `_compute_dest_address_id` in the `stock_dropshipping` module by following a similar logic as in `sale_purchase`:

https://github.com/odoo/odoo/blob/7a39185f83d0daca207c8007512f4700537c7e88/addons/sale_purchase/models/purchase_order.py#L25-L30

opw-5426322

Forward-Port-Of: odoo/odoo#245284

Currently, an error occurs when a user tries to generate lots while providing a lot number.

**Steps to replicate:**
- Install purchase (without demo).
- Create a product `test`.
- Install stock and turn on `Lots and Serial Numbers`
- Open the product `test` and turn on `Track Inventory` `by Lots`.
- Open Receipts > add the product `test`> give demand as 3 > and go to its form view using view button.
- Click `Generate Lots` > type `lot1` in `First lot Number` > Generate > Error-1
- Click `Generate Lots` > type 0 in Quantity received > Generate > Error-2.

**Error-1:**
```
  File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1026, in action_generate_lot_line_vals
    if (first_lot and first_lot == product.lot_sequence_id.get_next_char(first_number)):
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 237, in get_next_char
    interpolated_prefix, interpolated_suffix = self._get_prefix_suffix()
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/addons/base/models/ir_sequence.py', line 227, in _get_prefix_suffix
    self.ensure_one()
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5640, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: ir.sequence()
```

**Error-2:**
```
  File '/home/odoo/odoo18/community/addons/stock/models/stock_move.py', line 1025, in action_generate_lot_line_vals
    first_number = product.lot_sequence_id.number_next_actual - product.lot_sequence_id.number_increment
                   ^^^^^^^
UnboundLocalError: cannot access local variable 'product' where it is not associated with a value
```
---
**Cause:**
- Both errors originated through a recent [PR].

**Error-1 (Expected singleton: ir.sequence()):**
- As the product was already created before Inventory was installed, the `lot_sequence_id` was empty. (Note:`lot_sequence_id` field has a default value , but default value
       assignment triggers only during the record creation,  any records created
       before stock is installed will not be assigned any value for
      `lot_sequence_id`.)

- As no `lot_sequence_id` is assigned to `test` product the line [1] calls `get_next_char()` on an empty recordset which further calls `_get_prefix_suffix()` [2] and raises singletonerror from [here].

**Error-2 (UnboundLocalError: cannot access local variable 'product'):**
- As the `Received Quantity` was given 0, the `count` argument is received as 0 and as a result the `lot_qties` [3] and `lot_names` [4] are received as empty lists.
- This causes their [zip] to be empty list too and the loop never runs, so assignment to [product] variable never happens and causes the error to occur from here [5].
---
**Solution:**

**Error-1:**
- Now we perform write on `product.lot_sequence_id` only if it exists, otherwise we skip it.

**Error-2:**
- Moved the static assignment of variable `product` and `location_dest_id` outside the loop, this will also prevent the browse being called multiple times for browsing the same record.

[PR]: https://github.com/odoo/odoo/pull/240368

[1]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1026

[2]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L237

[here]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/odoo/addons/base/models/ir_sequence.py#L227

[3]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L989

[4]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L994

[zip]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1000

[product]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1004

[5]: https://github.com/odoo/odoo/blob/7ab52c1675b9764d11454c7b5216064bec4628f8/addons/stock/models/stock_move.py#L1025

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

Forward-Port-Of: odoo/odoo#248846