In a previous commit: #151805, the goal was to add margin to the account invoice report. No negative margins were possible before because it didn't take the customer's credit notes. This is now fixed with this commit, that aims to add customer's credit note to margin calculations task-4167630 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185498

In a previous commit: #151805, the goal was to add margin to the account invoice report.

No negative margins were possible before because it didn't take the customer's credit notes.

This is now fixed with this commit, that aims to add customer's credit note to margin calculations

task-4167630

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

Forward-Port-Of: odoo/odoo#185498

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. Also the other UI strings were in all caps and have been changed to capitalized strings. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/enterprise/pull/73285 Forward-Port-Of: odoo/odoo#186980 Forward-Port-Of: odoo/odoo#186237

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up.

Also the other UI strings were in all caps and have been changed to capitalized strings.

[opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444)

Related to https://github.com/odoo/enterprise/pull/73285

Forward-Port-Of: odoo/odoo#186980
Forward-Port-Of: odoo/odoo#186237

## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is cal

## Issue:
- When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English.

## Steps To Reproduce:
- Create a storable product.
- Define a vendor for this product and add a delivery lead time.
- Navigate to the product template and click on the "Replenish" button.
- Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time.
- Change the language of the database to a different language.
- Repeat the replenish process.
- Observe that the schedule date is not calculated correctly.

## Solution:
- Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons..

opw-4199660

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

Forward-Port-Of: odoo/odoo#183552

The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email,

The Send & Print dialog will not consider attachments that have the same name as removed ones, example:

- Create an invoice
- Confirm it
- From the action menu: `Print` > `Invoice`
- Download the file to disk - e.g. `INV_2024_00001.pdf`
- Open the `Send & Print` dialog
- Select `Email` only
- Remove the generated attachment `INV_2024_00001.pdf` (on the dialog)
- Add the `INV_2024_00001.pdf` attachment (the one on disk)
- Send the email

The invoice will not be attached to the email, you can check in the chatter.
This occurs because we filter out attachments by checking their names, and the name is the same as the auto-generated one.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4260237)
opw-4260237

Forward-Port-Of: odoo/odoo#186489

When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187102 Forward-Port-Of: odoo/odoo#186808

When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread.

The fix is to call the func to remove the typing indicator when the thread changes.

task-4285488


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

Forward-Port-Of: odoo/odoo#187102
Forward-Port-Of: odoo/odoo#186808

Steps to reproduce: [point_of_sale] - activate "Generate a code on ticket" option in PoS settings. - have a PoS session in GMT-6 and create an order after 6pm local time. - go to /pos/ticket, enter the order information and the date that appears on the ticket - ** No sale order found ** Cause The `date_order` of the sale order is stored in UTC while the date displayed on the ticket is in local time. Change This commit makes the search domain bigger to account for orders made in diff

Steps to reproduce:
[point_of_sale]
- activate "Generate a code on ticket" option in PoS settings.
- have a PoS session in GMT-6 and create an order after 6pm local time.
- go to /pos/ticket, enter the order information and the date that appears on the ticket
- ** No sale order found **

Cause
The `date_order` of the sale order is stored in UTC while the date displayed on the ticket is in local time.

Change
This commit makes the search domain bigger to account for orders made in different timezones.

opw-4311152

Forward-Port-Of: odoo/odoo#186770

**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the butto

**Steps to reproduce:**
- Install l10n_mx_reports (not mandatory but easier to reproduce)
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to "Accounting / Reporting / Audit Reports / Trial Balance"
- Select "Last Month" as data filter
- Select "Previous Month: 9" as comparison filter
- Click on dropdown button next to PDF button
- Click on a button that is displayed in front of the header of the report (e.g. XLSX)

**Issue:**
The action is not triggered.
Once the button has been clicked, the dropdown menu disappears behind the header of the report.

**Cause:**
The buttons in the dropdown menu have z-index:1000 and the thead
of the report has the z-index:999, which displays the buttons in
front the header of the report.
However, when clicked, the button becomes active and its z-index
falls to 2, putting it behind the header.

opw-4265087




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

Forward-Port-Of: odoo/odoo#186277

This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: re

This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen.

Steps to reproduce (on a small screen):
- Install CRM module
- Go to CRM > Configuration > Pipeline > Tags
- Try to modify one of the list's record

⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed

Note: reported during the mobile tests conversion to HOOT in master.



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

Forward-Port-Of: odoo/odoo#187110

Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579

Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed.

