[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#229344
Forward-Port-Of: odoo/odoo#213766

Behavior before:
When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors.

Behavior after:
Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets.

Root cause:
The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation.

Benchmark:

| Period size (journal items)  | Before patch   | After patch   |
|----------------------------------------|----------------------|--------------------|
| ~15k                                        | 7s                      | 5s                   |
| ~200k+                                    | Timeout error| 21s                 |


opw-5046077

Forward-Port-Of: odoo/enterprise#97660
Forward-Port-Of: odoo/enterprise#95047

Description
-----------
The commit odoo/odoo@0f981b14ea22cc154bcd93f53dc19f46c37ecb13 tried to fix an issue where, if the `company_id` was not set in the Form view, no `user_id` would match if they had a `company_id` set, while the wanted behavior was the inverse, all internal users should match regardless of companies.

This was fixed by introducing a computed field `allowed_user_ids` which was doing the company computation manually and replaced the `company_ids` domain leaf on the field.
Sadly, this approach introduces a performance regression on the front-end side, as the webclient creates internal data structures *per* individual result of the RHS in the domain. So if `allowed_user_ids` returns a lot of matching `ids`, it becomes a significant overhead.

Following the refactoring of `domains.py`, a slight semantic change happened and the initial issue of the bugfix can be resolved by just changing the domain operator to `'=?'` instead. When `company_id=False`, the domain leaf `('company_ids, '=?', False)` is optimized out by `_operator_equal_if_value` as `_TRUE_DOMAIN` (aka `(1, '=', 1)`). This is as expected behavior post-bugfix. This was not the case before the refactoring.

This allows us to completely deprecate the usage of the field `allowed_user_ids` and the front-end has no significant post-processing to do.

⚠️ This commits deprecates `hr.job.allowed_user_ids`, but doesn't remove it yet, as it might be referenced by views or custom JS.

Benchmark
---------
On a 19.0 database where `allowed_user_ids` returns 1.4k ids, opening the default kanban view of the Recruitment app took:

|                       | Before  | After  | Improvement |
|-----------------------|---------|--------|-------------|
| Backend process time  | 400ms   | 160ms  | 2.5x        |
| Frontend process time | 3.3s    | 220ms  | **15x**     |
| Total (LCP) time      | 3.7s    | 380ms  | 9.7x        |
| Response Payload size | ~800KiB | ~33KiB | **24x**     |

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

Forward-Port-Of: odoo/odoo#232354

*: purchase_accountant,sale_account_accountant

This commit adds new menu for SO and PO accruals.
A custom list view (`js_class`) was created for those reports:
`accrual_list_view`.

AccrualListView
===============
This view is used both by `sale.order.line` and `purchase.order.line`.
Its functionnalities are:

- The user can choose a date to see records' values in the past;

- If a line is clicked, instead of opening the line's form view, it will
  open its order form view instead.

Technical notes about this view:

- The chosen date is passed to the context but there is issue when the
  view is grouped (and it is by default): while the grouped lines uses
  the right context with the selected date, the contained lines sometime
  use an old version of this context with a previously selected date
  which means the grouped data are not the same than the single lines
  data. To fix that, we force the context on each group.

- The "at_date" fields are non-stored computed fields. By default, there
  is no sum value for those fields. Server side, we override the
  `_read_group` method to "manually" compute those fields sum. To be
  able to do that, we tweak the aggregate config in this view.

Boolean fields
==============
Four boolean fields are created:

- `prepaid_expense` and `bill_to_receive` for `purchase.order.line`;
- `deferred_revenue` and `invoice_to_be_issued` for `sale.order.line`.

Those fields are usefull to fetch right order lines for the right
accrual and are always a balance between delivered/received quantity and
invoiced quantity.

[task-5075455](https://www.odoo.com/odoo/966/tasks/5075455)
Community PR: odoo/odoo#231510

[IMP] account_fiscal_categories: enhance list view of account_account
======================================================

With this commit, we add a new field `current_rate` in `account.account`. This `current_rate` is a non-stored compute field, used to compute the current applicable rate on the given account.

This `current_rate` and `fiscal_category_id` has been introduced in the list view of `account.account`.

[IMP] account_fiscal_categories: enhance multiple rate warning in fiscal report
===========================================================

Before this commit, the "multiple rate" warning was shown even when no entries for accounts with multiple rates existed in the selected period. This happened because all accounts were considered for multiple rates, regardless of journal entries in that period.

After this commit, only accounts with entries in the selected period are considered for the "multiple rates" warning. The warning is now clickable, redirecting the user to the accounts having multiple rates.

[FIX] l10n_be_fiscal_categories: remove redundant rate on CoA
=================================================

This commit removes the redundant fiscal rate on account-613311. Both fiscal categories 1206 and 1073 were assigned to this account, resulting in two rates. Only 1073 should be there.

ref-https://github.com/odoo/enterprise/commit/f2579a80833ac129b2f21613b93c4e3203646a1b



**task**-5163392
-----------------------

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

Forward-Port-Of: odoo/odoo#233740

Problem:
Reverting history sometimes restores children in the wrong order (e.g. `acb` instead of `abc`).

Cause:
In `historyRevert`, node reinsertion relied on `nextId` / `previousId` only if the referenced sibling was connected to the live DOM (`.isConnected`).
When that check failed, the fallback was `parent.append()`. On some Firefox versions, mutation events list the parent removal *after* its children’s, meaning the parent is reinserted first while the children’s siblings still exist but are detached. Because `.isConnected` returned false, the fallback `append()` misplaced nodes and broke the order.

Example (processed in reverse order):
```js
[
  { type: 'remove', id: 'p', parentId: 'root', node: { tagName: 'P' } },
  { type: 'remove', id: 'b1', parentId: 'p', nextId: 'b2',
    node: { textValue: 'b' } },
  { type: 'add', id: 'b1', append: 'x', node: { textValue: 'b' } },
  { type: 'remove', id: 'c1', parentId: 'p', node: { textValue: 'c' } },
  { type: 'add', id: 'c1', append: 'x', node: { textValue: 'c' } },
]
```
During revert:
- Child removals (b1, c1) are processed first.
- Their sibling nodes exist but are detached → .isConnected false.
- Fallback append() used → "b" inserted after "c" → acb.
- `<p>` restored last with children in wrong order.

Solution:
Remove the `.isConnected` condition.
`before()` and `after()` work even on detached nodes, preserving the original child order regardless of browser mutation sequence.

Steps to reproduce:
- Open todo.
- Have this:
```html
<p>a[]</p>
<p>b<br>c</p>
```
- Press Delete.
- Observe "b" and "c" are not in the right order.

opw-5139795

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

Forward-Port-Of: odoo/odoo#233582

### Issue:

Scans processed during picking batch creation in the barcode app are interpreted as scans related to the BarcodePickingBatchModel edition (that is product, lot, package,... scans) which does not make sense and raises multiple errors.

### Steps to reproduce:

- In the settings enable "Batch Transfers"
- Inventory/Operations/Transfers/Batch Transfers
- Create a new batch and do not confirm it
- Go to the barcode app > Batch Transfers > Clear filters
- Select your draft batch
- Scan anything
#### > Traceback

#### Other issues:

The same flow with a cancelled batch triggers the same tracebacks and, with a done batch triggers the message: "This picking is already done".

### Cause of the issue:

Since `this.state.view === "barcodeLines"`, scans are processed as if we were processing an existing `BarcodePickingBatchModel` with lines: https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/components/main.js#L204-L209 In particular, if the scan corresponds to a product, and error will be raised because the scan can not process a `createNewLine` for the scanned product in the current view and if the scan does not correspond to anything valid, it will raise an error because `this.picking` is undefined and `this.picking.use_existing_lots` raises an error:
https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode/static/src/models/barcode_model.js#L1115 https://github.com/odoo/enterprise/blob/ce7460b27028d4133c4689afd2e8f303268494a0/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L177-L179

opw-5162164

Forward-Port-Of: odoo/enterprise#98022
Forward-Port-Of: odoo/enterprise#97526

**Steps to reproduce:**
1. Install the module `project_timesheet_forecast_sale`.
2. Go to Project > Configuration > Projects and open any project.
3. Go to Dashboard, click the "Timesheets and Planning" button.

**Issue:**
- Opening the "Timesheets and Planning" view raised the following error:
     `TypeError: Cannot read properties of undefined (reading 'length')`

**Cause:**
- Error caused by [method](https://github.com/odoo/odoo/blob/5be6ef1ae3958a25e680f5fa30824fec57d63efe/addons/web/static/src/views/pivot/pivot_renderer.js#L107-L109), occurred because the `planned_costs` and `effective_costs` fields are float fields but were declared with `widget="monetary"` in the pivot view. Since these fields use `format_type="monetary"` and have no corresponding `currency_field`, the pivot renderer failed to resolve currency mappings (`currency_ids` was undefined) and crashed.

**Solution:**
- Removed the `widget="monetary"` attribute from the `planned_costs` and `effective_costs` fields in the pivot view so they are treated as numeric measures instead of monetary ones.

**opw-5179265**

**Steps to reproduce:**
1. Install the module `project_timesheet_forecast_sale`.
2. Go to Project > Configuration > Projects and open any project.
3. On the project's dashboard, click the Dashboard stat button.
4. In the stats dialog, click "Timesheets and Planning".

**Issue:**
- Opening the Timesheets and Planning stat button from a Project dashboard (after installing `project_timesheet_forecast_sale`) raises the following error:

    TypeError: Cannot read properties of undefined (reading 'length')

**Cause:**
- The method _getCellCurrency() expected every dataset to have corresponding currencyIds, but the Timesheet/Forecast report does not include any currency information in its configuration data.
As a result, config.data.currencyIds[key] was empty, leading to the crash when trying to access .length.

**Solution:**
- Handle missing currencyIds in _getCellCurrency() by checking for an empty or undefined entry before accessing it.
If no currency is defined (as is the case for timesheet/forecast reports), the method now simply returns.

**opw-5179265**

On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items.

### Steps to reproduce:

On a small screen size (Zebra scanner, Iphone 4,..)
* Open barcode app
* Go on  Operations -> Receipts
* Apply a filter so that the list becomes empty. 
-> the image is over the barcode button and the text.

### Observation:

Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction.

### Why the fix:

The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below.

opw-5123880

Forward-Port-Of: odoo/enterprise#98243

When grouping by any field in Analytic Accounts, a traceback occurs.

Steps to reproduce the error:
- Install ``Accounting`` module
- Go to Settings > Enable ``Analytic Accounting`` > Save
- Go to Accounting > Configurations > Analytic Accounts > Group by any field

Traceback:
```py
ValueError: Cannot convert account.analytic.account.debit to SQL because it is not stored
```

https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/addons/analytic/models/analytic_account.py#L128-L133
When the user applies Group By, the ``_read_group_select`` method is called with ``debit:sum_currency`` as the ``aggregate_spec``.
This method then calls the super ``_read_group_select`` method,
and the super method calls the ``_field_to_sql`` method from [1].
which uses ``field.to_sql()`` to build an SQL object for the ``debit`` field at [2].
Since the ``debit`` field is a non-stored computed field, the ``to_sql()`` method raises the above ValueError at [3].

[1]: https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/odoo/orm/models.py#L2002

[2]: https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/odoo/orm/models.py#L2930

[3]: https://github.com/odoo/odoo/blob/a884794ebfc8145c61bb34908093f00246f224ff/odoo/orm/fields.py#L1211

sentry-6921656195

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

Issue
-----
After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity.

Steps to reproduce
-----
- Unarchive MTO route
- Create a stored product
	- Routes MTO & Manufacturing
	- Empty BoM
- Create a Sale Order for 3 units of the product & confirm it
- Go to the linked MO and split it in 2 (quants of 1 and 2)
- Confirm both MOs (and produce)
- Go to the sale's delivery
> The delivery's move only shows 1 unit of the product

Why the move quantity is only 1
-----
After confirming the first of the 2 backorder productions, when we manufacture the product, we go through

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054

Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

Which creates a SML for the delivery move when reserving it

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971

This in turn triggers the computation of the move's quantity since it depends on the move's lines

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383

Our move ends up with a quantity of 1.

When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

This means we don't create a new SML for the delivery move, so the quantity stays at 1.

Why there is no move_dest_id
-----
When splitting the production, we go through

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829

We create new a MO and SM for the backorder. The SM is created here

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915

When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656

So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78

In the write, we get to a line where we access the production's state

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931

This triggers a recompute of the field.

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552

In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800

The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f).

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167

-----
Ticket:
opw-4865082

Forward-Port-Of: odoo/odoo#233114
Forward-Port-Of: odoo/odoo#223792

Before this PR, if you created a leave of a type that had sandwich leave
enabled on a non-working day, it would show a negative duration.

This PR fixes some issues related to sandwich leave cases

(where Saturday and Sunday are considered non-working days):
- Friday - Monday across weekend - counted (4 days).
- Hour-based leave types: weekend bridging increases hours accordingly
- Public holiday in the middle (Tue-Thu with Wed PH) - counted (3 days).
- Stop/Start exactly on a public holiday(Tue-Wed(Public holiday), or Wed(Public holiday)-Thu) - trimmed to 1 day.
- Public holiday only - 0 days.
- Two single-day leaves around a Public holiday
  - When the second leave is created, it bridges via a public holiday (2 days),
  - The first one remains 1 day if it stands alone
- Mixed leave types:
  - If the linked leave type doesn’t have sandwich enabled, no sandwich rules.
  - If both leave enable sandwich (with different types) - sandwich rule applies
- Refusing/canceling a linked leave must immediately adjust the other side’s duration
(e.g., Monday refused - Friday drops from 3 - 1 day)

Task-4430044

Co-authored-by: @mepe-odoo

Forward-Port-Of: odoo/odoo#233717
Forward-Port-Of: odoo/odoo#193186

Currently, an error occurs when computing the dependency warning for tasks.

**Error:**
    ```Expected singleton: project.task(8, 7).```

After [this commit] if task1 depends on task2, if task1's task dependency is False, then the dependency warning for task1 should also be False.

However, when task dependency is enabled and two or more tasks are blocked by a single task, changing the Deadline of the blocking task triggers the computation of the dependency warning for those dependent tasks. During this process, the system attempts to check the task dependency across multiple records, which raises the error at [1].

This commit ensures that, since self may contain multiple tasks, the dependency warning is computed safely for each specific task.

[this commit]: https://github.com/odoo/enterprise/commit/50768627accb9d9767514fda7c6975bf4d8227d3#diff-b4bb763881453b0d69cae371c4c5034f6e199dfaf3a3056aba3381cf64dbf3dc

[1]- https://github.com/odoo/enterprise/blob/769201e22618b6683863f0839d7ad80bea0927cf/project_enterprise/models/project_task.py#L350

sentry-6914184933