Document users can now start an expense directly from the Documents app workflow actions. The new expense automatically uses the document name and a default “other” category, reducing manual entry and making it easier to turn receipts or related files into expense records.

PURPOSE
-------
A document user can create an expense from a document application.

SPECIFICATIONS
--------------
- Added a new "Create a Expense" on work flow Actions for creating an expense.
- When the expense is created from the document, the name of the expense should be
  the name of document and the category should be the other.

 task-304768

Documents managers can now use an activity view directly in Documents to see and manage scheduled activities linked to files. The view includes the document inspector, making it easier to review document details while planning follow-ups.

In this commit, we add activity view in documents.so user see the schedule activity documents.

task-289964

The Knowledge app's article link dialog has been updated to work more reliably in the editor. This helps users insert links to Knowledge articles without running into issues caused by the previous dialog behavior.

Purpose
=======

The old dialog's select2 is broken because of bootstrap so we are converting it to an OWL Component which is wrapped with a ComponentWrapper in order to be able to use it inside knowledge's wysiwyg.

Specs
=====

We are reusing the old dialog's select2 since it worked completely fine before.
We wrapped the new dialog, `ArticleLinkBehaviorDialog`, inside `ArticleLinkBehaviorDialogWrapper` which takes as props two functions:

* save, which is the function that will render the correct link based on the article that the user chose in the dialog

* close, which is the default close function of all Dialog.

task-3079001

Kenyan payroll configuration has been updated based on testing to make payslip calculations and reporting more accurate. Payslip presentation was also made more flexible, helping payroll outputs better reflect relevant salary lines for employees.

This commits adjusts the the datas for the kenian
payroll localization based on tests.

task-3029348

Polish financial report templates are now maintained in English, with Polish translations provided separately. This improves consistency for multilingual deployments while preserving the Polish report wording for local users.

Reports are translated in English.
Added .po to translate it back into Polish.

The appointment type list now gives more room to appointment names, making similar entries easier to tell apart. Appointment counts and related report figures are also aligned more cleanly for a clearer overview.

**PURPOSE**

Improve the kanbanlist in appointment type.There is not enough space for names. as all types start with the same few words we can't differentiate them.

**SPECIFICATIONS**

- Add more space for name.
- Align  the appointment count, appointment count report.

Task-3109366

Appraisal survey results now align with the updated survey filtering behavior. This helps appraisal feedback results display correctly and consistently after recent survey result changes.

Purpose
=======
Updating the module to the new filter results modifications done in Survey.

Specifications
==============
Adding the missing parameter to the _get_user_input_domain method
inheritance to handle the new search domain implementation.

Task-2957775

This update adds a team performance report for recruitment so managers can better compare recruiter activity and hiring outcomes. It also improves the spreadsheet color picker, making spreadsheet formatting easier and more user friendly.

WIP

This change removes legacy code that added chatter to older form views in the Mail Enterprise module. It simplifies maintenance because that compatibility layer is no longer useful in practice and should not affect normal current usage.

Sales workflows can now operate based on the currency of the sales order, website, or point of sale instead of requiring a pricelist. This simplifies pricing setup across subscriptions, rentals, field service, point of sale, and inter-company sales while keeping currency handling consistent.

Removes the constraint of using a pricelist and makes all sales flows
relies on the currency of the sale order, website, point of sale...

task-2735672

See also
- https://github.com/odoo/odoo/pull/84920
- https://github.com/odoo/upgrade/pull/3642

[FIX] account_avatax: don't check address on payments `account.payment` inherits `account.move`. Its fiscal_position_id field will be computed as normal. In the case of auto-applied fiscal positions it's possible `account.payment` records will have Avatax fiscal positions. When that happens a ValidationError is raised if the partner's address is incomplete (missing country, state or zip). To reproduce: 1/ set the Avatax fiscal position to auto-apply on California 2/ create a partne

[FIX] account_avatax: don't check address on payments

`account.payment` inherits `account.move`. Its fiscal_position_id
field will be computed as normal. In the case of auto-applied fiscal
positions it's possible `account.payment` records will have Avatax
fiscal positions. When that happens a ValidationError is raised if the
partner's address is incomplete (missing country, state or zip).

To reproduce:

1/ set the Avatax fiscal position to auto-apply on California
2/ create a partner with state California and country USA but no zip
3/ create and validate an invoice for this customer
4/ click "Register payment" on the invoice
5/ click "Create payment" in the wizard
6/ Error: 'Customers are required to have a zip, state and country...'

Since payments are not sent to Avatax (only invoices are sent) we
don't want to validate their addresses. The current behavior can also
block payment on a non-Avatax invoice if an Avatax fiscal position is
auto-applied on the payment, which is confusing for users.

