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

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

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