This fixes mismatched internal identifiers for Luxembourg payroll rule parameters introduced across parallel updates. It helps ensure the same payroll configuration is consistently recognized across supported versions before deployment, avoiding the need for a later upgrade step.

In #57515
some parameter rules were added. It was master
version and landed in saas-17.2
We needed the same parameter rules in 17.0 and 17.1 Thus, we made another PR - #58163

Unfortunately, those two PRs were done somewhat
parallely and some of the xml ids don't match.

This commit fixes that. And as the #58163
has not been deployed yet, we will not need upgrade

When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported. Description of the issue/feature this PR addresses: Current behavior before PR: When importing an invoice from a Factur-X format a payment reference was imported from wrong field related to a buyer order referenced document. But when the invoice is exported to Factur-X the original payment reference is exported to a spec

When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported.

Description of the issue/feature this PR addresses:

Current behavior before PR:
When importing an invoice from a Factur-X format a payment reference was imported from wrong field related to a buyer order referenced document. But when the invoice is exported to Factur-X the original payment reference is exported to a specific field "PaymentReference" under "SupplyChainTradeTransaction" section.

Desired behavior after PR is merged:
The imported field is the same as exported.

I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/odoo#157811

The `stock.move:_action_done()` already reserve the next mto moves at validation. Calling the reservation method after the validation again may lead to unwanted results like calling `check_entire_pack()` and messed up the result_package_id on the stock move lines. Task : 3764822 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

The `stock.move:_action_done()` already reserve the next mto moves at
validation. Calling the reservation method after the validation again
may lead to unwanted results like calling `check_entire_pack()` and
messed up the result_package_id on the stock move lines.

Task : 3764822

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

Forward-Port-Of: odoo/odoo#161445
Forward-Port-Of: odoo/odoo#160337

`compare_list_price` wasn't updated when the user changed the website's currency. Now, it's converted to the website's currency. This change also makes the conversion of `price_extra` and `list_price` safer by fetching both the `from` currency and the `from` amount from the same record. opw-3845887 Forward-Port-Of: odoo/odoo#161428

`compare_list_price` wasn't updated when the user changed the website's currency. Now, it's converted to the website's currency.

This change also makes the conversion of `price_extra` and `list_price` safer by fetching both the `from` currency and the `from` amount from the same record.

opw-3845887

Forward-Port-Of: odoo/odoo#161428

Before this commit, when adding a new grid item in a grid by using the "Add Elements" option, if the page was scrolled such that the top of the grid was not visible, this new grid item may not always be visible. This is annoying as the user could add an element and not see where it appeared and would therefore need to look for it. This commit fixes this by making the page scroll to the added grid item if it is not fully visible. Steps to reproduce: - Drop the "Text-Image" snippet and enou

Before this commit, when adding a new grid item in a grid by using the "Add Elements" option, if the page was scrolled such that the top of the grid was not visible, this new grid item may not always be visible. This is annoying as the user could add an element and not see where it appeared and would therefore need to look for it.

This commit fixes this by making the page scroll to the added grid item if it is not fully visible.

Steps to reproduce:
- Drop the "Text-Image" snippet and enough snippets under it to have a scrollbar.
- Toggle the "Text-Image" snippet to grid mode.
- Scroll the page so the top of the grid is not visible.
- Add a new "Button" with the "Add Elements" option.
=> The button is not visible.

task-3616138

Forward-Port-Of: odoo/odoo#161159
Forward-Port-Of: odoo/odoo#158838

Current behavior: If you change the expected duration of a workorder, then move the workorder to another workcenter, the expected duration is recomputed to but the finish date is not adapted. This leads to an inconsistency in the gannt view. Visually it will look like the duration expected has not changed because the date are still the same. Fix: To fix this we make sure that the finish date is recomputed when the expected duration is modified. This way both date and expected duration are c

Current behavior:
If you change the expected duration of a workorder, then move the workorder to another workcenter, the expected duration is recomputed to but the finish date is not adapted. This leads to an inconsistency in the gannt view. Visually it will look like the duration expected has not changed because the date are still the same.

Fix:
To fix this we make sure that the finish date is recomputed when the expected duration is modified. This way both date and expected duration are consistent.

Steps to reproduce:
- Create a product with a BOM
- The BOM should have at least 1 operations with a duration of 1 hour linked to a workcenter
- Create a manufacturing order for this product, confirm and plan it
- Go to the planning by workcenter
- Change the duration of the workorder by sliding its finishing date
- At this point if you click on it the duration should have changed
- Move the workorder to another workcenter
- The duration has been recomputed, but the finish date is not adapted (You can click on the workorder to see the duration has changed)

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

Forward-Port-Of: odoo/odoo#158141