Forward-Port-Of: odoo/odoo#187053
Forward-Port-Of: odoo/odoo#186579

In this commit, we fix undeterministic bugs in tour add_to_cart_snippet_tour. To fix this behavior, we add few additionnal steps to check the state of DOM before continuing the tour. Forward-Port-Of: odoo/odoo#180079 Forward-Port-Of: odoo/odoo#178788

In this commit, we fix undeterministic bugs in tour
add_to_cart_snippet_tour. To fix this behavior, we add few additionnal
steps to check the state of DOM before continuing the tour.

Forward-Port-Of: odoo/odoo#180079
Forward-Port-Of: odoo/odoo#178788

Before this commit, when changing the chart type, the data source was not updated. Which was a problem, because the data returned for different chart types is different (eg. pie charts filter empty points). That meant that when changing the chart type from line => pie we displayed a pie with empty points, but when reloading the page the data would change to the correct one. Task: [4306227](https://www.odoo.com/web#id=4306227&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&

Before this commit, when changing the chart type, the data source was not updated. Which was a problem, because the data returned for different chart types is different (eg. pie charts filter empty points).

That meant that when changing the chart type from line => pie we displayed a pie with empty points, but when reloading the page the data would change to the correct one.

Task: [4306227](https://www.odoo.com/web#id=4306227&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

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#186662
Forward-Port-Of: odoo/odoo#186110

Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods. To reproduce this issue: 1) Install Point of Sale 2) Try to duplicate multiple payment methods from the POS configuration Error:- ``` ValueError: Expected singleton: account.journal(14, 18) ``` This is because of the changes from the recent commit https://github.com/odoo/odoo/pull/175530/commits/0fbd47bdd2fe06feda7df747e8560b810a666386 In `copy` method, when multiple records are dupli

Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods.

To reproduce this issue:

1) Install Point of Sale
2) Try to duplicate multiple payment methods from the POS configuration

Error:- 
```
ValueError: Expected singleton: account.journal(14, 18)
```

This is because of the changes from the recent commit https://github.com/odoo/odoo/pull/175530/commits/0fbd47bdd2fe06feda7df747e8560b810a666386

In `copy` method, when multiple records are duplicated it executed the method at multiple times.
 so `self` should have a single record at a time.

From the `saas-17.2`, the `copy` method changes to `copy_data`, 
So it is executed at a time when the `self` having multiple recordsets.

This leads to a traceback as `self.journal_id.type` is used.

https://github.com/odoo/odoo/blob/88604332ae37d75c1435a298319a378841abf25a/addons/point_of_sale/models/pos_payment_method.py#L166-L168

sentry-5790593911

Forward-Port-Of: odoo/odoo#179058

…or the general ledger In a previous pull request: https://github.com/odoo/enterprise/pull/46498, the columns date was switched to invoice date. We want to revert back to the state before this commit. So using the accounting_date instead of the invoice_date on the general ledger. task-4270453 Forward-Port-Of: odoo/enterprise#72673

…or the general ledger

In a previous pull request: https://github.com/odoo/enterprise/pull/46498, the columns date was switched to invoice date.

We want to revert back to the state before this commit. So using the accounting_date instead of the invoice_date on the general ledger.

task-4270453

Forward-Port-Of: odoo/enterprise#72673

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. This commit adapts an error message to the new term. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/odoo/pull/186237 Forward-Port-Of: odoo/enterprise#73688 Forward-Port-Of: odoo/enterprise#73285

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up.

This commit adapts an error message to the new term.

[opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444)

Related to https://github.com/odoo/odoo/pull/186237

Forward-Port-Of: odoo/enterprise#73688
Forward-Port-Of: odoo/enterprise#73285

### Steps to reproduce: - In the settings Enable Multi-steps route - Create a product FP with a BOM: - 1 component: 1 x COMP (tracked by SN) - 1 operation: "Register SN on COMP" - Add an instruction on your op: - type: "Register consumed component" - Product To Register: COMP - Put 2 SN for COMP: - SN01 in Stock/Shelf1 - SN02 in Stock/Shelf2 - Create and confirm an MO for 1 Unit of FP > SN01 is reserved on the COMP raw move. - Go to the shopfloor > "Register SN o

### Steps to reproduce:

- In the settings Enable Multi-steps route
- Create a product FP with a BOM:
  - 1 component: 1 x COMP (tracked by SN)
  - 1 operation: "Register SN on COMP"
  - Add an instruction on your op:
    - type: "Register consumed component"
    - Product To Register: COMP
