[ADD] l10n_tr_nilvera_einvoice_extended: Adding Nilvera E-Invoice Extension  
[ADD] l10n_tr_nilvera_einvoice_extended: Adding Tax Offices

---

### Description of the issue/feature this PR addresses:

We do not support Withholding VAT (KDV Tevkifatı), Exemption Invoices, and Export Invoices (İhracat Faturaları) with our current e-invoicing solution in Türkiye. Those invoice types are legally important and required for both domestic and international sales for businesses. In addition, the inclusion of the Tax office in our current XML we send to Nilvera, both for `<cac:AccountingSupplierParty>` and `<cac:AccountingCustomerParty>`, is required by law.

This PR adds an extension module for Nilvera E-Invoicing. The purpose of this module is to extend the existing E-Invoicing functionality to support additional invoice types and scenarios to be compliant with the TR legal requirements.

---

### Invoice Scenario:

**Basic**  
Invoice Type:
- Sales  
- Withholding  
- Tax Exempt  
- Registered for Export  

**Export**  
Invoice Type:
- Tax Exempt  

**Public**  
Invoice Type:
- Sales  
- Withholding  
- Tax Exempt  
- Registered for Export  

---

### Current behavior before PR:

We don't support a scenario-based system to comply with TR legal requirements.

---

### Desired behavior after PR is merged:

We support a scenario-based system to comply with TR legal requirements.

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

Forward-Port-Of: odoo/odoo#229205
Forward-Port-Of: odoo/odoo#213766

After this commit:
https://github.com/odoo/odoo/commit/6247dc36f703ee2ec45913802ad175cb79873845 and this one:
https://github.com/odoo-dev/odoo/commit/5686072b8e7b827269573e8ab1f5b84b61b9315c

when we set default Structure to employee admin
but Later when clients set up their work flow
they set up their own admin employee.
This record is not present, so when employee admin record is not there , no need to set default structure too so need to set no forcecreate  on that employee admin too.

When we try to set default structure and if admin record does not exit,
we got error when we try to create employee as no name found and we try to pop name from val here :

https://github.com/odoo/odoo/blob/7e0cc5ec686a52b8c1f8270213acac54575ed469/addons/hr/models/hr_employee.py#L1275

Generated during upgrade

