Problem: en_US data is loaded while the user uses another language Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Change the language (e.g. to french) - Go to POS -> Products -> Discount & Loyalty - Create a new Loyalty Card - In Rewards, set a discount of 20 $ on order and save - Go to the shop and select a partner and a product (price must be expensive enough for the loyalty card to be applicable) - Click on "Reward", the earlier created reward is there

Problem:
en_US data is loaded while the user uses another language

Steps to reproduce:
- Install "point_of_sale" app and "pos_loyalty" module
- Change the language (e.g. to french)
- Go to POS -> Products -> Discount & Loyalty
- Create a new Loyalty Card
- In Rewards, set a discount of 20 $ on order and save
- Go to the shop and select a partner and a product (price must be expensive enough for the loyalty card to be applicable)
- Click on "Reward", the earlier created reward is there
- Go back to the form of the loyalty card and change the value and save
- Go back to the shop
- Click on "Reward" and the name of the loyalty card is still the same as before while it should be for the new price

Cause:
When loading the data, the record environment have language set to None so by default it is loaded in en_US which didn't recompute its value after the modification of the price.

opw-3987961


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

Forward-Port-Of: odoo/odoo#171950
Forward-Port-Of: odoo/odoo#171049

This PR refactors the process of finding candidates (SVL) in the FIFO run of the stock account. With the current Odoo standard behavior, we can't update the domain to find candidates or adjust the candidates' values, and we have to override `def _run_fifo.` This PR addresses this issue. @qrtl QT4657 Forward-Port-Of: odoo/odoo#170470

This PR refactors the process of finding candidates (SVL) in the FIFO run of the stock account. With the current Odoo standard behavior, we can't update the domain to find candidates or adjust the candidates' values, and we have to override `def _run_fifo.` This PR addresses this issue.

@qrtl QT4657

Forward-Port-Of: odoo/odoo#170470

STEP TO REPRODUCE: ================== 1- Go on Time off Application 2- Select First Approval filter You will see two records: one with "second approval" status and one with "to approve" status. With this commit only leaves with "to approve status" will appears with this filter. task-4005045 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170910

STEP TO REPRODUCE:
==================

    1- Go on Time off Application
    2- Select First Approval filter

You will see two records: one with "second approval" status and one with "to approve" status.

With this commit only leaves with "to approve status" will appears with this filter.

task-4005045

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

Forward-Port-Of: odoo/odoo#170910

Previously, users were able to edit reward sale order lines. However, these edits were undone on confirming the SO, which was confusing. This fix makes the quantity, unit price, and taxes of such lines readonly to make it clear that they're not meant to be edited. opw-3971219 Forward-Port-Of: odoo/odoo#171269

Previously, users were able to edit reward sale order lines. However, these edits were undone on confirming the SO, which was confusing. This fix makes the quantity, unit price, and taxes of such lines readonly to make it clear that they're not meant to be edited.

opw-3971219

Forward-Port-Of: odoo/odoo#171269

Steps to reproduce: - Create a subcontracted bom for a product with flexible consumption (with warning) - Create a receipt for that product from the recorded subcontractor with more than 1 qty - Click on 'Record Component' and set one qty produced and more than expected qty to consume - Record Production and validate the warning - Do the same thing a second time Issue: While the first 'Record Component' prompts the warning for different consumption, the second attempt doesn't. This i

Steps to reproduce:
- Create a subcontracted bom for a product with flexible consumption (with warning)
- Create a receipt for that product from the recorded subcontractor with more than 1 qty
- Click on 'Record Component' and set one qty produced and more than expected qty to consume
- Record Production and validate the warning
- Do the same thing a second time

Issue:
While the first 'Record Component' prompts the warning for different consumption, the second attempt doesn't.

This is due to the context containing the 'skip_consumption' key from the first attempt being used to generate the new action for the remaining quantity to produce.

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

Forward-Port-Of: odoo/odoo#171957
Forward-Port-Of: odoo/odoo#171216

When the client side requests an update of message statuses for sent invoices that are "Pending reception" (`peppol_move_state == "processing"`), the IAP throws an error if message is still being processed on the server side. We get a `702` "Peppol Request Not Ready" error code from the server in that case. Currently, on the client side as long as we see an error, we update `peppol_move_state` to `error`, which prevents further status updates (we only check "processing" messages). We

