Currently, an incorrect shipping address is assigned to invoices generated from 
POS orders when the customer has multiple delivery addresses.

**Steps to reproduce:**

- Install the `point_of_sale` and `contacts` modules.
- Enable `Customer Addresses` from the settings.
- Create a contact with `two` delivery addresses.
- Open POS and create an order using the `second delivery address` as the customer.
- Confirm the order with the `invoice`.
- Observe the `shipping address` on the invoice.

**Observation:**
The invoice incorrectly shows the first delivery address instead of the 
second delivery address.

**Cause:**
At invoice creation in POS, only `partner_id` is set and `partner_shipping_id` 
is missing at [1]. As a result, the invoice defaults to the customer's first 
delivery address instead of the delivery address selected in POS.

**Fix:**
This commit adds `partner_shipping_id` to the invoice values to ensure the 
POS invoice uses the exact delivery address selected during order creation. 
same as the `sale` module behaviour.

[1]:
https://github.com/odoo/odoo/blob/1d1cd8648ed1c3f13febbde8d48e28928e18583f/addons/point_of_sale/models/pos_order.py#L667-L684

opw-5350137

Forward-Port-Of: odoo/odoo#239663
Forward-Port-Of: odoo/odoo#238055

**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor.

**Steps to produce:**

- Install the `web_studio` module and enable `developer mode`
- Open `Apps` > `studio` > `view` > `</> xml`
- Declare encoding as: `<?xml version='1.0' encoding='utf-8'?>` and click `save`

**Error:**
`ValueError: Unicode strings with encoding declaration are not supported. 
Please use bytes input or XML fragments without declaration.`

**Root cause:**
At [1], an error is raised when the XML declaration contains an `encoding`
attribute, as encoding declarations are invalid in Unicode strings.

**Fix:**
This commit ensures that a `UserError` is raised, improving the error message clarity.

A similar fix was applied in https://github.com/odoo/odoo/pull/205324.

[1]:
https://github.com/odoo/odoo/blob/8a22b6ca09e1da3ccba3540bc4851a5174e035cc/odoo/tools/translate.py#L316

sentry-6981234548

Forward-Port-Of: odoo/odoo#239630
Forward-Port-Of: odoo/odoo#233571

Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered.

Steps to replicate:
- Install `sale_management` with demo and create a new SO.
- Add a combo product and remove the combo name and click Edit Configuration (pencil icon).

Error:
`TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'`

Cause:
- When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered.

Solution:
- Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present.

Similar PR for reference: https://github.com/odoo/odoo/pull/217464