```
 File "/home/odoo/src/odoo/19.0/addons/resource/models/resource_mixin.py", line 37, in create
    self._prepare_resource_values(
  File "/home/odoo/src/odoo/19.0/addons/hr/models/hr_employee.py", line 1275, in _prepare_resource_values
    vals.pop('name')  # Already considered by super call but no popped
KeyError: 'name'
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

Forward-Port-Of: odoo/enterprise#95982
Forward-Port-Of: odoo/enterprise#94438

When archiving an employee with a Detailed Reason, a traceback occurs.

Steps to reproduce the error:
- Open any employee record > Archive
- Set ``Detailed Reason`` > Apply

Traceback:
```py
NotImplementedError: Unsupported tracking on field departure_description (type html
```

https://github.com/odoo/odoo/blob/8002b82d5783744b88b75c1199c4c1f222a0f7d0/addons/hr/models/hr_version.py#L130
here, ``tracking=True`` was added for the ``departure_description`` html field by the commit [1].
but tracking is not supported for the html field.
So, it will lead to the above traceback.

Tracking for ``departure_description`` field is already handled via a chatter message in the write method by the commit [2]. https://github.com/odoo/odoo/blob/8002b82d5783744b88b75c1199c4c1f222a0f7d0/addons/hr/models/hr_employee.py#L1187-L1191

[1]: https://github.com/odoo/odoo/commit/aa4d13b89b4497d2e5b33faa49ad86e0788782a2

[2]: https://github.com/odoo/odoo/commit/9b723e2591224f2b563924d3b3dfe27ab909b7d0

sentry-6973440621

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

Purpose:
--------
When chatting with an agent one can now upload files (or attach documents
if documents is installed) that will be processed by the LLM to generate
the answers

Technical Changes:
------------------
To support this feature, files needs to be inside their related messages.
Previously they were simply appended to the list of inputs that were sent
to the LLMs, but that does not work inside a chatter because one sends the
history of messages. So if a user uploads a file in its first message, then
another one in the second message, one can't append them both to the list
of inputs otherwise the LLM would consider the first one as a new upload,
instead of an attachment from the previous message.

The `request_llm` method of the llm api service has been refactored to be
able to achieve this, and simplify the addition of attachment in any
message.
Instead of having 3 parameters "user_prompts", "inputs" and "files", there
is now only one parameter "messages".
Messages should always be either a string (considered as user prompt),
either a dict containing the role and the message parts:
```py
{'role': 'user', 'parts': [
    {'type': 'text', 'content': 'hello'},,
    {'type': 'image/png', 'content': 'aW1hZ2UgY29udGVudA=='},
    {'type': 'application/pdf', 'content': 'cGRmIGNvbnRlbnQ='},
]}
```
These messages will be converted to the format expected by the different
providers before the loop calling the llm so that the llm answers can be
appended to this message list.
The tools are now also converted before the loop (there is no real need
to convert them in every loop iteration.

Task-5031785

[IMP] account_accountant: css backport

To have a consistent css across all version of the new bank rec widget, we
decided to backport few changes.

backport of:
https://github.com/odoo/enterprise/commit/524a7a46a0c2888b591de7ad1a0a6d744e345f5a
https://github.com/odoo/enterprise/commit/2a83c85cb2c9a7a5da3d4a8483120eeda6b2e6cb
https://github.com/odoo/enterprise/commit/e3cb3ab3ec8c64297d8e97d941e0d2eea3e64667
https://github.com/odoo/enterprise/commit/fdbb93abbf831cfa2fdc75e79aa76c094d6e522a
https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e

[FIX] account_accountant: restrict some account in the set_account

Before this commit, we could select the liquidity account or bank suspense
account which could create a reco model for it that would do nothing.

[FIX] account_accountant: partner_name

Before this commit, when a transaction had no partner_name and some lines with
the same partner. When unfolded, we had the info of the partner on the statement
line and on the line itself which was a duplicate of information.

This commit will change when the line is unfolded so that the partner is visible
on the statement line only when there is a partner_name

[FIX] account_accountant: payable and receivable button

Before this commit, the payable and receivable buttons where on the top line
only when the reconcile button was not there anymore. Now We decided to always
have them present in secondary next to the reconcile button.

no task-id

Forward-Port-Of: odoo/enterprise#98458
Forward-Port-Of: odoo/enterprise#96852

The commit:
1. use static property to configure a builder option
2. introduce the concept of dependencies to access the plugin's shared
   in builder option
3. make a plugin context the same for Plugin, BuilderOption and
   BuilderAction to have the same API in each class.

Before this commit, to define an option, we had to define a javascript
object that would contain the information of the option within the
`builder_options` resource.

```js
class MyPlugin extends Plugin {
    resources: {
        builder_options: [
        {
            selector: "div.selector",
            template: "my.owlTemplate",
            cleanForSave() {}
            // ... other option props
        }
        ]
    }
}

// For a custom component
class MyPlugin extends Plugin {
    resources: {
        builder_options: [
        {
            selector: "div.selector",
            template: MyCustomComponent,
            cleanForSave() {}
            // ... other option props
        }
        ]
    }
}

class MyCustomComponent extends BaseOptionComponent {
    // ...
}
```

When building anything for the builder, there is 3 classes that are
important: `Plugin`, `BaseOptionComponent`, `BuilderAction`.

In practice, the option object defined in builder_options feels
strange. On the other hand, making the configuration of the option as
a static property of the component somehow feels simpler as everything
related to that option is defined in the same class.

```js
class MyPlugin extends Plugin {
  resources: {
    builder_options: [MyCustomComponent]
  }
}

class MyCustomComponent extends BaseOptionComponent {
  static template = "my.owlTemplate";
  static selector = "div.selector";
  static cleanForSave(context) {}
  // ...
}
```

To have the same mental context in the 3 important class, they all
share the same API (`dependencies`, `dispatchTo`, `getResource`, ...)
(see `Editor.getPluginContext`)

To access a plugin shared method, it's now the same for `Plugin`,
`BuliderAction` and `BaseOptionComponent`:

```js
class MyCustomComponent extends BaseOptionComponent {
    static selector = "mySelector";
    static dependency = "myPlugin";
    myMethod() {
        this.dependencies.myPlugin.pluginMethod();
    }
}
```

To access a resource, dispatch, ...:

```js
class MyCustomComponent extends BaseOptionComponent {
    static selector = "mySelector";
    myMethod() {
        const resource = this.getResource('myResource');
    }
}
```

Forward-Port-Of: odoo/enterprise#96515
Forward-Port-Of: odoo/enterprise#94102

Description
-----------
The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads to a bad plan where Postgres does a full Seq.Scan on `voip_call` to then post-filter based on `user_id`.

To simplify the final query, we inline the ids that are being resolved from searching on `res.users.employee_id` (which is just a proxy for `res.users.employee_ids`). We also re-write the `ir.rule` to use this new inlining via `employee_id` and avoid using `employee_ids` which is resolved as a generic One2many from the ORM.

This leads to a few more queries, but each is fast and trivial to process.

Benchmark
---------
On a database with over 10M `voip.call` and `res.users`, for a Hr Officer, to open the Phone's app default list view with no default filter (the default setup), took:

| Before | After | Speed-up |
|--------|-------|----------|
| 13.3s  | 80ms  | 162x     |

Forward-Port-Of: odoo/enterprise#98098

#### Issue:

In this bug, workorder duration inverse is causing some time_ids to be deleted.

To reproduce:
1- Create a db with mrp installed, and enable work orders in Setting
2- Create a MO, and confirm it
3- Add a new work order to the MO
4- Add two time tracking lines:
   - First one 10:00 -> 12:00
   - Second one 10:00 -> 11:00

5- As you see, duration reflects duration of first line as it is the interval duration
6- Save and close work center form. Then save MO form.
7- Open work orders again: As you see second line is unlinked

#### Cause:

The reason to this bug, is because in Enterprise, the `_compute_duration` override changes the logic of how duration is computed but the inverse function doesn't reflect the same logic.

To be specific this is the compute function override: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L757-L766

In which duration is calculated using get_duration: https://github.com/odoo/enterprise/blob/3cbe2bbbfd989a3daaa32769a843aeaa09c7ed3e/mrp_workorder/models/mrp_workorder.py#L828-L837

Which doesn't sum the durations, but calculates the intervals duration counting overlaps only once.

However, there is no override of inverse method in Enterprise, meaning that the logic behind inverse will not match with this logic. In the inverse it is assumed duration is sum of all time_ids intervals: https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L355-L400

As a result, if time_ids overlap:
new_order_duration < old_order_duration

As a result some time_ids will be unlinked and some will have duration changed.

#### Fix:

Inside the inverse function in Community we can do:
```diff
+ old_order_duration = order.get_duration()
- sum(order.time_ids.mapped('duration'))
```

As get_duration in Odoo Community is:
https://github.com/odoo/odoo/blob/9b286285a6c66bc2d629eacf651c3439cffb55cc/addons/mrp/models/mrp_workorder.py#L889-L899

The order.get_duration will be sum of duration of all time_ids in community, hence the logic will be unchanged.

In Enterprise, this is going to reflect the logic implemented in override of get_duration, as a result the duration logic will be consistent in compute and inverse function.

However, this might cause another issue:
If `order.duration` is not computed yet, and inverse method `_set_duration` is called, then `get_duration` inside `_set_duration` will be called before the `get_duration` in compute method. As a result there might be a small unexpected time difference between `old_order_duration` and `new_order_diuration`. To avoid that inside `get_working_duration` we can use cursor now instead:
```diff
+ now = self.env.cr.now()
- now = datetime.now()
```

opw-5082477

Forward-Port-Of: odoo/enterprise#96632

*: ai_website_livechat, test_discuss_full_enterprise

Before this commit, when the last agent from a live chat conversation leave, the live chat conversation did not end.

Steps to reproduce:
- install "ai" and "im_livechat" modules
- have a visitor initiate a live chat conversation with 1 available human agent
- have have human agent open conversation in chat window and close chat window + confirm button
=> the live chat conversation does not end

When live chat agent is about to close the chat window of live chat, there's a warning to tell that this will make him/her leave the conversation and thus end the conversation. When proceeding, it doesn't actually do this.

This is a bug caused by overrides of `ChatWindow._onClose()`, which is a function invoked during the closing of chat window, that has an option `notifyState` that determines whether the user leaves the conversation or not. The overridden code had to ensure the param is preserved and passed to `super` calls, but they fail to do this, and thus the closing of chat window is not making the user leave the conversation.

This commit fixes the issue by passing `...arguments` to super calls to make sure the params are preserved as expected by original code of the `_onClose` function.

Note that we had a test for the good working of the feature, but this test run with `im_livechat` assets and not overrides on top of it such as `ai` module. The main culpit of the problem was caused by the override in `ai` module. To have test coverage for this problem, the test is not executed in both `im_livechat` test suite and the `test_discuss_full_enterprise`, which is a module whose HOOT suite runs code of discuss with all overrides such as `ai` module.

Forward-Port-Of: odoo/enterprise#98481

_______________________________________
## Short functional explanation of the error
Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding employee in company_2. If the user selects company_1 and company_2 but keeps company_1 as his current company, and tries to assign himself a task that has been created for company_2, nothing happens.

## Reproduction Steps
1. As an admin, create a user with which you'll be able to log. Make sure that you have at least 2 companies created, and that the user has access to both. Create an employee for that user in company_2.
2. Select both companies. In planning, create a slot for company_2 and publish it.
3. Log in as the user you created. Make sure that the current company is company_1. Select company_2.
4. Go to planning and try to assign yourself to the slot you've just created as an admin

### Expected behavior
Either an error message shows, or the employee is assigned to the slot for company_2 (as company_2 is selected).

### Unexpected behavior
Nothing happens

## Origin of the issue
When the current company isn't the one corresponding to the one the employee is in, even if another company is selected and contains the employee,
self.env.user.employee_id is set at False

_________________________________________
opw-4963674

---

Forward-Port-Of: odoo/enterprise#95933
Forward-Port-Of: odoo/enterprise#91616

Steps to reproduce:
-------------------------
1. Install `hr_payroll` module
2. Enable debug mode and click on Become Superuser
3. Go to All Payslips and open any payslip record
4. Click on the Export Payslip button

Observation:
-------------------------
A 404 (Page Not Found) error appears when clicking the Export Payslip button

Issue:
-------------------------
The button triggers the route `/debug/payslip/<id>`, which was removed in the following commit
https://github.com/odoo/enterprise/commit/57969bcaf876a13c36794adeb47e0da938e297ad#diff-0105b1a6a9e742e7eeaf7cc727745ebd3932177378d46332d4ca854f931b3359
The route was never reintroduced afterward, but the Export Payslip button remained in the view.
As a result, clicking it leads to a 404 error

Solution:
-------------------------
1. Temporarily bypass the `action_export_payslip` function.
2. Remove the Export Payslip button from the XML in the master forward port branch, as doing so does not impact any existing customizations relying on that button

opw-5115946

Forward-Port-Of: odoo/enterprise#97361
Forward-Port-Of: odoo/enterprise#96359

Currently, on creating a budget using split budget causing an error.

**Steps to Reporduce:**
1) Install **account_budget module(with Demo)**
2) Navigate to **Accounting>Accounting>Analytic Budget** 
3) Click on `Generate` set `Analytic Plan` and click on `Split`

Error:
`ValueError: Cannot convert budget.line.achieved_amount to SQL because it is not stored`

Root Cause:
since [this commit](https://github.com/odoo/odoo/pull/224667/commits/53b4670b1ad375ffc3800fc3beb97e960f229dc6), a new aggregate spec `sum_currency` was added. As a result, the code at [1] is executed for currency-aware aggregates. From the line, `self._field_to_sql(self._table, fname, query)` the ORM tries to create an SQL expression for `achieved_amount`. Because `achieved_amount` is computed `_field_to_sql` fails and error is raised.

Fix:
Provide a default SQL expression for computed fields on Budget Line

[1]: https://github.com/odoo/odoo/blob/af668f545676f72385c52629f8498edfe22219cd/odoo/orm/models.py#L1972-L2004

Used Reference: https://github.com/odoo/odoo/blob/d42102cac8fff3967cb605a897bbb0e8690464ed/addons/crm/models/crm_lead.py#L286-L298

sentry-6917352415

Forward-Port-Of: odoo/enterprise#98215

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

Forward-Port-Of: odoo/enterprise#97700
Forward-Port-Of: odoo/enterprise#96299

The test 'test_customer_event_description' was failing inconsistently
due to a discrepancy in how the event description is generated.

The test previously relied on the base calendar model's logic, which
automatically creates a description by selecting the first partner
associated with the event (excluding the organizer) based on default
record ordering. This selected partner may not always be the actual
person who booked the appointment.

However, when a user books through the front-end, the controller
uses specific logic to build the description, correctly identifying the
booker and bypassing the model's default behavior.

This difference caused the test to occasionally choose the wrong partner
for the description, resulting in unpredictable failures.

This commit aligns the test more closely with the actual booking behavior
seen by users. It now explicitly prepares the event description using the
designated booker's details and prevents the base model logic from
interfering.

This ensures the test is reliable and accurately validates the description
content. A potential future improvement would involve refactoring the
controller's description logic into the model layer for better testability,
as the current test mimics the controller logic, which could diverge over time.

Task-5207757

Forward-Port-Of: odoo/enterprise#98221

Description
-----------
The rule `voip_call_hr_access_rule` is added with an `OR` to `voip_call_rule_user`, but with the presence of the `One2many` `employee_ids` in the domain, the final query leads to a bad plan where Postgres does a full Seq.Scan on `voip_call` to then post-filter based on `user_id`.

To simplify the final query, we inline the ids that are being resolved from searching on `res.users.employee_id` (which is just a proxy for `res.users.employee_ids`). We also re-write the `ir.rule` to use this new inlining via `employee_id` and avoid using `employee_ids` which is resolved as a generic One2many from the ORM.

This leads to a few more queries, but each is fast and trivial to process.

Benchmark
---------
On a database with over 10M `voip.call` and `res.users`, for a Hr Officer, to open the Phone's app default list view with no default filter (the default setup), took:

| Before | After | Speed-up |
|--------|-------|----------|
| 13.3s  | 80ms  | 162x     |


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

Steps to reproduce:
-------------------
* Create an invoice with the following line:
  * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50%
* Confirm, create a global invoice
> Observation: Error
```
Code : CFDI40108
Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual 
al redondeo de la suma de los importes de los conceptos registrados.
```

Why the fix:
------------
The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63.
https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336

Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62.

opw-5023597

Forward-Port-Of: odoo/enterprise#95982
Forward-Port-Of: odoo/enterprise#94438

[IMP] account_accountant: css backport

To have a consistent css across all version of the new bank rec widget, we
decided to backport few changes.

backport of:
https://github.com/odoo/enterprise/commit/524a7a46a0c2888b591de7ad1a0a6d744e345f5a
https://github.com/odoo/enterprise/commit/2a83c85cb2c9a7a5da3d4a8483120eeda6b2e6cb
https://github.com/odoo/enterprise/commit/e3cb3ab3ec8c64297d8e97d941e0d2eea3e64667
https://github.com/odoo/enterprise/commit/fdbb93abbf831cfa2fdc75e79aa76c094d6e522a
https://github.com/odoo/enterprise/commit/f9725d7b01cbd1235f022821a6861adb2955e49e

[FIX] account_accountant: restrict some account in the set_account

Before this commit, we could select the liquidity account or bank suspense
account which could create a reco model for it that would do nothing.

[FIX] account_accountant: partner_name

Before this commit, when a transaction had no partner_name and some lines with
the same partner. When unfolded, we had the info of the partner on the statement
line and on the line itself which was a duplicate of information.

This commit will change when the line is unfolded so that the partner is visible
on the statement line only when there is a partner_name

[FIX] account_accountant: payable and receivable button

Before this commit, the payable and receivable buttons where on the top line
only when the reconcile button was not there anymore. Now We decided to always
have them present in secondary next to the reconcile button.

no task-id

Forward-Port-Of: odoo/enterprise#98325
Forward-Port-Of: odoo/enterprise#96852

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

-> Resolved in 19.0 see https://github.com/odoo/enterprise/commit/060f4c3e24e7add05273cfad5853884546937d0e#diff-3c84b414a086808e446ae3f90b3b803edf964c28237c153af19edda3ed05cc6bL21

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

Forward-Port-Of: odoo/enterprise#97497
Forward-Port-Of: odoo/enterprise#96299

Currently, on creating a budget using split budget causing an error.

**Steps to Reporduce:**
1) Install **account_budget module(with Demo)**
2) Navigate to **Accounting>Accounting>Analytic Budget** 
3) Click on `Generate` set `Analytic Plan` and click on `Split`

Error:
`ValueError: Cannot convert budget.line.achieved_amount to SQL because it is not stored`

Root Cause:
since [this commit](https://github.com/odoo/odoo/pull/224667/commits/53b4670b1ad375ffc3800fc3beb97e960f229dc6), a new aggregate spec `sum_currency` was added. As a result, the code at [1] is executed for currency-aware aggregates. From the line, `self._field_to_sql(self._table, fname, query)` the ORM tries to create an SQL expression for `achieved_amount`. Because `achieved_amount` is computed `_field_to_sql` fails and error is raised.

Fix:
Provide a default SQL expression for computed fields on Budget Line

[1]: https://github.com/odoo/odoo/blob/af668f545676f72385c52629f8498edfe22219cd/odoo/orm/models.py#L1972-L2004

Used Reference: https://github.com/odoo/odoo/blob/d42102cac8fff3967cb605a897bbb0e8690464ed/addons/crm/models/crm_lead.py#L286-L298

sentry-6917352415

The test 'test_customer_event_description' was failing inconsistently
due to a discrepancy in how the event description is generated.

The test previously relied on the base calendar model's logic, which
automatically creates a description by selecting the first partner
associated with the event (excluding the organizer) based on default
record ordering. This selected partner may not always be the actual
person who booked the appointment.

However, when a user books through the front-end, the controller
uses specific logic to build the description, correctly identifying the
booker and bypassing the model's default behavior.

This difference caused the test to occasionally choose the wrong partner
for the description, resulting in unpredictable failures.

This commit aligns the test more closely with the actual booking behavior
seen by users. It now explicitly prepares the event description using the
designated booker's details and prevents the base model logic from
interfering.

This ensures the test is reliable and accurately validates the description
content. A potential future improvement would involve refactoring the
controller's description logic into the model layer for better testability,
as the current test mimics the controller logic, which could diverge over time.

Task-5207757

Steps to Reproduce:
- Create a Sale Order containing two combo products placed consecutively.
- Change the quantity of the first combo → corresponding combo items update correctly.
- Without saving, change the quantity of the second combo.
- Observe that the combo items now appear misplaced — items from the second combo are inserted before those of the first combo.

Issue:
- The order of combo items becomes incorrect when multiple combo products are updated consecutively in the same unsaved Sale Order.

Cause:
- During `onchange`, the `self.order_line` recordset reflects the *in-memory order of applied commands* rather than the database `sequence` field because they are not saved in the DB during the edition.
- Each `onchange` rebuilds `order_line` using concatenated command lists (`delete + create + update`), So when multiple combos are modified without save, newly created combo items are appended according to command evaluation order — not by logical grouping.
- This causes combo items to shift relative to their parent combo lines.

Solution:
- Restrict the recomputation of order lines to non-combo lines by filtering out combo item lines during the rebuild. As combo items will always be in their desired sequence.
- This ensures that combo items always stay under their respective parent combos and their sequence is preserved, regardless of the order in which combos are updated.

opw-5148770
Affected Version:18.0

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

Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues.

The reconciliation logic worked as follows:

1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`.
2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`.
3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`.

The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`.

---

To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced.

- Reconciliation now starts by iterating only over the relevant `in_moves`.
- If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`.
- This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited.

**Implementation details:**

- An `OrderedSet` is used for the inverse mapping to preserve the original query order.
- Benefits of `OrderedSet`:
  - **O(1)** removal (assuming no collisions)
  - Maintains insertion order, ensuring the same order as the query result.

---

| Metric        | Before PR | After PR |
|---------------|-----------|----------|
| Execution Time| ~90 sec   | ~10 sec  |

The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`.

opw-4951469

# Issues

There are a total of 3 different flows by which we observe the common issue (name not updating in the fileviewer)

-----------------------------

### 1st flow
1. click on any image to preview it.
2. close the preview.
3. now just select the same document.
4. change it's name from the inspector and hit ENTER.
5. now keeping it selected, preview it again.
6. you will notice the file name has not been updated in the file viewer.

issue:
- the existing IF condition which is present only checks for the datapoint ID
  (which changes only when we replace the existing document with a new document).

reason:
- but in our case, since the document is same the ID remains the same.
- as a result, the code inside the IF block does not get executed and the
  document store is not updated.
  but we still need to update the document store with the newly updated document.

fix:
- we remove the IF condition so that we ensure that the document store is
  updated everytime we PREVIEW any document.

----------------------------------------------------

### 2nd flow

1. click on any image to preview it. (do not select it)
2. change it's name from the inspector and hit ENTER.
3. close the PREVIEW.
4. PREVIEW the same document again.
4. you will notice the file name has not been updated in the file viewer.

issue:
- for some reason the existing `record.save()` fails to save/update the root
  records.

fix:
- we find that record from the root and save it from the root.


----------------------------------------------------------

### 3rd flow

1. click on any image to preview it.
2. change it's name from the inspector and hit ENTER.
3. you will notice the file name has not been updated in the file viewer.

issue:
- the `previewStore` object is formed/updated only when we preview any document.
  it is this `previewStore` object which contains the list of documents to preview.
- but when we update the file name from the inspector, the code to update the
  `previewStore` is absent.

fix:
- on updating the values from the inspector, we now update the `previewStore`
  as well. which then goes on to update the name in the FILEVIEWER.

Task-4605750

Steps to reproduce:
-------------------------
1. Install Email Marketing Module
2. Create a new Mail List
3. Go to Mailing List Contacts
4. Select multiple contacts from list and click on Add to List button
5. From wizard select the newly created list and click on Add button
6. Open one of the contact added in step 4

Observation:
-------------------------
In the Mailing Lists tab of the contact, the newly added list does not show a Subscription Date. However, if we add the same through Add a line, the subscription date is shown correctly.

Issue:
-------------------------
When adding contacts to a mailing list through the wizard, the code https://github.com/odoo/odoo/blob/1e6ba783fcd898875dadb47924147688685707cf/addons/mass_mailing/wizard/mailing_contact_to_list.py#L34-L39 adds the contact using a direct database operation. This bypasses the ORM record creation for `mailing.subscription`, so the `create_date` (subscription date) is never set.

Solution:
-------------------------
Use `Command.create` on the `subscription_ids` field to properly create the `mailing.subscription` records and ensure the Subscription Date is set.

opw-5055372