- Put 2 SN for COMP:
  - SN01 in Stock/Shelf1
  - SN02 in Stock/Shelf2
- Create and confirm an MO for 1 Unit of FP
> SN01 is reserved on the COMP raw move.
- Go to the shopfloor > "Register SN on COMP"
- Change the SN of the COMP from SN01 to SN02
#### > Go back to the MO the incorrect location was used

### Cause of the issue:

While the lot is correctly updated by the action here: https://github.com/odoo/enterprise/blob/e90cf74be3945d1f1256d398ca9c4b61bc35ed08/mrp_workorder/models/quality.py#L485-L507 The associated quant is not set and hence the move location_id, package, ... are not updated with it.

### Fix:

We take advantage of the `quant_id` dummy field of the `stock.move.line` to update the info to write thanks to the write override: https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L399-L400 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L911-L920

### Note:

Unfortunately, the Dialog opened when clicking on the the quality check from the shopfloor:
https://github.com/odoo/enterprise/blob/34ab94cdcc49f4ade66953874a03f2988b2b4317/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L12
is not embedded in a form view so that the onchange:
https://github.com/odoo/odoo/blob/366676cafdce00d55823c6daf41452b0c2373e4d/addons/stock/models/stock_move_line.py#L185-L192
is not triggered by our change of "lot_id".

opw-4149941
---

Forward-Port-Of: odoo/enterprise#73175
Forward-Port-Of: odoo/enterprise#72816

Steps to reproduce: - Create a subscription product with two or more plans - Go to the product's page on eCommerce - Choose another plan than the default one - Add it to the cart - Notice the default plan is the one added to the cart Current behavior before PR: After this change https://github.com/odoo/enterprise/pull/71347/commits/a847237eaf91df641d6af6c7122a1e7216621f9a there is a div got added before the tag of the select dropdown menu. So when we are getting the value of the pl

Steps to reproduce:
	- Create a subscription product with two or more plans
	- Go to the product's page on eCommerce
	- Choose another plan than the default one
	- Add it to the cart
	- Notice the default plan is the one added to the cart

Current behavior before PR:
After this change https://github.com/odoo/enterprise/pull/71347/commits/a847237eaf91df641d6af6c7122a1e7216621f9a there is a div got added before the tag of the select dropdown menu. So when we are getting the value of the plan_id selected https://github.com/odoo/enterprise/blob/18.0/website_sale_subscription/static/src/js/website_sale_subscription.js#L14 we don't find any element with this path.

Desired behavior after PR is merged:
We are changing the path that we get the value of the selected plan out of so we can make sure it is getting the right element which will get the right value accordingly.

opw-4296527

Forward-Port-Of: odoo/enterprise#73677

The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon. task-4317822 Forward-Port-Of: odoo/enterprise#73582

The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon.

task-4317822

Forward-Port-Of: odoo/enterprise#73582

**Version:** - 17.0 **Steps to reproduce:** 1. In the Sign app, send a request for a signature. 2. Complete the signature and submit the request. 3. Observe the completion certificate that is generated. **Issue:** The log_date in the completion certificate report is displayed based on the user's timezone, causing inconsistencies. **Solution:** replaced `t-field` with `t-out` to retain the log_date in UTC, ensuring consistency regardless of the user's time zone. task-4014378

**Version:**
- 17.0

**Steps to reproduce:**
1. In the Sign app, send a request for a signature.
2. Complete the signature and submit the request.
3. Observe the completion certificate that is generated.


**Issue:**
The log_date in the completion certificate report is displayed based on the user's timezone, causing inconsistencies.


**Solution:**
replaced `t-field` with `t-out` to retain the log_date in UTC, ensuring consistency regardless of the user's time zone.

task-4014378

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

Forward-Port-Of: odoo/enterprise#66565

StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period. To reproduce, you can: - Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01" * Recurring plan: Monthly * Start Date: "2024-10-01" - Trigger the cron to invoice & deliver the FIRST period ("2

StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period.

To reproduce, you can:
- Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01"
    * Recurring plan: Monthly
    * Start Date: "2024-10-01"
- Trigger the cron to invoice & deliver the FIRST period ("2024-10-01" -> "2024-10-31").
- Validate the first period picking => "Scheduled Date" becomes the done date: "2024-11-01"
- Trigger the cron to invoice & deliver the SECOND period ("2024-11-01" -> "2024-11-30"). => Second period picking is NOT generated, because the first period picking was interpreted as belonging to the second period.

---