This commit ensures to only check non-payments (checked via the
`payment_id` field on `account.move`).

opw-3140130

Forward-Port-Of: odoo/enterprise#35948

P01 for l10n_mx_edi_usage was used in cfdi 3.3 as 'por definir' (to define) and that option existed at the time. With the transition to cfdi 4.0, that option P01 disappeared, but we kept it and changed it in the XML to S01, which is the 'Sin efectos fiscales' (without fiscal effects) option. However, this is confusing for the users as 'Sin efectos fiscales' is not the same as 'Por Definir'. So, in order to avoid confusion, we changed the label for the old option to be only used in 3.3 and

P01 for l10n_mx_edi_usage was used in cfdi 3.3 as 'por definir' (to define) and that option existed at the time.

With the transition to cfdi 4.0, that option P01 disappeared, but we kept it and changed it in the XML to S01, which is the 'Sin efectos fiscales' (without fiscal effects) option.

However, this is confusing for the users as 'Sin efectos fiscales' is not the same as 'Por Definir'.  So, in order to avoid confusion, we changed the label for the old option to be only used in 3.3 and we added an option S01 that will be chosen by default when cfdi 4.0 is installed.

Forward-Port-Of: odoo/enterprise#35933

Before this fix, when an invoice was reconciled with a payment made on a prior date, the invoice appeared in the report at the date of the payment. This was wrong: in this case, we want to use the most recent date: if the payment is in the past, the invoice date must be used. X-original-commit: f3346c12e36b1d19decf610d24453afeace3e42b Manual forward-port of https://github.com/odoo/enterprise/pull/33007 Forward-Port-Of: odoo/enterprise#35892

Before this fix, when an invoice was reconciled with a payment made on a prior date, the invoice appeared in the report at the date of the payment. This was wrong: in this case, we want to use the most recent date: if the payment is in the past, the invoice date must be used.

X-original-commit: f3346c12e36b1d19decf610d24453afeace3e42b Manual forward-port of https://github.com/odoo/enterprise/pull/33007

Forward-Port-Of: odoo/enterprise#35892

To reproduce: 1) Create a company in Belgium 2) Assign a VAT number to this company 3) Set an accounting firm as representative of this company. Make sure it has no VAT number 4) Open the EC Sales List and try exporting it to XML ==> An error message should be shown, warning that some data (the VAT) are missing on your representative, and proposing to complete them. Instead, a traceback was raised. This was due to the fact _get_xml_export_representative_node received the EC Sales repo

To reproduce:

1) Create a company in Belgium
2) Assign a VAT number to this company
3) Set an accounting firm as representative of this company. Make sure it has no VAT number 4) Open the EC Sales List and try exporting it to XML

==> An error message should be shown, warning that some data (the VAT) are missing on your representative, and proposing to complete them.

Instead, a traceback was raised. This was due to the fact _get_xml_export_representative_node received the EC Sales report as its parameter, and tried to call _split_vat_number_and_country_code on its handler, while this function is only defined on the Belgian tax report's custom handler.

We solve that by revamping _split_vat_number_and_country_code, so that it can be called without referring to any handler.

OPW 3102753

Forward-Port-Of: odoo/enterprise#35909

Purpose ======= Fix the properties types image that should be light and not dark in dark mode. Fix the background color of the selection options. Task-3117416 Forward-Port-Of: odoo/enterprise#35408

Purpose
=======
Fix the properties types image that should be light and not dark in dark mode. Fix the background color of the selection options.

Task-3117416

Forward-Port-Of: odoo/enterprise#35408

The cash flow comparison was not working when there was a reconciled move in any of the periods. The problem was due to a wrong initialization of two variables (reconciled_account_ids and reconciled_percentage_per_move). They should both have at least the column_group_key for each period, but they were initialize to empty values. Forward-Port-Of: odoo/enterprise#35806 Forward-Port-Of: odoo/enterprise#34053

The cash flow comparison was not working when there was a reconciled move in any of the periods.

The problem was due to a wrong initialization of two variables (reconciled_account_ids and reconciled_percentage_per_move). They should both have at least the column_group_key for each period, but they were initialize to empty values.

Forward-Port-Of: odoo/enterprise#35806
Forward-Port-Of: odoo/enterprise#34053

Forward-Port-Of: odoo/enterprise#35773

Forward-Port-Of: odoo/enterprise#35773

See: https://finances.belgium.be/fr/entreprises/personnel_et_remuneration/precompte_professionnel/calcul Forward-Port-Of: odoo/enterprise#35752 Forward-Port-Of: odoo/enterprise#35574

