…rrect data from MO operation

**Problem:**
lines of mrp.workcenter.productivity added from 
the workorder widget do not update the linked 
analytic account with the right amount

**Steps to reproduce:**
- enable "analytic accounting" setting
- Unarchive MTO route
- Create a new product
- In the inventory page check MTO and Manufacture routes
- click on the Bill of materials smart button and create 
a new BOM
- add a component and an operation
- Create another product, set "product type" as service
- in the "create on order" field select "project & task"
- create a new quotation with these two products and confirm
- click on the "manufacturing" smart button
- in the work orders page click on the "open work order" 
button at the right of the line
- click on add a line
- set a duration of 30:10 and clik elsewhere on the screen
- save
- click on the "analytic account" smart button
- select the only line and click on the "gross margin" 
smart button

**Current behavior:**
There is a single line with an amount of 0.01

**Expected behavior:**
The price should reflect the hourly rate of the employee
for the task (that's 50.28 with a 100$/hours rate for 
instance)

**Cause of the issue:**
There is two issue here.
First Issue : 
When clicking on save on the widget, this will 
modify the time_ids field of the mrp.workorder
this will create a new mrp.workcenter.productivity
with the values we wrote.
Consequently, on the vals_list when the create method
is triggered duration is set to the duration we wrote 
(so here 30.17)

Because of this, when the _compute_duration is the triggered
previous_durations will be [30.17] and _create_analytic_entry
will be called with a parameter of 30.17
https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L14

Therefore, inside _create_analytic_entry 
duration will be 0 and amount will also be 0

This issue does not happen if the duration is set by changing
the "real duration" in the "work orders" page of the manufacturing 
order. 
This is because when doing it this way, we modify the duration 
of the mrp.workorder which triggers the set_duration_method
which also creates a new mrp.workcenter.productivity but 
here the _prepare_timeline_vals returns a dictonary without 
a duration field
https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workorder.py#L352-L353

Second Issue: 
The line we see with a 0.01 amount is actually created 
before we save. 
It's created from the onchange method when we change the 
duration on the form.
The onchange of duration triggers an onchange of start date
which gets the value of duration and triggers of recomputation
of duration 
https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L522-L531
As a consequence, _compute_duration is called. 
self.duration is initially not rounded so in our exemple 
previous duration will be equal to 30.1666666666668
https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L11
However after the call to super()._compute_duration(), self.duration
will be rounded thanks to the use of convert to duration inside 
the super method
https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L472

So when doing the difference here inside _create_analytic_entry
https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L38
duration will be 5.555555555556424e-05 and amount will be 
-0.005555555555556424 which results in the creation of this line 
with an amount of 0.01

**fix:**
Calling the creation of account.analytic.line from the compute method leads to other problems : 
For instance, if a line is added in the "open work order" widget and we change the end date but change our mind and don't save the line, the duration will have been computed and a new account analytic line will have been created

Whereas calling the method _create_analytic_entries from create() and write() ensures it's only called when the model is saved
opw-4715690

Forward-Port-Of: odoo/enterprise#85517

- Create a product with tracking by serial numbers then set a lot and serial number on the product
- Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings
- Create a sale order with the test product and confirm it
- Create the invoice and send the cfdi report
- Request a cancel and select the reason 01 Document issued with errors (with related document)
.
On the CFDI PDF report of the new invoice, there are no lines for lots and serial numbers—they are not printed.

The report uses the _get_invoiced_lot_values method from sale_stock to retrieve serial numbers. This method is first called when sending the CFDI for the parent invoice. However, when it is called for the child invoice, the method checks the quantity of the serial product, which is now depleted.

This commit introduces a hook that allows to filter the amls taken into account in get_invoiced_lot_values. In l10n_mx_edi, we do not take the amls from the parent invoice after a cfdi cancellation.

community PR: https://github.com/odoo/odoo/pull/202262

opw-4644031

Forward-Port-Of: odoo/enterprise#87687
Forward-Port-Of: odoo/enterprise#81656

The system will crash when we try to set the account for statement lines. And at [1],  we can see that this fetches the `previous_statement_lines`.

[1]
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L654-L656

After that, it calls the `_prepare_reconciliation_rule_data` method. and try to find a `common substring`.
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L676

In the `_get_common_substring` method, when [2] is executed, and if we have the below `payment_ref`
```
[
'PRLV SEPA VROOMLY STR16NASUC4VSCWSRGTVURANBFJQM4LJU9 VROOMLY',
'PRLV SEPA AMAZON PAYMENTS EUROP 450X4WSOR73LFYYL 171-6087599-8440309 AMZN MKTP
FR 45 0X4WSOR73LFYYL',
'PRLV SEPA VROOMLY STR16NASTLNFBLLPVADQPRANTXVPUDYDFY VROOMLY',
'VIR STRIPE VROOMLY-6NXKKON62EKBHVFLXZ3T9PTDOP5 VROOMLY',
'PRLV SEPA VROOMLY STR16NAST8PLKGEKOLWOLRANIEPSODZENR VROOMLY'
]
```
(means our len(substring) is less than 10), Then it returns `None` from line [3].

[2]
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L777-L781

[3]
https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L780

**Steps to produce:-**
1. Install the `Accounting` module.
2. Set up the `Odoo demo bank`.
3. Click on `Transactions` under Bank.
4. Set account as `Cash Discount Loss` for `Monthly Office Rent ` and
   `Annual Public liability insurance`.
5. For `Deposit on the invoice 784`, set the account as other than
   `Cash Discount Loss`  and then delete that, and again set the account as
   `Cash Discount Loss`.

**Error:-**
`AttributeError: 'NoneType' object has no attribute 'strip'`

**Solution:-**
- In this commit, we handle the case where `_get_common_substring` returns
  `None` by checking it before calling .strip().
- This prevents the system from crashing without changing the function’s
  return value.


**Sentry - 6682820343**

Forward-Port-Of: odoo/enterprise#87828