Test result before fix:
```
2024-11-07 13:44:54,695 34298 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_picking_done_in_another_period
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 543, in test_picking_done_in_another_period
    self.assertTrue(bool(second_picking))
AssertionError: False is not true
```

OPW-4280155

Forward-Port-Of: odoo/enterprise#73575
Forward-Port-Of: odoo/enterprise#73484

Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388 Forward-Port-Of: odoo/enterprise#66901

Tax closing with fiscal positions was not working properly.

1. If the generic tax report doesn't have a specific country and the filter for
fiscal position, it should take into account `all` fiscal positions.

3. The closing mechanism until version 18.0 does not work properly with the
oss reports. It was not intended for the user to be able to do a closing
there before version 18.0.

opw-3974388

Forward-Port-Of: odoo/enterprise#66901

Purpose ======= Currently not handled for localized projects TaskID: 4319801 Forward-Port-Of: odoo/enterprise#73568

Purpose
=======

Currently not handled for localized projects

TaskID: 4319801

Forward-Port-Of: odoo/enterprise#73568

Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC Quadrum - Enable currency USD - Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148 - Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16% - Confirm - Make 2 partial payments of 100'000 MXN - On the Invoice, click 'Update Payments' - In the CFDI tab, on one

Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system
Use case:
- In an MX Company with PAC Quadrum
- Enable currency USD
- Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148
- Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16%
- Confirm
- Make 2 partial payments of 100'000 MXN
- On the Invoice, click 'Update Payments'
- In the CFDI tab, on one of the payments, click 'Force CFDI'

Issue: Validation will fail with error
Note: This does not occur with other providers (Solucion Factibles)
```
Code : CRP20275
Message : La suma de los valores registrados en el campo ImpPagado del nodo DoctoRelacionado,
convertidos a la moneda del pago, no es menor o igual que el valor del campo Monto.
```

This occurs because, when computing the payment rate in USD, we obtain 4959.90. Due to rounding, this amount, reconverted in MXN is 100000.02 so we need to transmit an adjusted rate for Providers with a lower error tolerance

opw-4314798

Forward-Port-Of: odoo/enterprise#73696

Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as

Steps to reproduce:
- Install Attendances
- New employee > New Contract > Set a wage
- Set 'Work Entry Source' to 'Attendances'
- Payroll app > New Payslip > Compute Sheet
- Salary Computation tab > Basic salary = contract Wage

Steps to check salary configurator:
- Install Salary Configurator and Recruitment
- Recruitment > Any Job Position > New Application
- Generate Offer > Pick template > Configure your package
- Under 'Net Salary' click Details

The basic salary should be 0 as no work hours have been recorded, note that this is different from having leaves recorded we're talking about a case where no records are available to compute the payslip basic salary. We might still want to generate a payslip in such cases to account for the flat allowances / deductions the employee might have on their contract's salary structure.

We can't just set it to 0 though:
This workaround is needed because the salary configurator also uses salary computation, where we do want to get the monthly wage (Since the contract is still provisional we don't have worked hours, but we still want it to be reflective of the position's monthly wage). In the case of an active employee however, paying a basic wage when no hours have been worked does not make sense so it should invariably be 0.

This could also be relevant with other work entry sources than attendances but a contract based on worked entries automatically generates worked hours according to the schedule so it is more difficult to reach.

opw-4266880

Forward-Port-Of: odoo/enterprise#73469

Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when trying to create the corresponding purchase order. Purpose of this PR: If there are no subscription dates on the invoice lines then we do not calculate the length of the subscription in months and instead create the purchase order line description just as the commission for the corres

Version: 16.0+

Issue:
When we make commission on a subscription sale order, 
the subscription end and start dates are not passed through the order lines -> invoice lines and 
we run into an error when trying to create the corresponding purchase order.

Purpose of this PR:
If there are no subscription dates on the invoice lines 
then we do not calculate the length of the subscription in months and 
instead create the purchase order line description just as the commission for the corresponding subscription.

Steps to reproduce on runbot:
install partner_commission
set up a subscription with a referrer and a commission plan create invoice for the subscription
try to register the payment for the invoice
error raised regarding a max function with no args

Notes:
looking to investigate further why the subscription dates are not passed from 
the subscription to the order lines to the invoice lines

in 17.0+ field name is changed from `subscription_end_date` to `deferred_end_date` (same for `start` date),
will have to adjust in fw ports

opw-4240937

Forward-Port-Of: odoo/enterprise#73465
Forward-Port-Of: odoo/enterprise#73428