When the client side requests an update of message statuses for
sent invoices that are "Pending reception" (`peppol_move_state == "processing"`),
the IAP throws an error if message is still being processed on the server side.
We get a `702` "Peppol Request Not Ready" error code from the server in that case.

Currently, on the client side as long as we see an error, we update
`peppol_move_state` to `error`, which prevents further status updates
(we only check "processing" messages).

We should not update the move state to error and just keep it as processing,
so that we will retry fetching the state on the next scheduled action run.

no task, customer feedback



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

Forward-Port-Of: odoo/odoo#171479

Another checksum flag was added in 4a578a58 but this flag is not supported by older versions of Docker. Forward-Port-Of: odoo/odoo#171879

Another checksum flag was added in 4a578a58 but this flag is not supported by older versions of Docker.

Forward-Port-Of: odoo/odoo#171879

When exporting non-grouped records we include archived records in results, this commits makes grouped results consiste with that, i.e. now also grouped records will include archived results [Reproduce] - Install crm - Go to: crm app - Switch to List view - Remove all filters - Use filter "Lost" - Group by "Stage" - Select all and Export -> BUG: exported xlsx file is empty Note: Above we have a specyfic case, to generalize that steps we can say, that whenever we filter with "Los

When exporting non-grouped records we include archived records in results, this commits makes grouped results consiste with that, i.e. now also grouped records will include archived results

[Reproduce]
- Install crm
- Go to: crm app
	- Switch to List view
	- Remove all filters
	- Use filter "Lost"
	- Group by "Stage"
	- Select all and Export -> BUG: exported xlsx file is empty

Note: Above we have a specyfic case, to generalize that steps we can say, that whenever we filter with "Lost" and use whatever "group by" then export is empty

opw-3901258

Forward-Port-Of: odoo/odoo#170349
Forward-Port-Of: odoo/odoo#166097