[1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14

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

Forward-Port-Of: odoo/odoo#238536

When registering to an event, customers are asked questions before reaching the payment page. By default, a *Name* question is included, but it can be removed by the organizer of the event. If the *Name* question is removed, but a name is asked in the delivery form, Odoo will try to compare the (missing) name from the event's questions with the (required) name from the delivery form.

https://github.com/odoo/odoo/blob/828a9504c7d43aa35ed91141268d04e0a55782c3/addons/portal/controllers/portal.py#L551

The issue is that if there's no *Name* question among the event's questions, a `res.partner` with its `name` field set to `False` is created. When attempting to call `.strip()` on its name, an `AttributeError` is raised (*'bool' object has no attribut 'strip'*).

This fix prevents the error by considering the name field as an empty string in case no name is provided.

### Steps to reproduce:
1. Install *Online Event Ticketing* (`website_event_sale`)
2. In Settings > Website, set *Sign in/up at checkout* to *Disabled (buy as guest)*
3. In Events, create a new Event
    - Give it any name
    - Add a product line for the Event Registration with a price greater than 0
    - In the *Questions* tab, remove the *Name* question
    - Click the *Go to website* smart button and publish the event
4. On the website, in incognito mode:
    - Click *Events*
    - Click the new event we created in Step 3
    - Click *Register*, (set the quantity to one ticket,) click *register*
    - Answer the questions (there should **not** be a *Name* question) and click *Confirm Registration*
    - Fill out the required fields of the delivery form (there **should** be a *Name* field)
    - Open the console, then click *Confirm* in the delivery form: An error appears, and the Payment page does not appear

opw-5259781

Forward-Port-Of: odoo/odoo#237154

### Issue:
In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file.

### Steps to reproduce:
- Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company
- Make sure the company has a "Partena Affiliation Number"
- Create an employee for this company, with a "Partena code"
- Create a contract for this employee, set it a running
- Create a new Belgian company with a different "Partena Affiliation Number"
- Activate both Belgian companies, but set the second one as active
- Payroll > Reporting > Export work entries to Partena
- Create a new one, populate it with the employee just created
- Click "Generate Export File"

### Cause:
When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values.

### Solution:
Use `self.company_id` instead of `self.env.company_id`.

Also adds the test class with basic tests.

opw-5345786

Forward-Port-Of: odoo/enterprise#101110

This fix addresses an issue where selling multiple gift cards in a single POS order results in only one gift card being created with the total amount, instead of multiple gift cards with the correct individual amounts.

Step to reproduce:
- Create a new gift card and enable the option to sell this card in the POS
- Open the POS and try to sell multiple gift cards in the same order
- Validate the order
- Check the generated gift cards, only one gift card will be created with the total amount instead of multiple gift cards with the correct individual amounts

This issue occurs because the field `reward_point_split` is missing from the kanban view of loyalty rules. So, when creating a new gift card, this field value, which should be True for gift cards, is not returned by the onchange method, and since nothing triggers a new computation unless the program type is changed, the field remains False.

This fix simply restores this field in the kanban view (like before https://github.com/odoo/odoo/pull/172561) so that its value is correctly taken into account when creating a new gift card.

opw-5103652

Forward-Port-Of: odoo/odoo#238993

Steps to reproduce:
1. Install `loyalty` and `sale_management`
2. Activate another language with another date format, eg. English (AU)
3. Set that language on a contact
4. Sales > Product > Discount & loyalty
5. Create a record with program type coupons
6. Generate a coupon for that AU contact with an expiration date

Issue:
The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format.

Cause:
We are not using a formatted date according to the customer

before: Customer with English AU language
<img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" />

<img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" />


After:
<img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" />

<img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" />


opw-5247621

Forward-Port-Of: odoo/odoo#237880

Currently a user that connected to a pos user cannot go backend if he was not the person who opened the session the first time.

Steps to reproduce:
-------------------
* Modify settings of the shop to use employee feature
* Make sure admin and demo can access the shop, set them advenced employee for example.
* Logged as Mitchell Admin, open the pos (It should have been closed before)
* Use Mitchel admin employee
* Complete cash control
* Go backend
* Log out
* Log back in with Marc Demo
* Enter the shop (it was already "opened" by Admin)
* Use Marc demo employee
* Now try to see the backend button
> Observation: Backend button is not available

Why the fix:
------------
Quoting this commit: https://github.com/odoo/odoo/commit/61df2871e1aac0144d26022a2a49c75ea9ecad4a
> Now, the only employees that can go back to the backend are those binded to the user connected.

However, `this.pos.session.user_id` only reflects the user who opened the pos the first time, in our case Mitchell Admin. It does not represent the connected user.

opw-5276950

Forward-Port-Of: odoo/odoo#239627
Forward-Port-Of: odoo/odoo#238636

**[IMP] account: Add new tax helpers for EDI** (backport)

task_id: 5096249

**[FIX] account_edi_ubl_cii: Fix management of fixed taxes** (backport)

This commit contains 2 things:
- an helper to extract any tax_data and move it to another base_line
- the usage of this helper in UBL to turn emptying taxes into additional base_lines

== Add helpers to turn tax_data into new base_lines easily ==

With this helper, you can now exclude any tax from any base line and turn
them into new base lines.

Also, I changed a bit the smooth distribution of rounding because the math.ceil
is sometimes too greedy and make the whole results to be less accurate.

== Make a different behavior between recycling contribution taxes / emptying taxes ==

In UBL, all fixed taxes are treated as allowances/charges.
In this commit, we make a clear distinction between recycling contribution taxes
that are treated as allowances/charges and emptying taxes that are exempted of tax
and are treated as addition invoice lines in the document.

== Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function ==

The aggregator wasn't called when setting the 'target_base_line' at the very first time.

task_id: 5182783

**[FIX] account_edi_ubl_cii: Reword export BIS3**

- Separate the BIS3 from the annoying dependency between all the UBL files.

You are not supposed to generate an UBL 2.0 & 2.1 UBL files. Those are templates
with all the options you have to build your format on top of it. However, since
we used them as a hierarchy and since most of the code and implementation are
inside UBL 2.0, "fixing" any use case for one single implementation has impacts in
all others.
In order to fix issues about ways amounts are computed in BIS3, we first split BIS3
to be independant from UBL 2.0 / UBL 2.1 but using new generic helpers that could be
used for any single format.
The future goal will be to make all formats independant but that part is already big
enough and we are in a hurry. "To be continued in a next PR"

- Reword the test suite for exported files to be more explicit about which test is testing what exactly.

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

Forward-Port-Of: odoo/odoo#239580
Forward-Port-Of: odoo/odoo#238560

…f related line is complete

### Steps to reproduce:

- In the settings enable Lots & Serials and Batch transfers
- On the delivery operation types enable show reserved lots in the barcode tab
- Create a storable product tracked by lots and put 10 x lot1 in stock
- Create and confirm a delivery for 10 units
- Create a batch transfer with your delivery
- Process your transfer from the barcode app
- Scan one unit of LOT1 and put in pack
- Toggle sublines select the 0/9 subline without lots nor package
- Scan LOT1
#### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9

### Cause of the issue:

Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot.

opw-5340865

Forward-Port-Of: odoo/enterprise#101817
Forward-Port-Of: odoo/enterprise#101611

**Steps to reproduce:**
- (Firefox only)
- Go to any record which uses a chatter (e.g. Contact)
- Send message > Full composer > click the schedule message icon (lower right corner)
- Schedule the message in the future and click send
- You should see now a post in the chatter indicating that the message will be sent
- Now click Send message and repeat the above steps again to schedule a second message
- Whole page will be freezed
- Reloading doesn't help

**Issue:**
Infinite loop in reactive callback on firefox.
The code gets stuck in
```js
for (const callback of [...callbacks]) {
    clearReactivesForCallback(callback);
    callback();
}
```
because of
```js
const sortProxy2 = reactive(recordProxy, function sortObserver() {
    self.requestSort(record, fieldName);
});
this.fieldsSortProxy2.set(fieldName, sortProxy2);
```
which loops over `store._.ADD_QUEUE("sort", record, fieldName);`

(Forcing the `requestSort` only change the infinite loop into a recursion error)

The recomputation seems to be caused by a bad sorting here:
```js
this.scheduledMessages = Record.many("ScheduledMessage", {
    sort: (a, b) => {
        if (a.scheduled_date === b.scheduled_date) {
            return a.id - b.id;
        }
        return a.scheduled_date < b.scheduled_date ? -1 : 1;
    },
```
In the case both datetimes are equal the first condition doesn't properly catches it:
```
> a.scheduled_date - b.scheduled_date
> 0
> a.scheduled_date === b.scheduled_date
> false
> a.scheduled_date < b.scheduled_date
> false
> a.scheduled_date > b.scheduled_date
> false
```
Which make the ordering change on each sort iteration:
```
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,13", "ScheduledMessage,14" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
```
Chromium based browsers probably use a different sorting algorithm than Firefox, which seems to prevent the issue.

**Fix:**
Use `compareDatetime` to ensure the ordering is constant for the same datetime values.

opw-5367371

Forward-Port-Of: odoo/odoo#239624
Forward-Port-Of: odoo/odoo#239199

**Steps To Reproduce:-**

1. Install point_of_sale in 17.0
2. Activate flexible taxes setting
3. set default fiscal position  and after that archived that fiscal position.
4. try edit and save the POS config any operation below mentioned recursion error will come.

**Issue :-**

Due to archived record of fiscal postion is keep updating due to not satisfying this condition [config.default_fiscal_position_id.id not in config.fiscal_position_ids.ids](https://github.com/odoo/odoo/blob/62652ba3a7a90699e7aa8ff98e2d4980f1b43694/addons/point_of_sale/models/pos_config.py#L529) here ``config.fiscal_position_ids`` on this active filter is applying and it coming empty and going to update many2many field this process goes infinite due to archive fiscal position record

**FIX:-**
       adding the check of active record fiscal position

```
 File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
    self.sudo()._set_fiscal_position()
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
    self.sudo()._set_fiscal_position()
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
    self.sudo()._set_fiscal_position()
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 418, in write
    result = super(PosConfig, self).write(vals)
  File "/data/build/odoo/odoo/models.py", line 3820, in write
    field.write(self, value)
  File "/data/build/odoo/odoo/fields.py", line 4287, in write
    return self.write_batch([(records, value)])
  File "/data/build/odoo/odoo/fields.py", line 4308, in write_batch
    return self.write_real(records_commands_list, create)
  File "/data/build/odoo/odoo/fields.py", line 4835, in write_real
    old_relation = {record.id: set(record[self.name]._ids) for record in records}
  File "/data/build/odoo/odoo/fields.py", line 4835, in <dictcomp>
    old_relation = {record.id: set(record[self.name]._ids) for record in records}
  File "/data/build/odoo/odoo/models.py", line 6007, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/data/build/odoo/odoo/fields.py", line 2824, in __get__
    return super().__get__(records, owner)
  File "/data/build/odoo/odoo/fields.py", line 1270, in __get__
    return self.convert_to_record(value, record)
  File "/data/build/odoo/odoo/fields.py", line 4199, in convert_to_record
    corecords = corecords.filtered(Comodel._active_name).with_prefetch(prefetch_ids)
  File "/data/build/odoo/odoo/models.py", line 5496, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/data/build/odoo/odoo/models.py", line 5496, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/data/build/odoo/odoo/models.py", line 5493, in <lambda>
    func = lambda rec: any(rec.mapped(name))
  File "/data/build/odoo/odoo/models.py", line 5470, in mapped
    recs = recs._fields[name].mapped(recs)
  File "/data/build/odoo/odoo/fields.py", line 1299, in mapped
    return self.convert_to_record_multi(vals, records)
  File "/data/build/odoo/odoo/fields.py", line 942, in convert_to_record_multi
    return [convert(value, record) for value, record in zip(values, records)]
  File "/data/build/odoo/odoo/fields.py", line 942, in <listcomp>
    return [convert(value, record) for value, record in zip(values, records)]
  File "/data/build/odoo/odoo/models.py", line 5844, in __iter__
    yield self.__class__(self.env, (id_,), self._prefetch_ids)
RecursionError: maximum recursion depth exceeded
```

**OPW** - 5208462
**UPG** - 3248441


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

Forward-Port-Of: odoo/odoo#239727
Forward-Port-Of: odoo/odoo#233358