## Issue: - when creating an accrual plan based on attendance,the duration is not computed accurately when allocating. - the computation is not correct if you select a different start date in the allocation without emptying the field "Allocation" ## Steps To Reproduce: - In the time-off app create an accrual plan: where employee accrue 1h for every hour worked based on attendance. - In the attendance app create a new attendance for 8 hours. - add a new allocation to Mitchell Admin with

## Issue:
- when creating an accrual plan based on attendance,the duration is not computed accurately when allocating.
- the computation is not correct if you select a different start date in the allocation without emptying the field "Allocation"

## Steps To Reproduce:
- In the time-off app create an accrual plan:  where employee accrue 1h for every hour worked based on attendance.
- In the attendance app create a new attendance for 8 hours.
- add a new allocation to Mitchell Admin with the plan you created.
- Change the date on the validity period, new allocation is 8h.
- change the date again and notice the Allocation not computed correctly.

## Solution:
- In `_onchange_date_from` when simulating how many days an accrual plan would give from a certian `date_from` we don't reset `number_of_days` to 0. reseting it to 0 fixes the issue.

opw-3793961

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

Forward-Port-Of: odoo/odoo#160696

When editing the login page, most snippets are disabled by default and cannot be dropped because there is no place to drop them. However, if you enable the cookies bar, then all snippets are enabled even on the login page, because they can be dropped within the cookies bar. It then looks like a bug for the users who try to drop blocks on the main page and cannot. To avoid that, this commit also disables the snippets if the only spot available is within a cookies bar. opw-3829660 Forward-P

When editing the login page, most snippets are disabled by default and cannot be dropped because there is no place to drop them. However, if you enable the cookies bar, then all snippets are enabled even on the login page, because they can be dropped within the cookies bar. It then looks like a bug for the users who try to drop blocks on the main page and cannot.

To avoid that, this commit also disables the snippets if the only spot available is within a cookies bar.

opw-3829660

Forward-Port-Of: odoo/odoo#160880

Steps to reproduce: - Open the 'project.milestone' form view. Issue: - Excessive space exists between quantity and unit of measure in the 'project.milestone' form view, impacting the layout. Solution: - Reduce the space between elements to improve the layout and enhance the user experience. task: 3549267 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 t

Steps to reproduce:
- Open the 'project.milestone' form view.

Issue:
- Excessive space exists between quantity and unit of measure in the 'project.milestone' form view, impacting the layout.

Solution:
- Reduce the space between elements to improve the layout and enhance the user experience.

task: 3549267

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

Forward-Port-Of: odoo/odoo#139806

Currently, there is an access right problem concerning timesheet. The module mrp gives write access to portal user on analytic line, but it is not something we want for the project app. step to reproduce: - install hr_timesheet on a saas-16.3 db - go to project app, open office design - select any task, and add a subtask to it - go the the view form of the subtask - create a new timesheet for this subtask - go back to the view form of the parent task a button 'subtask timesheet' is now

Currently, there is an access right problem concerning timesheet. The module mrp gives write access to portal user on analytic line, but it is not something we want for the project app.

step to reproduce:
- install hr_timesheet on a saas-16.3 db
- go to project app, open office design
- select any task, and add a subtask to it
- go the the view form of the subtask
- create a new timesheet for this subtask
- go back to the view form of the parent task a button 'subtask timesheet' is now visible
- share the project in edit mode with a portal user
- connect with that portal user
- open the office design project
- go to the view form of the parent task and click on the button
- the user is redirected to a view tree with the timesheet of the subtask
this view tree is editable

Source of the problem:
in the mrp module, the access rights of the analytic line is overwritten to give write access to it to portal user.
Soluce:
We have to make the view in readonly mode for timesheet when the connected user is a portal one. Unfortunately, it is not 100% possible because setting the field to readonly still gives the user the opportunity to click on those fields (which triggers access errors). So we have to create new views and specifically open those views when the user is a portal one.

affected version: saas-16.3 - master
task - 3751315

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

Forward-Port-Of: odoo/odoo#160959
Forward-Port-Of: odoo/odoo#155768

Description of the issue/feature this PR addresses: Create an invoice with analytic_distribution. Go to account.move.line, select the line with analytic_distribution, click on action 'Move account' validate --> Issue the analytic_distribution is not reversed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160981 Forward-Port-Of: odoo/odoo#159751

Description of the issue/feature this PR addresses:
Create an invoice with analytic_distribution.
Go to account.move.line, select the line with analytic_distribution, click on action 'Move account' validate
--> Issue the analytic_distribution is not reversed




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

Forward-Port-Of: odoo/odoo#160981
Forward-Port-Of: odoo/odoo#159751