See: https://finances.belgium.be/fr/entreprises/personnel_et_remuneration/precompte_professionnel/calcul

Forward-Port-Of: odoo/enterprise#35752
Forward-Port-Of: odoo/enterprise#35574

Steps: - Create multiple companies and select one different from the default user's company - Go to sign - Upload a document to sign and send it to a partner - Sign the document with the link provided in the mail - Download the certificate of completion Issue: The company on the certificate is the default one Cause: the ir.action.report takes the default company rather than the one used to create the document Solution: Pass the the right company throught the data use by the temp

Steps:
- Create multiple companies and select one different from the default user's company
- Go to sign
- Upload a document to sign and send it to a partner
- Sign the document with the link provided in the mail
- Download the certificate of completion

Issue:
The company on the certificate is the default one

Cause:
the ir.action.report takes the default company rather than the one used to create the document

Solution:
Pass the the right company throught the data use by the template render

nb: The issue was first detected on 15.2 but it's not possible to fix it there.

opw-3112628

Forward-Port-Of: odoo/enterprise#35910

**Current behavior before PR:** When we try to insert an appointment on list it inserts below the list **Desired behavior after PR is merged:** Now we can insert an appointment on list where cursor is. Task-2859691 Forward-Port-Of: odoo/enterprise#31879 Forward-Port-Of: odoo/enterprise#31617

**Current behavior before PR:**

When we try to insert an appointment on list it inserts below the list

**Desired behavior after PR is merged:**

Now we can insert an appointment on list where cursor is.

Task-2859691

Forward-Port-Of: odoo/enterprise#31879
Forward-Port-Of: odoo/enterprise#31617

Owl 2.0.3 properly escapes backslashes when generating block strings [1]. As a consequence, the non breakable spaces used in the legacy grid views now get escaped and are displayed as text. This commit ensures they're correctly evaluated as html. [1] https://github.com/odoo/owl/commit/530c2f9e4c9757c457fcc0a8b46ed914664c46e3 Forward-Port-Of: odoo/enterprise#35818 Forward-Port-Of: odoo/enterprise#35770

Owl 2.0.3 properly escapes backslashes when generating block strings [1]. As a consequence, the non breakable spaces used in the legacy grid views now get escaped and are displayed as text. This commit ensures they're correctly evaluated as html.

[1] https://github.com/odoo/owl/commit/530c2f9e4c9757c457fcc0a8b46ed914664c46e3

Forward-Port-Of: odoo/enterprise#35818
Forward-Port-Of: odoo/enterprise#35770

SUNAT Resolution 000123-2022, which came into force on 1 December 2022, provides a new framework for the filing of 'Guías de Remision' ('delivery guides') by companies. Any company that transfers goods (e.g. for a sale or from one location to another) must file a 'Guía Remitente'. In addition, there is a specialized regime for carriers (companies specialized in the transport of goods) which must file a 'Guía Transportista'. After filing, SUNAT provides a confirmation that includes a QR co

SUNAT Resolution 000123-2022, which came into force on 1 December 2022, provides a new framework for the filing of 'Guías de Remision' ('delivery guides') by companies.

Any company that transfers goods (e.g. for a sale or from one location to another) must file a 'Guía Remitente'.
In addition, there is a specialized regime for carriers (companies specialized in the transport of goods) which must file a 'Guía Transportista'.

After filing, SUNAT provides a confirmation that includes a QR code that must be presented by the driver if stopped by the authorities.

For creating delivery guides, SUNAT provides an online portal and a REST API. The REST API has three endpoints: one for requesting an authentication token, one for filing a delivery guide, and one for retrieving the confirmation.

This module implements the filing of 'Guía Remitente' via the REST API, and the retrieval of the confirmation including the QR code.

Implementation notes:
- We reused the existing module l10n_pe_edi_stock as much as possible. The old module is no longer in use since the old API was deprecated. We plan to merge the two in master.
- Often, the confirmation is not yet ready when we attempt to retrieve it. We catch that error code; in that case, the 'Retry' button attempts to re-retrieve the confirmation.
- If the filing/confirmation process fails, the 'Retry' button will file a new delivery guide with a new document number.
- Several new fields have been added, including:
  - credentials (the credentials for the REST API are different from those for the invoice EDI);
  - ID / authorization number fields for the company, the vehicle and the transport operator;
  - 'tariff fraction code' field on products, which needs to be specified if the product is a normalized product; and
  - Related Document type/number fields on the picking, to reference a supporting document for the transfer (e.g. invoice or authorization)

Task: 3068389

Forward-Port-Of: odoo/enterprise#35228
Forward-Port-Of: odoo/enterprise#34648