Currently, a traceback is occurring when the user clicks on the chat button while creating a new employee record. To reproduce this issue: 1) Install `employee` 2) Create a new `employee` record 3) Give the value for the related user in the `HR Setting` page 4) A chat button appears at the left side of the `employee name` 5) Click on the chat button, and a traceback occurs Error:- ``` TypeError: '<' not supported between instances of 'int' and 'NoneType' File "odoo/http.py",

Currently, a traceback is occurring when the user clicks on the chat button while creating a new employee record.

To reproduce this issue:

1) Install `employee`
2) Create a new `employee` record
3) Give the value for the related user in the `HR Setting` page 
4) A chat button appears at the left side of the `employee name` 
5) Click on the chat button, and a traceback occurs

Error:- 
```
TypeError: '<' not supported between instances of 'int' and 'NoneType'
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/mail/models/discuss/discuss_channel.py", line 973, in channel_get
    """, (tuple(partners_to), tuple(partners_to), sorted(list(partners_to)),))
```

When the related user value is given, the `chat` button is visible to the user before saving the record. 
But here in the `openChat` method, we used `props.record.resId`.
which is created after the employee record is created.

https://github.com/odoo/odoo/blob/a6c14effd3e38cf38966ae89675e8e54b54cf825/addons/hr/static/src/components/employee_chat/employee_chat.xml#L4-L11

It leads to the above traceback as `channel_get` calls with `partners_to` as `None` from the below line

https://github.com/odoo/odoo/blob/a6c14effd3e38cf38966ae89675e8e54b54cf825/addons/mail/static/src/core/common/thread_service.js#L555-L557

This commit will resolve this issue by making it visible to the user after the employee record is created.

Note:- An alternative solution can be at this line
https://github.com/odoo/odoo/blob/9f84ff581686f8e2198a0a88d19f7a52e27ccb53/addons/hr/static/src/thread_service_patch.js#L9
```
if (!person) {
            this.notificationService.add(
                _t("To open chat, please first save the record.."),
                { type: "info" }
            );
            return;
        }
```

sentry- 5501637214

Forward-Port-Of: odoo/odoo#171380

# Description Since upgrading Bootstrap a few months ago, the `nav-link-padding-x` and `nav-link-padding-y` classes now rely on CSS variables defined within the `nav` class. To ensure these variables are correctly applied, we need to wrap the `nav-item` in a nav class. This change fixes the missing padding issue for the sign-in button. Task: [4032574](https://www.odoo.com/odoo/project/2328/tasks/4032574?cids=2) --- I confirm I have signed the CLA and read the PR guidelines at

# Description

Since upgrading Bootstrap a few months ago, the `nav-link-padding-x` and `nav-link-padding-y` classes now rely on CSS variables defined within the `nav` class. To ensure these variables are correctly applied, we need to wrap the `nav-item` in a nav class.

This change fixes the missing padding issue for the sign-in button.

Task: [4032574](https://www.odoo.com/odoo/project/2328/tasks/4032574?cids=2)




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

Forward-Port-Of: odoo/odoo#171887

Commit [1] introduced a fix which selects the last button of the Vert. Alignment option when switching back from grid mode. However, commit [2] removed the XML's data-js attribute which linked the JS code to the option in 16.1, and this was not caught in commit [1]'s forward-ports. Therefore, the fix was no longer working in 16.1+. This commit restores the data-js attribute in JS for a stable fix, and in master, will add it back on the template. [1]: https://github.com/odoo/odoo/comm

Commit [1] introduced a fix which selects the last button of the Vert. Alignment option when switching back from grid mode.

However, commit [2] removed the XML's data-js attribute which linked the JS code to the option in 16.1, and this was not caught in commit [1]'s forward-ports.

Therefore, the fix was no longer working in 16.1+.

This commit restores the data-js attribute in JS for a stable fix, and in master, will add it back on the template.

[1]: https://github.com/odoo/odoo/commit/cdf0870e1f81a5ec5096ddd062cf699e98681880
[2]: https://github.com/odoo/odoo/commit/c6561929f339ac1451cc998b2d2b399253db0016

Related to task-3142615

Forward-Port-Of: odoo/odoo#170990

Before this commit, trying to log non-ascii characters from the IoT box would raise an error. The case primarily happens when a user has devices in their system that are named with special characters (e.g Chinese characters for printer names, accented French names, etc). After this commit, a device name containing non-ascii characters will be logged properly without triggering any tracebacks. REASON: It's the option that incurs the least amount of changes in the codebase. Furthermore, alt

Before this commit, trying to log non-ascii characters from the IoT box would raise an error.
The case primarily happens when a user has devices in their system that are named with special characters (e.g Chinese characters for printer names, accented French names, etc).

After this commit, a device name containing non-ascii characters will be logged properly without triggering any tracebacks.

REASON: It's the option that incurs the least amount of changes in the codebase. Furthermore, alternative options would lead to lots of bespoke code to cover all cases.
The proposed change is also the one that offers the greatest flexibility: clients can freely use their native language to name their devices.

OPW-4001252

Forward-Port-Of: odoo/odoo#171728

--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171167

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

Forward-Port-Of: odoo/odoo#171167

When the authorization of the payment expires. Happens when you do not capture manually tx in 7 days (by default). Stripe sends a webhook that payment is canceled which was not captured before this PR, hence the changes were not applied for the corresponding payment. With this PR the cancel webhook is captured and the corresponding payment is canceled odoo-side. opw-3957346 Forward-Port-Of: odoo/odoo#171061

When the authorization of the payment expires. Happens when you do not capture manually tx in 7 days (by default). Stripe sends a webhook that payment is canceled which was not captured before this PR, hence the changes were not applied for the corresponding payment.
With this PR the cancel webhook is captured and  the corresponding payment is canceled odoo-side.


opw-3957346

Forward-Port-Of: odoo/odoo#171061

**Current behavior before PR:** Templates were displayed in a compressed mode, similar to how they appear on small devices. **Desired behavior after PR is merged:** Templates are now displayed in a more expanded, desktop-like mode, providing a clearer and more accurate visual representation. **Task**-[3916601](https://www.odoo.com/odoo/my-tasks/3916601?cids=2) Forward-Port-Of: odoo/odoo#170126

**Current behavior before PR:**
Templates were displayed in a compressed mode, similar to how they appear on
small devices.

**Desired behavior after PR is merged:**
Templates are now displayed in a more expanded, desktop-like mode, providing
a clearer and more accurate visual representation.

**Task**-[3916601](https://www.odoo.com/odoo/my-tasks/3916601?cids=2)

Forward-Port-Of: odoo/odoo#170126

**Current behavior:** When importing a repair order record, if a picking_type_id is not supplied by the data source, the import will fail. **Expected behavior:** Fields with default values shouldn't be required during record creation. **Steps to reproduce:** 1. Create a .CSV with one column (e.g., `scheduled date`) and load it in the import record view in the Repair app 2. Map the CSV column to the repair model's date field 3. Click the test button to see the error (bad query)

**Current behavior:**
When importing a repair order record, if a picking_type_id is not supplied by the data source, the import will fail.

**Expected behavior:**
Fields with default values shouldn't be required during record creation.

**Steps to reproduce:**
1. Create a .CSV with one column (e.g., `scheduled date`) and load it in the import record view in the Repair app

2. Map the CSV column to the repair model's date field

3. Click the test button to see the error (bad query)

**Cause of the issue:**
If a `picking_type_id` is not supplied, we try to get the default field value via `default_get()`. However, it is called incorrectly (string argument vs. container), so the string is iterated over and each letter is treated as a field name (none of which, of course, exist in the model).

Later in the create sequence, we assume there is a `picking_type_id` value obtained from the `default_get()` call but it is not there. This (eventually) causes the invalid query.

**Fix:**
Correct the call to `default_get()`.

opw-3813273

Forward-Port-Of: odoo/odoo#171589

Previously, the down payment invoice used the account related to the product. The final invoice used the default computed account instead. This resulted in two different accounts being billed for the same client and the same sale. This commit makes the final invoice use the same account as its down payment. To verify: - Create a sale order with a product which have an income account different from default one - Create Downpayment => Invoice will have the income account of the product

Previously, the down payment invoice used the account related to the product.
The final invoice used the default computed account instead.
This resulted in two different accounts being billed for the same client and the same sale.

This commit makes the final invoice use the same account as its down payment.

To verify:
- Create a sale order with a product which have an income account different from default one
- Create Downpayment => Invoice will have the income account of the product
- Fully invoice the sale order => Line to deduce the payment will use the default account

[Ticket link](https://www.odoo.com/odoo/project.task/3887331)
opw-3887331

Forward-Port-Of: odoo/odoo#170783

**Current behavior:** Setting up a control point for a product by quantity with a failure stock location on manufacturing operations will never allow a manufactured product that fails the quality check to end up in the failure location. **Expected behavior:** A product created in a manufacturing order can fail a quality check and end up in the designated failure location in WH. **Steps to reproduce:** 1. Set up a quality point on some storable product on manufacturing operations with:

**Current behavior:**
Setting up a control point for a product by quantity with a failure stock location on manufacturing operations will never allow a manufactured product that fails the quality check to end up in the failure location.

**Expected behavior:**
A product created in a manufacturing order can fail a quality check and end up in the designated failure location in WH.

**Steps to reproduce:**
1. Set up a quality point on some storable product on manufacturing operations with:
      `Control per: Quantity`
      `Type: Pass - Fail`
      `Failure Location: Some internal location`

3. Create a new MO with the quality controlled product and confirm it

4. Click the Quality Checks button, fail the check (make sure to select the faiure location here)

5. After the Quality Check, click Produce All -> Observe that the full quantity of products produced by the MO still was moved to whatever the default Stock location is, not the failure location specified.

**Cause of the issue:**
The method `_move_line_to_failure_location()` expects a picking and SML to exist, however when the quality check starts from an MO, we have neither (contrasted with a check starting from a picking). So the method just skips the logic where the re-route would occur.

**Fix:**
Override the method in the mrp_quality bridge module, if the quality check has a production_id then create the SML on the spot via `MrpProduction.action_confirm()`, then go through the same logic to split the created line as necessary based on the failed quantity vs. total quantity of the MO.

opw-3865301

Forward-Port-Of: odoo/enterprise#62731

### Issue: A quantity of `3` gets displayed as `3.00...004`. ### Steps to reproduce: - Settings > Technical > Database Structure > Decimal Accuracy - Change the `Digits` of `Product Unit of measure` to 5 - Create a storable product P1 with a BOM: - In the operation tab: one operation in `Assembly line 1` - In the component tab: 1 unit of P2 consumed in the operation - Create and confirm an MO for 3 units of P1 - Go to the shopfloor module, remove the MO ready filter Two issues can b

### Issue:

A quantity of `3` gets displayed as `3.00...004`.

### Steps to reproduce:

- Settings > Technical > Database Structure > Decimal Accuracy
- Change the `Digits` of `Product Unit of measure` to 5
- Create a storable product P1 with a BOM: - In the operation tab: one operation in `Assembly line 1` - In the component tab: 1 unit of P2 consumed in the operation
- Create and confirm an MO for 3 units of P1
- Go to the shopfloor module, remove the MO ready filter Two issues can be noticed:
- Click on Register Production A pop up opens. Before validating it:
The displayed producing quantity of P1 and the quantity of P2 that should be consumed by the operation is`3.00...004`. After validation, the produced quantity is rounded. However, if you click on the cross the rounding error will remain. In addition, the second rounding issue will remain even after validation of the consumed qty.

### Cause of the issue:

Our float utils introduce tiny rounding errors, especially at higher precisions. In our case, these errors are introduced during the call of the write method of the `web_save`.

### Fix:

We eliminate the rounding errors for the display in the same way as initially ptoposed by https://github.com/odoo/enterprise/pull/58880
see commit https://github.com/odoo/enterprise/commit/1c2f0068d319917bb4af163396d0861a1ff6c9e1 and adapt it to also apply to the raw_move_ids of the MO.

opw-3861892
---

Forward-Port-Of: odoo/enterprise#62510

### steps to reproduce: - Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2 - Create and confirm an MO using that bom - Go to the shopfloor, validate all the quantities of the operation 1 and mark as done without setting a SN on the final product #### > Invalid Operation: You should provide a lot/serial number for the final product ### Expected behavior: You should be able

### steps to reproduce:

- Create a storable product tracked by SN with a bom with two operations in the same workcenter: - Operation 1: with at least one component consumed - Operation 2
- Create and confirm an MO using that bom
- Go to the shopfloor, validate all the quantities of the operation 1 and mark as done without setting a SN on the final product

#### > Invalid Operation: You should provide a lot/serial number for the final product

### Expected behavior:

You should be able to validate the operations of the MO without assigning an SN but you should not be able to mark the MO as done without assigning the SN to the final product.

Note: if no component were consumed in an operation, the invalid operation would not be raised.

### Cause of the Issue:

The invalid operation is raised because of these lines: https://github.com/odoo/enterprise/blob/1b0435a92492d85f28549a207fcdb7224b457c66/mrp_workorder/models/mrp_workorder.py#L433-L434 However, the existence of "self.move_raw_ids" only indicates that a component has to be consumed in this opration rather than the existence of a move requiring a the SN of the final product to be set.

## opw-3987022

Forward-Port-Of: odoo/enterprise#65075

With PostgreSQL 16, test_report_load_more_limit fails because the result of `_get_lines` is not deterministic. It is the case because the query in `_report_custom_engine_partner_vat_listing` doesn't have a ORDER BY clause. Add a ORDER BY clause to have a deterministic behavior. Forward-Port-Of: odoo/enterprise#66035 Forward-Port-Of: odoo/enterprise#65991

With PostgreSQL 16, test_report_load_more_limit fails because the result of `_get_lines` is not deterministic. It is the case because the query in `_report_custom_engine_partner_vat_listing` doesn't have a ORDER BY clause. Add a ORDER BY clause to have a deterministic behavior.

Forward-Port-Of: odoo/enterprise#66035
Forward-Port-Of: odoo/enterprise#65991

This test expects a search result to be in a specific order but the order is not specified in the search query. With postgresql 16 it leads to random order. Forward-Port-Of: odoo/enterprise#66055 Forward-Port-Of: odoo/enterprise#65903

This test expects a search result to be in a specific order but the order is not specified in the search query. With postgresql 16 it leads to random order.

Forward-Port-Of: odoo/enterprise#66055
Forward-Port-Of: odoo/enterprise#65903

Since [1], the shop floor application might crash when not running an update of the MRP application to add the new filter to the search view. This fix resolves this issue by ignoring the 'This Station' filter if it is not installed. [1] https://github.com/odoo/enterprise/pull/64551 Forward-Port-Of: odoo/enterprise#65987

Since [1], the shop floor application might crash when not running an update of the MRP application to add the new filter to the search view. This fix resolves this issue by ignoring the 'This Station' filter if it is not installed.

[1] https://github.com/odoo/enterprise/pull/64551

Forward-Port-Of: odoo/enterprise#65987

Before this commit, receiving logs with non-ascii characters would cause a traceback. After this commit, non-ascii characters are processed correctly. With the proposed fix, should a client send an ascii-encoded string, it will still be decoded correctly, ensuring backwards compatibility. This means that if the IoT box doesn't get updated and interacts with an updated server, since the UTF-8 table covers the ascii table, it won't lead to any error server-side. OPW-4001252 Forward-Port-

Before this commit, receiving logs with non-ascii characters would cause a traceback.

After this commit, non-ascii characters are processed correctly.

With the proposed fix, should a client send an ascii-encoded string, it will still be decoded correctly, ensuring backwards compatibility. This means that if the IoT box doesn't get updated and interacts with an updated server, since the UTF-8 table covers the ascii table, it won't lead to any error server-side.

OPW-4001252

Forward-Port-Of: odoo/enterprise#65956

When computing the number of children of an employee, if the field was never changed, it will be equal to False and appear as 0 on the form view, leading to an error in the retrieval of the appropriate IS Code. We also improve the recompute whole sheet mechanism, applying changes to salary attachments and contract modifications. Forward-Port-Of: odoo/enterprise#65799

When computing the number of children of an employee, if the field was never changed, it will be equal to False and appear as 0 on the form view, leading to an error in the retrieval of the appropriate IS Code.

We also improve the recompute whole sheet mechanism, applying changes to salary attachments and contract modifications.

Forward-Port-Of: odoo/enterprise#65799

Following https://github.com/odoo/enterprise/pull/57063 , demo companies were merged with base companies, we adapt the demo data references to fix tests. Forward-Port-Of: odoo/enterprise#66067

Following https://github.com/odoo/enterprise/pull/57063 , demo companies were merged with base companies, we adapt the demo data references to fix tests.

Forward-Port-Of: odoo/enterprise#66067

For the `Special Economic Zone` , we don't need to show invoice lines in nil category table. The issue was part of the PR https://github.com/odoo/enterprise/pull/61433 but it got missed from saas-17.2 version while resolving the conflicts. saas-17.2 version PR https://github.com/odoo/enterprise/pull/65105 Forward-Port-Of: odoo/enterprise#66051

For the `Special Economic Zone` , we don't need to show invoice lines in nil category table.
The issue was part of the PR https://github.com/odoo/enterprise/pull/61433 but it got missed from saas-17.2 version while resolving the conflicts.

saas-17.2 version PR https://github.com/odoo/enterprise/pull/65105

Forward-Port-Of: odoo/enterprise#66051

# Description Previously, attempting to re-insert a list containing NaN values would cause multiple traceback errors. To resolve this, an error message will now be displayed in the input dialog when the user tries to insert a list with invalid numbers. Task: [4008696](https://www.odoo.com/odoo/project/2328/tasks/4008696?cids=2) Forward-Port-Of: odoo/enterprise#65966 Forward-Port-Of: odoo/enterprise#65592

# Description

Previously, attempting to re-insert a list containing NaN values would cause multiple traceback errors.

To resolve this, an error message will now be displayed in the input dialog when the user tries to insert a list with invalid numbers.

Task: [4008696](https://www.odoo.com/odoo/project/2328/tasks/4008696?cids=2)

Forward-Port-Of: odoo/enterprise#65966
Forward-Port-Of: odoo/enterprise#65592

The withholding extra is being computed based on the current date, and not based on the payslip one. This is of course incorrect. Forward-Port-Of: odoo/enterprise#65868

The withholding extra is being computed based on
the current date, and not based on the payslip one. This is of course incorrect.

Forward-Port-Of: odoo/enterprise#65868