**Description of the issue/feature this PR addresses:** The logger show "Job done" before the flush. But if during the flush an error appear (sql constraint, validation error during computed field, ...), the log contain "Job done", but is not True. The time to compute the cron is not good because it doesn't contain the flush time (in some case can be very long). @Julien00859 @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-

**Description of the issue/feature this PR addresses:**
The logger show "Job done" before the flush. But if during the flush an error appear (sql constraint, validation error during computed field, ...), the log contain "Job done", but is not True.

The time to compute the cron is not good because it doesn't contain the flush time (in some case can be very long).

@Julien00859 @rco-odoo 


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

Forward-Port-Of: odoo/odoo#161204
Forward-Port-Of: odoo/odoo#160895

## Description Add indexes affecting queries related to `account.analytic.line`. Based on heuristics like domains in `search`/`read_group` that are not really selective, or being an inverse of One2many. Some of these searches are on code-paths that are frequent, like creation of an SO. The goal is to reduce the number of Seq.Scan or non-selective Index Scan. ## Reference task-3724844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-

## Description
Add indexes affecting queries related to `account.analytic.line`. Based on heuristics like domains in `search`/`read_group` that are not really selective, or being an inverse of One2many. Some of these searches are on code-paths that are frequent, like creation of an SO.
The goal is to reduce the number of Seq.Scan or non-selective Index Scan.

## Reference
task-3724844

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

Forward-Port-Of: odoo/odoo#160472

After odoo/odoo#154035 users were unable to upgrade resolves https://github.com/odoo/odoo/issues/160816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161274

After odoo/odoo#154035 users were unable to upgrade

resolves https://github.com/odoo/odoo/issues/160816



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

Forward-Port-Of: odoo/odoo#161274

Add missing indexes on stock.move and mrp.workorder to speed up search_read on mrp.production. That's mostly useful at the opening of the Shop Floor app. This turns Seq scans into Index scan, leading to an overall speedup. ENT PR: https://github.com/odoo/enterprise/pull/59998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160349

Add missing indexes on stock.move and mrp.workorder to speed up search_read on mrp.production. That's mostly useful at the opening of the Shop Floor app. This turns Seq scans into Index scan, leading to an overall speedup.

ENT PR: https://github.com/odoo/enterprise/pull/59998

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

Forward-Port-Of: odoo/odoo#160349

Only delivery carriers that can communicate with the outside should be deactivated. Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated. Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping

Only delivery carriers that can communicate with the outside should be deactivated. Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated. Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping methods without prejudice to the users in neutralized databases.

@moduon @yajo @Shide MT-5612

Description of the issue/feature this PR addresses:

Current behavior before PR:

Deactivated every delivery carriers.

Desired behavior after PR is merged:

Deactivated only delivery carriers with external provider.


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

Forward-Port-Of: odoo/odoo#160443

-Same behaviour as [1] we should use slug(job) instead of job.id 1: a2c6ddf8158bf40f13b5c5a8b89deb3d2ae8af6b 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 Forward-Port-Of: odoo/odoo#160809 Forward-Port-Of: odoo/odoo#160622

-Same behaviour as [1] we should use slug(job) instead of job.id

1: a2c6ddf8158bf40f13b5c5a8b89deb3d2ae8af6b

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

Forward-Port-Of: odoo/odoo#160809
Forward-Port-Of: odoo/odoo#160622

### Steps to reproduce: - Go to Accounting > Accounting > Actions > Lock Dates - Set a Tax Return Lock Date to a date of the previous month - Create and confirm vendor Bill with a taxed line of positive price - Go to Accounting > Reporting > Audit Reports > Journal Report - Hover over the Vendor Bills and click on "journal items" - Add the optional vehicle field to the record - Select your expense line and try to add a vehicle #### > Invalid Operation "You cannot modify the taxes rel

### Steps to reproduce:

- Go to Accounting > Accounting > Actions > Lock Dates
- Set a Tax Return Lock Date to a date of the previous month
- Create and confirm vendor Bill with a taxed line of positive price
- Go to Accounting > Reporting > Audit Reports > Journal Report
- Hover over the Vendor Bills and click on "journal items"
- Add the optional vehicle field to the record
- Select your expense line and try to add a vehicle

#### > Invalid Operation "You cannot modify the taxes related to a posted journal item..."

### Cause of the issue:

Modifying the "vehicle_id" of the account move line will trigger a call of the `_sync_dynamic_line` method in order to modify other account move line linked to the same account move:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move.py#L2285-L2287 During the call of this write method, the account move line that we did not directly modified will not be excluded:
https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move_line.py#L1571 as `..._field_will_change(line, vals,"vehicule_id")` will be `True`. The error will therefore be raised two lines later because a 'tax_id' is present in vals as a 'tax_id' was set on our related account move line.

### Expected behaviour:

Since the 'tax_id' present in vals is the same as the one already set on our account move line, we are not modifying the taxes related to a posted journal item and we should not raise the error.

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

Forward-Port-Of: odoo/odoo#159919

This PR fixes an issue about the search panel content being cut in some accounting interfaces. This is due to the fact that the searchpanel with a specific class would get an arbitrary width value in px. To avoid this issue, we set a `w-auto` to the searchpanel, allowing it to adapt its width to its content. task-3560617 | saas-16.4 | saas-16.4-accounting-searchpanel-width-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/ac479776-76f1-47

This PR fixes an issue about the search panel content being cut in some accounting interfaces. This is due to the fact that the searchpanel with a specific class would get an arbitrary width value in px.

To avoid this issue, we set a `w-auto` to the searchpanel, allowing it to adapt its width to its content.

task-3560617

| saas-16.4 | saas-16.4-accounting-searchpanel-width-chgo |
|--------|--------|
| <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/ac479776-76f1-471b-b20b-927abf2fef2f"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/a683f0fd-16b1-49a5-9621-315288c6d186"> |

Forward-Port-Of: odoo/odoo#143803

[FIX] web_editor: make the drag towards the bottom in grid mode smoother Since commit [1], we can now drag and drop an image by dragging it directly, and not only by the move handle. Commit [2] allowed the image to be dragged from anywhere and not only from the top middle. In grid mode, in order for the column to stay well inside the grid when dragging, its computed position was originally bound horizontally, to the left and the right of the row. With commit [2], it is now also bound verti

[FIX] web_editor: make the drag towards the bottom in grid mode smoother

Since commit [1], we can now drag and drop an image by dragging it directly, and not only by the move handle. Commit [2] allowed the image to be dragged from anywhere and not only from the top middle.

In grid mode, in order for the column to stay well inside the grid when dragging, its computed position was originally bound horizontally, to the left and the right of the row. With commit [2], it is now also bound vertically, to the top and the bottom of the row.

While it makes sense for the top, because we need to take into account from where we dragged the image, it should not have been the case for the bottom, as we need to overflow in order to add new rows. This resulted in the drag towards the bottom becoming jumpy, because it locks on the bottom of the grid until a new row is added, when the mouse pointer is down enough.

This commit removes this bottom bound, in order for the drag towards the bottom to be smooth again.

Steps to reproduce:
- Drop the "Text-Image" snippet and toggle the grid mode.
- Drag a column towards the bottom in order to add new rows. 
=> It is not smooth: it locks on the bottom of the grid.

