This update adjusts the bank statement reconciliation process within Odoo Enterprise to better align with accounting regulations. Specifically, it prevents statement lines from being automatically marked as reconciled when the 3% rule applies, ensuring accurate financial reporting. This improves the reliability of financial data.

POC

no task id

This change updates the email address used for automated support notifications from iap@odoo.com to noreply@odoo.com. This ensures that client responses to support emails are correctly directed to the appropriate team, improving response times and support efficiency.

The current mail address is iap@odoo.com so some client respond to the automatic mail.

This fix change it to noreply@odoo.com

Task-6086556

Forward-Port-Of: odoo/enterprise#114712
Forward-Port-Of: odoo/enterprise#114097

This update corrects a mismatch in transaction identifiers used when generating financial reports (FAIA export) for Luxembourg. Previously, the system used different identifiers, leading to potential reporting errors. This change ensures all transaction IDs align, improving the accuracy and reliability of financial data.

The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too.

opw-6111343, opw-542729

Forward-Port-Of: odoo/enterprise#113846

This update resolves an issue where incorrect string comparisons were occurring within the l10n_co_dian module. The fix ensures accurate data processing for the Colombian Dian tax reporting system, preventing potential errors and ensuring compliance. This change improves the reliability of the Dian localization functionality.

Issue:
commit 780b12ca7e2525bfa86f00d232fa9f186c914a85 introduced incorrect string comparison

opw-6077050

This update allows administrators to control when subscription users are automatically reset. Previously, this process was automatic and couldn't be altered. This change provides greater flexibility in managing subscription accounts and ensures alignment with business processes.

After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable.

Forward-Port-Of: odoo/enterprise#114459
Forward-Port-Of: odoo/enterprise#114055

This update fixes a bug that prevented users from changing the state of tax returns within the accounting dashboard. Previously, attempting to use an invalid state would cause the page to crash. This change ensures the system handles state transitions correctly, improving the reliability of tax return management.

Before this commit, if you were to change the states_workflow to from a some that had an option, such as submitted, to something that did not contain a state that an account_return does not have, you would crash when trying to load the page. To get to this page go to the accounting dashboard and click on the tax returns option. To change the states_workflow change go to accounting -> configuration -> return types and change the states variable.

opw-6107995

This update resolves an issue where portal users were incorrectly seeing the 'View Timesheets' button, even when they lacked the necessary permissions. The fix utilizes a new helper method to accurately control button visibility, ensuring users only see options they are authorized to access. This improves the user experience and prevents confusion.

**Issue:**
   The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.

 Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet.
 We are using it here.

 task-4745519

Forward-Port-Of: odoo/enterprise#115193
Forward-Port-Of: odoo/enterprise#113481

This update corrects a potential error in the account reports module where custom modules could cause conflicts when referencing the 'state' column. By explicitly using column aliases, the system now correctly identifies and resolves ambiguous column references, ensuring reports run smoothly across all client configurations.

Issue:
-------
There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes,
https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause
```
File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line
2204, in _check_suite_common_vat_report
self.env.cr.execute(SQL(
File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute
self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous
LINE 9: state = 'posted'
```

Solution:
------------
Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'`

OPW - 6044665

Forward-Port-Of: odoo/enterprise#114341

This update ensures that when a company is quickly created through the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. The fix also includes a minor typo correction within the equity views.

The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case.

This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views.

task-6132343

This update corrects a technical issue where styling applied to a list view was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list view, improving the visual consistency of reports. This resolves a minor cosmetic problem.

The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well.

task-6141685

This update resolves an issue where time off allocations couldn't be deleted after a payslip was validated. The fix adjusts the system to recognize that time off created *after* payslip validation can be safely deleted, removing a previous restriction. This improves usability for HR and payroll teams.

## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**

## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:

https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203

It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.

The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.

opw-6089990

This update resolves an issue where payroll document validation incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a company-dependent field with a stored employee flag, ensuring accurate validation during background tasks like payroll generation. This prevents errors and ensures proper document access.

Steps to reproduce-
1) In a multi-company environment, create an employee in a secondary company. 
2) Link a Portal User to this employee via the user_id field. 
3) Create and validate a payslip for this employee. 
4) Run the 'Payroll: Generate pdfs' cron.

Error - ValidationError: The following user(s) cannot own root documents/folders:
portal_employee: Payslip - portal_employee

Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company).

When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner.

Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies.

opw-6143042

Co-authored by Tina Lin (liti)