The message shown when an employee has no linked contact has been updated to explain the real requirement. This helps users understand that a valid associated contact is needed to use the Documents app from an employee record.

In order to use the Documents app from Employee, you need a valid associated contact. However, the error message when no contact exists was outdated and showed an irrelevant message.

This commit updates the error message to indicate that a contact is needed to use the Documents app from the Employee.

task-4684139

Point of Sale orders now include a clearer indicator to distinguish refunds from regular sales. This helps local electronic invoicing and settlement processes handle refund orders more reliably and with less ambiguity.

Add is_refund field in pos_order model to differentiate easily between
refund and normal orders

taskId: 4589361

The Sign app now adapts avatar cards to show when someone is on leave, helping users better understand signer availability. This improves coordination around document signing without changing the core signing flow.

Manually merge together PR to avoid conflicts.

Enterprise counter-part.

task-4653722

Community: https://github.com/odoo/odoo/pull/207009
Upgrade: https://github.com/odoo/upgrade/pull/7595

Taken from:
- https://github.com/odoo/enterprise/pull/82159

The Sign app’s enterprise test coverage was adjusted to align with a related change in the shared Odoo platform around avatar cards. This helps keep automated validation consistent and reduces the risk of regressions without changing day-to-day user workflows.

This commit adapts enterprise test to the community PR.

Community: https://github.com/odoo/odoo/pull/202702

task-4653722

The partner commission process now uses a newer progress-tracking approach when confirming purchase orders in the background. This keeps the system aligned with future platform updates while preserving the existing business workflow.

Rewrite the `_cron_confirm_purchase_orders` to use the new `_commit_progress` method.

This is because we would like to deprecate `_notify_progress` in the future.

The Swiss payroll module display name was updated to distinguish the ELM Transmission version from another similarly named module. This helps users identify the correct payroll accounting option more easily and reduces confusion in module lists.

- changed `l10n_ch_hr_payroll_elm_transmission_account`'s display name from "Switzerland - Payroll with Accounting" to
"Switzerland - Payroll with Accounting (ELM Transmission)" because duplicated.

Task-4717615

The Indian payroll demo data now includes a company bank account. This makes sample payroll scenarios more complete and easier to evaluate during demonstrations or testing.

Add demo bank account for the Indian company.

task-4668323

The VoIP call screens now correctly recognize when an incoming caller is already saved as a contact. This prevents users from seeing the wrong action, such as an unnecessary “Add contact” button, and makes call handling clearer.

The incoming invitation interface didn't display contact button althought the caller is already in the contacts. Also, after accepting a call from a caller that is in the contact, a button "Add contact" was dispalyed. This happened because the template was trying to retrieve a `contact` variable but there was not getter implemented for this variable.

This restores a previous fix that makes VoIP testing more reliable by controlling timers and waiting for background notifications. It helps prevent false test failures during development, supporting more dependable VoIP updates without changing user-facing behavior.

Restore b9853be51a16d800b9b131a8c59c6c92a22c9552, inadvertently reverted during refactoring.

The payroll payment advice wizard now lists only the current company's bank accounts in the Company Bank Account field. This prevents employee bank accounts from appearing there and helps payroll users select the correct account for payment advice reports.

Before this commit 'Company Bank Account' on the payment advice report wizard displayed the employee's bank account

Now, it will only show company bank accounts.

task-4642193

Subscription discount notes were missing from the customer portal view after a recent change to how upsell discount lines are handled. This fix ensures customers can see the relevant discount note information on their subscription page.

Since https://github.com/odoo/enterprise/pull/73438 sale.order.line with display_type=='subscription_discount' are used to easily update the line name when the upsell period is updated.

The portal template was not updated. As a result, the line was not displayed on the portal view of subscription.

taskid: 4690494

This work removes a menu entry from the web client configuration. It likely simplifies the user interface or eliminates an obsolete navigation option, with limited business impact based on the available details.

According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it: >3.º Principios contables La contabilidad de la empresa y, en especial, el registro y la valoración de los elementos de las cuentas anuales, se desarrollarán aplicando obligatoriamente los principios contables que se indican a continuación: > >1. Empresa en funcionamiento. Se considerará, salvo prueba en contrario, que la gestión de la empresa

According to [last update from PGCE](https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221) and the accounting standards inside it:

>3.º Principios contables
La contabilidad de la empresa y, en especial, el registro y la valoración de los elementos de las cuentas anuales, se desarrollarán aplicando obligatoriamente los principios contables que se indican a continuación:
>
>1. Empresa en funcionamiento. Se considerará, salvo prueba en contrario, que la gestión de la empresa continuará en un futuro previsible, por lo que la aplicación de los principios y criterios contables no tiene el propósito de determinar el valor del patrimonio neto a efectos de su transmisión global o parcial, ni el importe resultante en caso de liquidación.
>
>En aquellos casos en que no resulte de aplicación este principio, en los términos que se determinen en las normas de desarrollo de este Plan General de Contabilidad, la empresa aplicará las normas de valoración que resulten más adecuadas para reflejar la imagen fiel de las operaciones tendentes a realizar el activo, cancelar las deudas y, en su caso, repartir el patrimonio neto resultante, debiendo suministrar en la memoria de las cuentas anuales toda la información significativa sobre los criterios aplicados.
>
>2. Devengo. Los efectos de las transacciones o hechos económicos se registrarán cuando ocurran, imputándose al ejercicio al que las cuentas anuales se refieran, los gastos y los ingresos que afecten al mismo, con independencia de la fecha de su pago o de su cobro.
>
>3. Uniformidad. Adoptado un criterio dentro de las alternativas que, en su caso, se permitan, deberá mantenerse en el tiempo y aplicarse de manera uniforme para transacciones, otros eventos y condiciones que sean similares, en tanto no se alteren los supuestos que motivaron su elección. De alterarse estos supuestos podrá modificarse el criterio adoptado en su día; en tal caso, estas circunstancias se harán constar en la memoria, indicando la incidencia cuantitativa y cualitativa de la variación sobre las cuentas anuales.
>
> 4. Prudencia. Se deberá ser prudente en las estimaciones y valoraciones a realizar en condiciones de incertidumbre. La prudencia no justifica que la valoración de los elementos patrimoniales no responda a la imagen fiel que deben reflejar las cuentas anuales.
> 
> Asimismo, sin perjuicio de lo dispuesto en el artículo 38 bis del Código de Comercio, únicamente se contabilizarán los beneficios obtenidos hasta la fecha de cierre del ejercicio. Por el contrario, se deberán tener en cuenta todos los riesgos, con origen en el ejercicio o en otro anterior, tan pronto sean conocidos, incluso si sólo se conocieran entre la fecha de cierre de las cuentas anuales y la fecha en que éstas se formulen. En tales casos se dará cumplida información en la memoria, sin perjuicio de su reflejo, cuando se haya generado un pasivo y un gasto, en otros documentos integrantes de las cuentas anuales. Excepcionalmente, si los riesgos se conocieran entre la formulación y antes de la aprobación de las cuentas anuales y afectaran de forma muy significativa a la imagen fiel, las cuentas anuales deberán ser reformuladas.
> 
> Deberán tenerse en cuenta las amortizaciones y correcciones de valor por deterioro de los activos, tanto si el ejercicio se salda con beneficio como con pérdida.
> 
> 5. No compensación. Salvo que una norma disponga de forma expresa lo contrario, no podrán compensarse las partidas del activo y del pasivo o las de gastos e ingresos, y se valorarán separadamente los elementos integrantes de las cuentas anuales.
> 
> 6. Importancia relativa. Se admitirá la no aplicación estricta de algunos de los principios y criterios contables cuando la importancia relativa en términos cuantitativos o cualitativos de la variación que tal hecho produzca sea escasamente significativa y, en consecuencia, no altere la expresión de la imagen fiel. Las partidas o importes cuya importancia relativa sea escasamente significativa podrán aparecer agrupados con otros de similar naturaleza o función.
> 
> En los casos de conflicto entre principios contables, deberá prevalecer el que mejor conduzca a que las cuentas anuales expresen la imagen fiel del patrimonio, de la situación financiera y de los resultados de la empresa.

For item 5, assets and liabilities, income and expenses shall not be offset, unless required or permitted by a standard.

Therefore, group 55 accounts should be presented:

- On the assets side if they have a debit balance.
- On the liabilities side if they have a credit balance.
- Without offsetting each other.

@moduon MT-9820

@chklop @jco-odoo @rafaelbn

Forward-Port-Of: odoo/enterprise#82976

Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group. https://runbot.odoo.com/odoo/error/163649 Forward-Port-Of: odoo/enterprise#83802

Most tests of the module need to create a sale order, which requires the `group_sale_salesman` at least. Set this group.

https://runbot.odoo.com/odoo/error/163649

Forward-Port-Of: odoo/enterprise#83802