[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9

task-3601336

---
[FIX] web_editor: fix dragging a column from the bottom in a grid

Since commit [1], we can now drag and drop an image column by dragging it directly, and not only by the move handle. Commit [2] allowed the image to be dragged from anywhere and not only from the top middle. However, since commit [2], it is really difficult to drag a column downwards in a grid, if the drag started from the bottom move handle or near the bottom of the column if it contains an image, because we easily get out of the dropzone.

Indeed, since the positioning of the column now takes into account the mouse position on the column where the drag started, the mouse cursor is therefore located under the column (or almost under in the second case). This is why it gets out of the dropzone before a new row could be added. For the second case, new rows can be added, but only if the drag is slow enough, which is not convenient.

This commit bounds the vertical position of the mouse when dragging, in order for it to always be considered inside the column, so it cannot escape the dropzone anymore. A safety margin of one grid row is considered, to not escape when dragging rapidly.

Steps to reproduce:
- Drop enough snippets to have a scrollbar or select the "Sidebar"
  header template.
- Drop a "Text-Image" snippet
  - at the top of the page if the header was changed at the previous step, or
  - at a place where the top of the snippet can be hidden with a scroll.
- Toggle it to grid mode.
- Start dragging any column with the bottom move handle or drag the image column by clicking near the bottom of the column.
- Go over the grid dropzone if the move handle is used.
- Drag towards the bottom of the grid.
=> The mouse easily gets out of the dropzone, making it impossible to add new rows and drag further down the grid.

[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9

task-3601336

Forward-Port-Of: odoo/odoo#144427

See https://github.com/odoo/odoo/pull/151989#issuecomment-2041952639 The test test_tz_legacy will fail if the taget does not exist on the operating system. This is breaking in some versions of the tz-data package. Don't make this test fail if the target is missing. Forward-Port-Of: odoo/odoo#160868

See https://github.com/odoo/odoo/pull/151989#issuecomment-2041952639

The test test_tz_legacy will fail if the taget does not exist on the operating system. 
This is breaking in some versions of the tz-data package. 

Don't make this test fail if the target is missing.

Forward-Port-Of: odoo/odoo#160868

Before this PR, the chatbot script would hang when redirected to a page where the chatbot is not enabled. When such a scenario occurs, we should restore the chatbot's state to where it stopped, and the script should continue. This PR fixes this issue. Forward-Port-Of: odoo/odoo#161121

Before this PR, the chatbot script would hang when redirected to a
page where the chatbot is not enabled.

When such a scenario occurs, we should restore the chatbot's state to
where it stopped, and the script should continue.

This PR fixes this issue.

Forward-Port-Of: odoo/odoo#161121

Steps to reproduce the bug: - Install e-commerce. - Open a product page in edit mode. - Click on the "product.description_ecommerce" field. - Bug: an infinite loop starts. The "selectionchange" event is triggered in an endless loop, causing various issues such as the page freezing after a while. This issue was introduced by this commit [1]. Since this other commit [2], when a selection itself is the main container of the editable area, we replace this selection to only include the

Steps to reproduce the bug:

- Install e-commerce.
- Open a product page in edit mode.
- Click on the "product.description_ecommerce" field.
- Bug: an infinite loop starts. The "selectionchange" event is triggered in an endless loop, causing various issues such as the page freezing after a while.

This issue was introduced by this commit [1].

Since this other commit [2], when a selection itself is the main
container of the editable area, we replace this selection to only
include the content of it. With commit [1], this has been modified to
take into account "oe_structure" and "[contenteditable]" elements. As
these elements can be empty, clicking on them would reselect them,
creating an endless loop since we'd never leave the condition that
replaces the selection.

[1]: https://github.com/odoo/odoo/commit/e93fa23c29421ffe8917d9650330585d6dad210f
[2]: https://github.com/odoo/odoo/commit/10c5a16cd44b8d8e54082df90166f2309dfa788d

task-3830033

Forward-Port-Of: odoo/odoo#160535

Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date. Now journal entries will match the date of the expense when it is an expense paid by company. Signed, Logan Staelens lost@odoo.com https://github.com/lost-odoo Forward-Port-Of: odoo/odoo#160990 Forward-Port-Of: odoo/odoo#159083

Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date.

Now journal entries will match the date of the expense when it is an expense paid by company.

Signed,

Logan Staelens lost@odoo.com https://github.com/lost-odoo

Forward-Port-Of: odoo/odoo#160990
Forward-Port-Of: odoo/odoo#159083

Before ====== In E-invoice Value is pass as other values After ==== No RC value is pass to the E-invoice because not required to pass RC value. 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 Forward-Port-Of: odoo/odoo#161125

Before
======
In E-invoice Value is pass as other values

After
====
No RC value is pass to the E-invoice because not required to pass RC value.

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

Forward-Port-Of: odoo/odoo#161125

Add support for the Malaysian Peppol PINT specialization, allowing to generate the related XML file. This also adds a few additional features that are in the specifications: - SST registration number, needed in the xml and on the invoice. - TTx registration number, needed on the invoice. Both numbers are optional, but if the business is registered in any of them they are required to display these on the invoices and they are required to enforce some rules. (cannot send taxes that are n

Add support for the Malaysian Peppol PINT specialization, allowing to generate the related XML file.

This also adds a few additional features that are in the specifications:

- SST registration number, needed in the xml and on the invoice.
- TTx registration number, needed on the invoice.

Both numbers are optional, but if the business is registered in any of them they are required to display these on the invoices and they are required to enforce some rules. (cannot send taxes that are not 0% "Out of scope" if not registered with SST, ..)

Task id # 3647922

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

Forward-Port-Of: odoo/odoo#159407

Configure an email alias for the journal 'Vendor Bills' Send to the mail alias two pdf bills Issue: Only 1 record is created with the 2 bills as attachment The system should split the bills into separate records, but this does not occur: - after the first bill is processed the current move extract_state is 'waiting_extraction' - when the system check whether to extract data from the second document the result is negative as it check the state of the first document Enterprise PR:

Configure an email alias for the journal 'Vendor Bills'
Send to the mail alias two pdf bills

Issue: Only 1 record is created with the 2 bills as attachment
The system should split the bills into separate records, but this does
not occur:
- after the first bill is processed the current move extract_state is
  'waiting_extraction'
- when the system check whether to extract data from the second document the
  result is negative as it check the state of the first document

Enterprise PR: https://github.com/odoo/enterprise/pull/60168

opw-3822262

Forward-Port-Of: odoo/odoo#160983

Before this commit, users could not disable the Terms and Conditions display on the product page from the Customize tab of the web editor. To remove it from the product page, the only workaround was to remove the text in that div. Now, a button will be available in the Customize tab of the web editor to quickly show or hide the Terms and Conditions. Forward-Port-Of: odoo/odoo#161230

Before this commit, users could not disable the Terms and Conditions display on the product page from the Customize tab of the web editor. To remove it from the product page, the only workaround was to remove the text in that div.

Now, a button will be available in the Customize tab of the web editor to quickly show or hide the Terms and Conditions.

Forward-Port-Of: odoo/odoo#161230

**[FIX] round_per_line: Fix payment CFDI rounding issues** - 'base' * 'tasa_o_cuota' must give 'importe' with 0.01 rounding error allowed. Suppose an invoice of 5 * 0.47 with 16% tax. Each line gives a tax amount of 0.08 so 0.40 for the whole invoice. However, 5 * 0.47 = 2.35 and 2.35 * 0.16 = 0.38 so the constraint is failing. - 'base' + 'importe' must be exactly equal to the part that is actually paid. Using the same example, we need to report 2.35 + 0.40 = 2.75 **[FIX] round_globall

**[FIX] round_per_line: Fix payment CFDI rounding issues**

- 'base' * 'tasa_o_cuota' must give 'importe' with 0.01 rounding error allowed.
Suppose an invoice of 5 * 0.47 with 16% tax. Each line gives a tax amount of 0.08 so 0.40 for the whole invoice.
However, 5 * 0.47 = 2.35 and 2.35 * 0.16 = 0.38 so the constraint is failing.
- 'base' + 'importe' must be exactly equal to the part that is actually paid.
Using the same example, we need to report 2.35 + 0.40 = 2.75

**[FIX] round_globally: Manage round globally**

Before, the results given in case of round_globally was the same as round_per_line.
Suppose an invoice of 5 * 0.47 with 16% tax. We were sending a tax detail of
0.47 * 0.16 ~= 0.08 for each line, so 0.40 for the whole invoice.
However, in case of round globally, the total tax is 5 * 0.47 * 0.16 ~= 0.38.
The invoice was incorrectly reported as an invoice of 2.75 instead of 2.73.

To fix that, the base/tax amount per line are now given using 6 decimals.

**[FIX] Deterministic invoices's order in payment CFDI**

Before generating a payment CFDI, make sure the invoices are sorted in order to
avoid a not deterministic xml.

**[FIX] Rounding of TipoCambio**

On the xml, the rate to switch from the invoice to payment rate is rounded to 6 decimals.
By consistency, we need to use the same number of decimals during the computation to avoid
the xml to be rejected. For example:

With an MX company setup
USD Exchange rate:
  - Yesterday 17.187
  - Today 17.0357
Create an invoice with:
  - date: yesterday, quantity: 200, unit price: 7.34 USD, tax: 16%
Confirm and Send the invoice
Register the payment with today date
Open the payment and force cfdi
SAT Validation will return an error:
'''
Code : CRP20204 Message : El valor del campo TotalTrasladosBaseIVA16
no es igual al redondeo de la suma del resultado de multiplicar cada
uno de los importes de los atributos BaseP de los impuestos trasladados
registrados en el elemento TrasladoP donde los atributos contengan en
ImpuestoP el valor IVA, en TipoFactorP el valor Tasa y en TasaOCuotaP
el valor 0.160000, por el valor registrado en el atributo TipoCambioP
de cada nodo Pago.
'''

opw-3775099

**[FIX] Rounding of TotalTrasladosBaseIVA16**

- Have an MX company setup
- USD Exchange rate:
  - Yesterday 16.9912
  - Today 17.068
- Create two invoices as follows:
  1) date yesterday, qty 68.25, unit price 68 USD, tax 16%, total 5383.56 USD
  2) date yesterday, qty 24.00, unit price 68 USD, tax 16%, total 1893.12 USD
Confirm and Send the two invoices
In invoices list view, select both and register payment
Select 'Group Payments'
Open one of the invoices, and press "Update Payments"
In CFDI Tab Force cfdi for the payment

Issue: Cfdi validation return an error
"""
Code : CRP20204 Message : El valor del campo TotalTrasladosBaseIVA16 no es igual
al redondeo de la suma del resultado de multiplicar cada uno de los importes de
los atributos BaseP de los impuestos trasladados registrados en el elemento TrasladoP
donde los atributos contengan en ImpuestoP el valor IVA, en TipoFactorP el valor
Tasa y en TasaOCuotaP el valor 0.160000, por el valor registrado en el atributo
TipoCambioP de cada nodo Pago.
"""

opw-3775099

Forward-Port-Of: odoo/enterprise#60532
Forward-Port-Of: odoo/enterprise#60025

Currently, in the timesheet leaderboard timer grid, kanban and list views, a search_read is done on hr.employee to retrieve the billable_time_target field. However, this field is exclusive to users that have the hr.group_hr_user, and so if a user without that group tries to open any of these views, a traceback is raised. To fix this, a method was added to retrieve the billable time targets using a sudo(). Forward-Port-Of: odoo/enterprise#60463

Currently, in the timesheet leaderboard timer grid, kanban and list views, a search_read is done on hr.employee to retrieve the billable_time_target field. However, this field is exclusive to users that have the hr.group_hr_user, and so if a user without that group tries to open any of these views, a traceback is raised.

To fix this, a method was added to retrieve the billable time targets using a sudo().

Forward-Port-Of: odoo/enterprise#60463

Purpose ======= Fix the unnecessary horizontal and vertical scrollbars appearing in the inspector when a document name is too long. Specifications ============== In the inspector, when the value of the fields of type model (like the Journal Entry or Signature fields) is too long, the value is styled so that its width takes the max-width. However the field max-width is incorrectly computed. It is missing the table-sm class horizontal padding. The field is thus too big to fit in the ins

Purpose
=======
Fix the unnecessary horizontal and vertical scrollbars appearing in the
inspector when a document name is too long.

Specifications
==============
In the inspector, when the value of the fields of type model (like the Journal Entry
or Signature fields) is too long, the value is styled so that its width takes the max-width.
However the field max-width is incorrectly computed. It is missing the table-sm class
horizontal padding. The field is thus too big to fit in the inspector and scrollbars appear.

Taking into account the table-sm paddings while computing the field value max-width.
As the field label left padding is set to 0, the table-sm padding is multiplied by 3
(right padding of label, left and right padding of value).
Also adding the "overflow-hidden" class on the inspector so that scrollbars never appear.

Task-3829716

Forward-Port-Of: odoo/enterprise#60430
Forward-Port-Of: odoo/enterprise#59652

At the moment, the Unaffected Earnings and Current Year Earnings lines are expressed using domains. We change them to use cross-report formulas to the Profit & Loss. This ensures that the Balance Sheet is balanced. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59132

At the moment, the Unaffected Earnings and Current Year Earnings lines are expressed using domains. We change them to use cross-report formulas to the Profit & Loss.

This ensures that the Balance Sheet is balanced.

taskid: 3060790

Forward-Port-Of: odoo/enterprise#59132

The declining method, even though its name doesn't tell it explicitly, implies a comparison with the output of a linear depreciation of the depreciable value on the remaining duration of the asset's lifecycle. task-3734735 Forward-Port-Of: odoo/enterprise#60352 Forward-Port-Of: odoo/enterprise#56601

The declining method, even though its name doesn't tell it explicitly,
implies a comparison with the output of a linear depreciation of the
depreciable value on the remaining duration of the asset's lifecycle.

task-3734735

Forward-Port-Of: odoo/enterprise#60352
Forward-Port-Of: odoo/enterprise#56601

This commit fixes an issue where readonly users are able to access and restore an old version of an article via the history dialog but it didn't affect the DB as no write could be done by this user. The change was only visible and functionnally didn't change the body field. Now when a user accesses to an article where he can only read, the history dialog button is hidden. task-3836201 Forward-Port-Of: odoo/enterprise#59609

This commit fixes an issue where readonly users are able to access and restore
an old version of an article via the history dialog but it didn't affect the DB
as no write could be done by this user.
The change was only visible and functionnally didn't change the body field.

Now when a user accesses to an article where he can only read, the history
dialog button is hidden.

task-3836201

Forward-Port-Of: odoo/enterprise#59609

Basically, the following fields are only defined in private employee, and not on public employee. Thus we need to put group on them Forward-Port-Of: odoo/enterprise#60396

Basically, the following fields are only defined in private employee, and not on public employee. Thus we need to put group on them

Forward-Port-Of: odoo/enterprise#60396

Add missing indexes on quality_check. This speeds up search_read on mrp.production when the quality/quality_mrp modules are installed. It's mostly useful at the opening of the Shop Floor App to turn Seq Scans into Index Scans. COM PR: https://github.com/odoo/odoo/pull/160349 Forward-Port-Of: odoo/enterprise#59998

Add missing indexes on quality_check. This speeds up search_read on mrp.production when the quality/quality_mrp modules are installed. It's mostly useful at the opening of the Shop Floor App to turn Seq Scans into Index Scans.

COM PR: https://github.com/odoo/odoo/pull/160349

Forward-Port-Of: odoo/enterprise#59998

The tax brackets have been updated since 01-01-2024 https://impotsdirects.public.lu/dam-assets/fr/baremes/baremes-impot-20240101-fr.pdf https://impotsdirects.public.lu/fr/baremes.html#Ex Add new parameter values to reflect the change. task-3748852 Forward-Port-Of: odoo/enterprise#58163

The tax brackets have been updated since 01-01-2024

https://impotsdirects.public.lu/dam-assets/fr/baremes/baremes-impot-20240101-fr.pdf https://impotsdirects.public.lu/fr/baremes.html#Ex

Add new parameter values to reflect the change.

task-3748852

Forward-Port-Of: odoo/enterprise#58163

This commit adds some of the missing information in the commercial invoice for international shipments in `delivery_ups` and `delivery_ups_rest` modules. opw-3668875 Forward-Port-Of: odoo/enterprise#60043 Forward-Port-Of: odoo/enterprise#58861

This commit adds some of the missing information in the commercial invoice for international shipments in `delivery_ups` and `delivery_ups_rest` modules.

opw-3668875

Forward-Port-Of: odoo/enterprise#60043
Forward-Port-Of: odoo/enterprise#58861

The module uses the field `stock_picking.carrier_tracking_url`, defined in module `stock_delivery`, which is not listed as dependency. Although it is auto-installed, if it gets uninstalled before `whatsapp_delivery` is installed, it will trigger an error as the field is missing. Steps to reproduce: - On a fresh 17.0 db, install `stock` and `delivery`, `stock_delivery` will be auto-installed. - Uninstall `stock_delivery`. - Install `whatsapp_delivery` or just `whatsapp`. Forward-Port-

The module uses the field `stock_picking.carrier_tracking_url`, defined in module `stock_delivery`, which is not listed as dependency.

Although it is auto-installed, if it gets uninstalled before `whatsapp_delivery` is installed, it will trigger an error as the field is missing.

Steps to reproduce:

- On a fresh 17.0 db, install `stock` and `delivery`, `stock_delivery` will be auto-installed.
- Uninstall `stock_delivery`.
- Install `whatsapp_delivery` or just `whatsapp`.

Forward-Port-Of: odoo/enterprise#60322

Forward-Port-Of: odoo/enterprise#60316 Forward-Port-Of: odoo/enterprise#60166

Forward-Port-Of: odoo/enterprise#60316
Forward-Port-Of: odoo/enterprise#60166

Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving the user any change to get to the workspace view where we are able to upload new file if allowed or see the rest of documents in the folder. Steps to reproduce: 1. Install Documents and go to Spreadsheet. 2. Create or Upload a new spreadsheet. 3. Click next to the upload button and in the dro

Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving the user any change to get to the workspace view where we are able to upload new file if allowed or see the rest of documents in the folder.

Steps to reproduce:

1. Install Documents and go to Spreadsheet.
2. Create or Upload a new spreadsheet.
3. Click next to the upload button and in the dropdown, select share to open the share popup.
4. Inside here just select the allow to download and upload documents and we click on share again.
5. Open the link in a new tab and we will see only the document already opened, without any posibility of see the entire folder or uploading a new document.

Solution: Inside the `share_portal` of `SpreadsheetShareRoute` when checking for a single document, we also need to check if we are working with a selection, or if it's the folder what we want to share.

opw-3688409

Forward-Port-Of: odoo/enterprise#57394

Fix the document name which was renamed to "(remaining pages.pdf" when exiting the split tool by gathering in one page. Missing the initial name and missing the closing parenthesis. The document name by gathering in one page is now structured as: "name (remaining pages).pdf" Technical point: Using sprintf so that users will have an entry with %s in the translation file allowing them to choose the file name position. related: https://github.com/odoo/enterprise/pull/40454 Task-384

Fix the document name which was renamed to "(remaining pages.pdf"
when exiting the split tool by gathering in one page.
Missing the initial name and missing the closing parenthesis.

The document name by gathering in one page is now structured as:
"name (remaining pages).pdf"

Technical point:
Using sprintf so that users will have an entry with %s in the
translation file allowing them to choose the file name position.

related: https://github.com/odoo/enterprise/pull/40454

Task-3847395

Forward-Port-Of: odoo/enterprise#60414
Forward-Port-Of: odoo/enterprise#59979

Configure an email alias for the jounrnal 'Vendor Bills' Send to the mail alias two pdf bills Issue: Only 1 record is created with the 2 bills as attachment The system should split the bills into separate records, but this does not occur: - after the first bill is processed the current move extract_state is 'waiting_extraction' - when the system check whether to extract data from the second document the result is negative, while it should be positive when new_document is true, i

Configure an email alias for the jounrnal 'Vendor Bills'
Send to the mail alias two pdf bills

Issue: Only 1 record is created with the 2 bills as attachment
The system should split the bills into separate records, but this does
not occur:
- after the first bill is processed the current move extract_state is
  'waiting_extraction'
- when the system check whether to extract data from the second document the
  result is negative, while it should be positive when new_document is
  true, in order to create a separate move.

Related: https://github.com/odoo/odoo/pull/160983

opw-3822262

Forward-Port-Of: odoo/enterprise#60168