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

### Issue:
When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs.

### Steps to reproduce:
- Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step)
- Refuse all time off for "Anita Oliver" (to avoid side effect in next step)
- Create a user for the employee "Anita Oliver"
- Link the employee and the user
- Create 2 payslips
	- 1 for "Mitchell Admin"
	- 1 for "Anita Oliver"
- Compute sheet and confirm both payslips
- Run scheduled action: "Payroll: Generate pdfs"
- Nothing happens

### Cause:
The traceback is raised on the line `self._get_document_partner().id`
 because `_get_document_partner()` can return a recordset.

### Solution:
Call `ids` instead of `id`.

### Note:
Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`.

The final code works fine as `_check_create_documents()` is called agion individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86).

opw-5213979

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

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

Version
- 18.0

Steps to Reproduce:
Issue 1: Incorrect tooltip text
  1. Go to Products → Products in subscription app.
  2. Open a product page and select goods product type
  3. observe product_tooltip show incorrect wording:
       * "Based on order" showed end of the period.
       * "Based on delivered" showed beginning of the period.

Issue 2: Product card shows both recurring and sales price
  1. Go to Products → Products in subscription app.
  2. Observe that the product card displays both recurring price and sales price

After this PR:
- Tooltip now correctly states:
   * for "based on order" invoice_policy -> beginning of period
   * for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.

task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />

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

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

uprade pr: https://github.com/odoo/upgrade/pull/8648

**Steps to reproduce:**
1. Install `eCommerce` and `Rental` modules.
2. Create a rental product.
3. Create a new attribute with two values with extra price. Set display type to multi-checkbox.
4. Add attribute and its values to the product.
5. Activate rental for the product and configure rental pricing.
6. Open the product page on the eCommerce store.
7. Select values from both attributes including multi-checkbox options.

**Observed behavior:**
* Multi-checkbox attribute values can be selected, but their extra prices are ignored in the cart subtotal and product configurator price display.

**Root cause:**
* The rental pricing logic bypassed the standard price computation that includes extra prices from no_variant attributes. In `_get_pricelist_price()`, the rental price was computed using rental-specific rules without adding extra prices from `product_no_variant_attribute_value_ids`. Similarly, in the product configurator (`_get_combination_info_variant()`), price_extra from no_variant attributes was not added to the rental price. The template also hid extra price badges for rental products.

**Solution:**
1. In `sale_order_line._get_pricelist_price()`, add extra prices from no_variant attributes after computing the rental price.
2. In `product_template._get_combination_info_variant()`, add `price_extra` to `current_price` for rental products.
3. Remove the template override that hid extra price badges for rental products, allowing customers to see extra prices in the product configurator.

opw-4937869

On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task

Steps to reproduce:
-------------------
* Create a product
	- Purchase: False
	- Sale    : True
* Create a fsm task
* Add products
* Go to the sale order
* Create the invoice (regular invoice)
* Go back to the task
* Go to the invoice using the invoices smart button
* Try to add your product
-> issue it's not possible.

Observation:
---------------
The domain of the search is not the same if we go from the sale order or from the task.

This is because the domain depend on the context and the context is not the same :
[Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141)

When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice":
[SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453)

Instead when using it on the task, the context does not have that element:

https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327

This will be calculate here in the js files:

[evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400)

opw-5135567

Forward-Port-Of: odoo/enterprise#98612

Currently, an error occurs when a user applies a discount code to the cart.

Steps to reproduce:

 - Install the `website_sale_loyalty` module.
 - Go to `Discount & Loyalty` and create a new program with `Program Type = Discount Code`.
 - Under the `Rules & Rewards` tab, add a rule with a `code (e.g., demo)`.
 - `Archive` the program record.
 - Repeat `steps 2 and 3`.
 - `Unarchive` the first record.
 - Go to `Website` > `Shop`, add a product to the cart, and go to the cart page.
-  Apply the code `demo`.

`ValueError: Expected singleton: loyalty.program(2, 3)`

This error occurs when a user creates a sale loyalty program and adds a loyalty rule with a code, then archives that record. If the user creates the same record again and later unarchive the first record, there will be two rules with the same code, resulting in two loyalty programs [1], which raises the error [2].

This commit ensures that the system also checks archived records when unarchiving and verifies that there are no two or 
more programs with the same code being unarchived, so that no conflicting rules are activated.

[1]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1351

[2]- https://github.com/odoo/odoo/blob/76a8d6bc28eb5998bd976b3c41bf9772d325c8bf/addons/sale_loyalty/models/sale_order.py#L1371

sentry-6871330244

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

Issue
=====
When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work.

How to reproduce
================
1. Enable "Packages" and "Storage Locations" settings;
2. Create two packages with some content in WH/Stock/Shelf 1;
3. Create an empty package;
4. Create an internal transfer directly from the Barcode app;
5. Scan Shelf 1 barcode and scan first package;
6. Scan the empty package => It's assigned as the result package;
7. Confirm the operation;
8. Create another internal transfer;
9. Scan Shelf 1 barcode and scan second package;
10. Scan the no more empty package => This time, it's not assigned as the result package.

Reason
======
A package was assigned as the result package only if one of the following conditions is matched:
1. The scanned package is empty (it's what's happening in 6.);
2. The selected line has no result package yet and the scanned package is in the selected line's destination location.

Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.)

Fix
===
For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package.

[opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234)

Forward-Port-Of: odoo/enterprise#101357

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#238055

Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos.

Steps to reproduce:
-------------------
* Set max closing difference as 0
* Have 1 admin user and 1 pos user
* Have 2 employees
* Set admin user and employee 1 as advanced employees of the pos
* Set pos user and employee 2 as basic employees

Steps with admin:
* Make sure you are logged as the admin in the database
* Open pos (could be a session opened by other user)
* Log in with Admin user
* Try to close the pos with a difference of 10 -> You can, ok
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You ca but shouldn't

Steps with pos user
* Now log in the database as pos user
* Open pos (could be a session opened by other user
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You cannot, ok
* Log in with Admin user
* Try to close the pos with a difference of 10 -> you cannot but should

Why the fix:
------------
Employees that have no linked user should not ba able to override the max difference.

Employees who have a connected user should only be able to override the max difference if their user is admin of the pos.

opw-5184041