Can't create a payment for an inactive currency. So activate the currency. https://runbot.odoo.com/odoo/error/161659 Forward-Port-Of: odoo/enterprise#83812

Can't create a payment for an inactive currency. So activate the currency.

https://runbot.odoo.com/odoo/error/161659

Forward-Port-Of: odoo/enterprise#83812

It's always useful to keep the original .coda or .xml (for SODA) file that we receive from CodaBox on the created entry. task-none Forward-Port-Of: odoo/enterprise#83643 Forward-Port-Of: odoo/enterprise#81612

It's always useful to keep the original .coda or .xml (for SODA) file that we receive from CodaBox on the created entry.

task-none

Forward-Port-Of: odoo/enterprise#83643
Forward-Port-Of: odoo/enterprise#81612

The is_invoice_cron flag was set at the start of the cron and only reset at the end. In addition, key processing steps (_process_invoices_to_send and _post_invoice_hook) were done after all subscriptions were processed. If the cron was interrupted, unprocessed subscriptions could be left with is_invoice_cron set to True indefinitely, blocking post-processing. This also caused the post-processing cron to accumulate a backlog of payments to handle. To fix this, subscription processing is now

The is_invoice_cron flag was set at the start of the cron and only reset at the end. In addition, key processing steps (_process_invoices_to_send and _post_invoice_hook) were done after all subscriptions were processed.

If the cron was interrupted, unprocessed subscriptions could be left with is_invoice_cron set to True indefinitely, blocking post-processing. This also caused the post-processing cron to accumulate a backlog of payments to handle.

To fix this, subscription processing is now atomic: the is_invoice_cron flag is set only when a subscription (or group) is being processed and cleared immediately afterward. The post-processing steps are also moved inside the processing loop.

This ensures that only a single group may be left flagged if interrupted, and the flag will be reset when the cron resumes.

Forward-Port-Of: odoo/enterprise#83180

### Steps to reproduce: - Create a task in Field Service - Navigate to the product's catalog through the smart button - Add some products to the SO - Filter with 'Added products' - Notice the quantity bar is not shown ### Cause: This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/pr

### Steps to reproduce:
	- Create a task in Field Service
	- Navigate to the product's catalog through the smart button
	- Add some products to the SO
	- Filter with 'Added products'
	- Notice the quantity bar is not shown

### Cause:
This is happening as when click on the product smart button we are passing the order_id in the context to get the order lines info

https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/static/src/components/product_catalog/kanban_model.js#L21-L26

but if we still didn't create an order for this task order_id will be false, so it won't have an order to fetch its data and will just add the default data where the quantity will be 0

https://github.com/odoo/enterprise/blob/6e7525e0e0c2858e028694e9227077b2275d88c5/industry_fsm_sale/models/sale_order.py#L45-L48

### Fix:
If we have a fsm_task we can fallback on its order_id if order_id is false.

opw-4712922

Forward-Port-Of: odoo/enterprise#83396

