This update enhances the chat interface by adding a company card with details sourced from DNB. Previously, industry tags from DNB were stored separately, but now they're integrated directly into this new company card within the chatter window, providing a more complete view of partner information.

Before:
 Industry tags coming from DnB were stored in the Tags section of res.partner.
 and there was no Company info card in chatter.
After:
Industry tags coming from DnB are not stored in the Tags section of res.partner. Company card is created in chatter that is having details from Dnb along with tags.

task-5373200

This update modifies the process for generating BOE (Boletín Oficial Electrónico) tax reports in Spain, aligning with recent regulatory changes (BOE-A-2025-25390). The update addresses a requirement for the Modelo 347 report, adding a placeholder for subsidy numbers with default zeros. This ensures compliance with Spanish tax regulations.

reference: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-25390 considering the modelo 347

As we do not have anything for the subsidy number, we just put 6 0s.

opw-5926624

This pull request adds a crucial test case to the account_edi_ebl_cii module, ensuring the system correctly processes Electronic Bank Letter (EBL) data in CII format. Previously, this specific functionality lacked adequate testing, potentially leading to errors in financial transactions. Merging this change strengthens the reliability and accuracy of our EBL processing.

Adding test for 5f5181c6b8eed3550432371227b22a36715cc857

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

This update resolves a user error that prevented invoices from being sent via PEPPOL, a key compliance feature. The issue stemmed from the audit trail preventing attachment modifications during the PEPPOL sending process. The fix ensures attachments are handled correctly, allowing invoices to be successfully transmitted.

**Steps to reproduce:**
- Install Accounting and l10n_de
- Switch to a German company (e.g. DE Company)
- In Accounting settings, activate Peppol

- Create an invoice:
  * Customer: [a German customer with VAT]
  * Invoice Lines: [a line with a tax]
- Confirm the invoice
- Send the invoice via PEPPOL

**Issue:**
A UserError is raised:
"You cannot remove parts of the audit trail.".

**Cause:**
The audit trail prevent modifying an attachment.
When sending an invoice to PEPPOL, a message is logged in the chatter with both the invoice PDF and XML as attachment.
During the process, "res_model" and "res_id" fields of the attachments are set to the message record.
Before doing it, "res_id" is removed in SQL to prevent raising the audit trail error.
However, it fails because the value is still in cache.

**Solution:**
Invalidate these fields as it is done when sending the invoice without PEPPOL.
https://github.com/odoo/odoo/commit/e0229d5c7fa89d32f67151d307161482c300ff20

opw-5916696




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

This update fixes an issue with part-time schedules and public holidays in the French localization module (l10n_fr_he_holidays). Previously, there were inconsistencies in how part-time schedules were handled alongside public holidays. This change ensures accurate scheduling and holiday calculations for French businesses, improving payroll and HR processes.

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

This update resolves an issue where invoices created in a non-AFIP POS sales journal in Argentina didn't display available document types. The fix ensures that document types are correctly identified for these invoices, allowing for proper record-keeping and reporting. This improves the accuracy of financial data for businesses using this sales channel.

Issue:
No documents are available for Invoices of a non AFIP POS sale journal.

Steps to reproduce:
- in a Company in Argentina.
- Create a new journal named "NO-AFIP POS" of type "Sales" with documents, but not AFIP POS.
- Create an invoice for "Consumidor Final Anónimo" with the journal "NO-AFIP POS".

Current behavior:
No document show in the Document Type field.

Expected behavior:
Some documents should appear.

Solution:
Find document for those sale journals as if they were journals using the AFIP POS system for pre-printed invoice.

opw-5234311

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

This update ensures that the correct company is used when downloading FEC files, resolving a potential mismatch between the selected company in the user interface and the company used during file generation. Previously, the download process defaulted to the user's default company, leading to inaccurate reports. This fix guarantees that FEC files are generated and downloaded using the intended company data.

The FEC generation spans two HTTP requests: generate_fec (RPC call)
and the download controller (plain GET). RPC calls include
allowed_company_ids in the context, so self.env.company resolves
correctly. But the plain GET to /download/fec_file/<id> carries no
context, so self.env.company falls back to user.company_id (the user's
default company), which may differ from the one selected in the UI.

This commit aims to fix the issue by passing
the company_id from generate_fec through the download URL and restore it in the controller via with_company(), with an access check to ensure the user belongs to that company.