Currently, a traceback occurs when the user clicks critical path in tasks gantt. To reproduce this issue: 1) Install Project and add the `Use Task Dependencies` group to the current user 2) Open the list view of the project 3) Enable the `Task Dependencies` to any one project 4) Now remove all the start dates from the Planned Date for all tasks 5) Open the Gantt view of the tasks and add a task 6) Refresh the page, and click the `Get Critical Path` button Error:- ``` KeyErro

Currently, a traceback occurs when the user clicks critical path in tasks gantt.

To reproduce this issue:

1) Install Project and add the `Use Task Dependencies` group to the current user 
2) Open the list view of the project
3) Enable the `Task Dependencies` to any one project 
4) Now remove all the start dates from the Planned Date for all tasks 
5) Open the Gantt view of the tasks and add a task 
6) Refresh the page, and click the `Get Critical Path` button

Error:- 
```
KeyError: 24
```

https://github.com/odoo/enterprise/blob/c9a753fce85dfb09dc413831993e63c7736d258a/project_enterprise/models/project_task.py#L1544

From the above line, the traceback is occurring because the `path_last_task` will take the value from the sorted_tasks's first record. But we don't have any `planned_date_begin` in any task except the one we added in the Gantt view.

So the first task which is `path_last_task` will not execute further because of this, https://github.com/odoo/enterprise/blob/c9a753fce85dfb09dc413831993e63c7736d258a/project_enterprise/models/project_task.py#L1529-L1531

This leads to the above traceback when we compare the value of the `path_last_task` from the `total_time` with the current task. https://github.com/odoo/enterprise/blob/c9a753fce85dfb09dc413831993e63c7736d258a/project_enterprise/models/project_task.py#L1544

We can resolve this issue by taking the `path_last_task` if only the task contains `planned_date_begin`.

sentry-6327461743

Forward-Port-Of: odoo/enterprise#80195

The same test is used in multiple modules. Sometimes in the mx localization it was possible that the closing of the session would take a bit longer and the modal wasn't fully closed (though invisible). The modal step in the tour was added when it was planned to remove the 'in_modal' parameter in tour steps and is not really needed for the original purpose of the test. runbot-error: 163628 Forward-Port-Of: odoo/enterprise#83779

The same test is used in multiple modules. Sometimes in the mx localization it was possible that the closing of the session would take a bit longer and the modal wasn't fully closed (though invisible).

The modal step in the tour was added when it was planned to remove the 'in_modal' parameter in tour steps and is not really needed for the original purpose of the test.

runbot-error: 163628

Forward-Port-Of: odoo/enterprise#83779

In this PR we : -Allow manual input of source tax adjustments -Improve transmission error messages -Add missing translations -Reintroduce work information and skills tab Forward-Port-Of: odoo/enterprise#83730 Forward-Port-Of: odoo/enterprise#81754

In this PR we :
-Allow manual input of source tax adjustments
-Improve transmission error messages
-Add missing translations
-Reintroduce work information and skills tab

Forward-Port-Of: odoo/enterprise#83730
Forward-Port-Of: odoo/enterprise#81754

Prior to this commit, a utility function `parseUTCString` was being used to format the order's `date_order` property. However, two things have changed since then: 1. The function `parseUTCString` was removed in this `odoo` repo PR: https://github.com/odoo/odoo/pull/189879. 2. The order datetime is now being passed as a DateTime object instead of a UTC string, so there is no need to parse it anymore. As such, when we tried to call that function when printing an Italian receipt, we would get

Prior to this commit, a utility function `parseUTCString` was being used to format the order's `date_order` property. However, two things have changed since then:
1. The function `parseUTCString` was removed in this `odoo` repo PR: https://github.com/odoo/odoo/pull/189879.
2. The order datetime is now being passed as a DateTime object instead of a UTC string, so there is no need to parse it anymore.

As such, when we tried to call that function when printing an Italian receipt, we would get a client error and no receipt would be printed.

This commit removes the parsing code so that the formatting can be done directly on the order's `date_order` property.

opw-4712063

Forward-Port-Of: odoo/enterprise#83547

This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while. It seems like one of the tour teardown steps can cause the loadin

This error shows up in 18.2, possibly because by waiting more for browser responses #206271 made it more likely that this error would have the time to be sent back down the pipe (also might be a change in chatter impl which makes 18.2 more sensible). However it's likely a global issue: when the tour "click[s] on ticket", it does a full page navigation then triggers the async load of a chatter which can take a pretty long while.

It seems like one of the tour teardown steps can cause the loading of the chatter bundle to get cancelled, which is then raised as an exception. The error is triggered from `getBundle` while reading the response body, but it just wraps and forwards the error it gets, and swallowing all bundle errors is probably a bad idea...

https://runbot.odoo.com/odoo/error/134748

Forward-Port-Of: odoo/enterprise#83871

### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the i

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

Since c18a7d2dc36d33134c5bdb1569865bd554e04130, the rentable forecast for future dates ignores the `rented_qty_during_period` if the setting "Rental transfers" is enabled. This happens because that rented quantity during period is supposed to be absorbed by the stock forecast: https://github.com/odoo/enterprise/blob/8ea5f4f9a0a907c57844c6274688171193f6a904/sale_stock_renting/models/sale_order_line.py#L132-L134 
However, the stock forecast of the 'virtual_available' relies solely on deliveries and receipt happening prior to the start of the renting period. Therefore the rental orders that are planned to start during the renting period should still contribute to the
`rented_qty_during_period` in that use case.

opw-4552760

Forward-Port-Of: odoo/enterprise#83576
Forward-Port-Of: odoo/enterprise#82172

Increase the field of the rank directly in test instead of going through `_increase_rank` which increases the rank in postcommit. odoo/odoo#205528 Forward-Port-Of: odoo/enterprise#83272

Increase the field of the rank directly in test instead of going through `_increase_rank` which increases the rank in postcommit.

odoo/odoo#205528

Forward-Port-Of: odoo/enterprise#83272