task-5926528

Forward-Port-Of: odoo/odoo#248126

This update enhances the security of invoices by preventing the use of untrusted accounts when processing inbound invoices. The team removed unnecessary calculations and logging logic, simplifying the process and relying on existing methods. This change ensures greater accuracy and reduces potential risks associated with invoice processing.

fixed some tests and remove the computation logic from account_move_reversal wizard, to rely on existing compute method



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

Forward-Port-Of: odoo/odoo#247954

This update fixes an issue where Italian tax information (like VAT number) wasn't being correctly applied when creating a company record from an Italian ecommerce order. The change ensures that all required Italian tax fields are automatically populated, improving data accuracy and compliance for Italian businesses using Odoo.

**STEP TO REPRODUCE**

1. Create a ecommerce order on a shop page of a italian company.
2. Goes to the checkout page, enter info (company_name, l10n_it_codice_fiscale, l10n_it_pa_index).
3. On the contact created, click on create company.
4. Notice l10n_it fields are not propagated to the company.

opw-5477372

This update resolves an issue where stock valuation reports were generating inconsistent results due to how related records were being linked. The fix ensures the reports always produce the same output by sorting purchase and sales order IDs, guaranteeing a reliable and predictable report. This improves data accuracy for financial reporting.

Occasionally the test_kardex_report test fails:

```
Traceback (most recent call last):
  File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in test_kardex_report
    self.assertSequenceEqual(
AssertionError: Sequences differ: ['M1|[18 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[313 chars], ''] != ['M1|[18 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[313 chars], '']

First differing element 0:
'M1|0[17 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[21 chars]0|1|'
'M1|0[17 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[21 chars]0|1|'

- ['M1|0000|1|99|FURN9999|1||02/01/2024|01|FBILL202401|0002|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^

+ ['M1|0000|1|99|FURN9999|1||01/01/2024|01|FBILL202401|0001|02|product_order_no|NIU|3.00|0.00|1|',
?                             ^                           ^
```

The issue was reproducible locally by disabling nested loop joins: `self.env.cr.execute("SET LOCAL enable_nestloop = off")` to nudge Postgres to use a different join strategy.

The test creates a PO that is picked and invoiced in two steps (first quantity 3, then the remaining 2). As a result, the `stock.valuation.layer` ends up being linked to two `account.move.line`s because the join goes through the same `purchase_order_line`. So it will appear twice in the `_get_ple_reports_data()` query. A `DISTINCT
ON (stock_valuation_layer.id)` was already there with the goal of picking one of them. Which one depends on the order, but it's not deterministic: the valuation layer's `id`, `product_id`, and `create_date` will all be the same.

This commit makes the behavior deterministic by sorting on PO line and SO line ids.

runbot-error-238888

This update fixes an issue preventing users from dragging tasks to the 'Mitchell Admin' row within the Gantt chart view. The previous code incorrectly set rows to 'readonly' during the drag-and-drop process, blocking subsequent actions. This change ensures smooth task movement within the Gantt chart.

**Steps to reproduce**
1. Go to Project > Tasks > All tasks > Gantt view
2. Drag and drop a task from the Mitchell Admin row to the Marc Demo row.
3. Now, it will be impossible to drag and drop a task from any row to the Mitchell Admin row.

**Cause**
Since commit 3009885188580a7e82c25fc224428fa0f9ba63af, a readonly attribute is removed when the dragging starts to be able to drop in the same row. It is added back at the end of the drag, even if the row is not readonly. This causes any row from which we drag from to become readonly.
https://github.com/odoo/enterprise/blob/3009885188580a7e82c25fc224428fa0f9ba63af/web_gantt/static/src/gantt_renderer.js#L291

opw-5462522

This update strengthens the security of invoices by preventing untrusted accounts from being used in inbound transactions. The change addresses a vulnerability where unauthorized accounts could potentially be linked to invoices, improving data integrity and reducing risk. This update was a necessary fix to ensure the accuracy and reliability of financial records.

fixed some tests

see odoo#247954

Forward-Port-Of: odoo/enterprise#106980

This update corrects a reporting issue where assets marked as disposed still appeared in depreciation schedules. The fix ensures that cancelled depreciation moves, which were incorrectly influencing disposal dates, are no longer considered when generating reports. This provides more accurate asset reporting.

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749