**Current behavior:**
For a `PurchaseOrder` record, writing on the `partner_id` and a field of an `order_line` which is computed by
`_compute_price_unit_and_date_planned_and_name` will cause the new value of the order line write to be overwritten.

E.g., writing on `partner_id` and
`purchase.order.line.price_unit`

**Expected behavior:**
The freshly written value in cache for the order line field should be protected from re-writes.

**Steps to reproduce:**
1. Create a product with a supplierinfo (vendor)

2. Create a new purchase order with the vendor as the partner and an order line for the product -> Save

3. Export the purchase order to xlsx, add the fields: `partner_id`, `order_line/external ID`, `order_line.price_unit`

4. Open the exported xlsx file and change the price unit value

5. Import the file -> see that the price unit on the order line did not update

**Cause of the issue:**
The new price unit gets updated in cache, but prior to the entire `write` sequence finishing, we will process pending recomputations where, seeing that `PurchaseOrder.partner_id` was updated, `_compute_price_unit_and_date_planned_and_name` will be called.

Even though `price_unit` is protected, if any of the other fields which are computed by this method are not, then it won't matter.

**Fix:**
A simple solution for *this specific* instance of over-using a compute method is to just not over-write `partner_id` if it's equivalent to the present value on the record.

If `partner_id` is overwritten for real it seems fine to let everything be recomputed.

opw-4574816

### Steps to reproduce:
- Install "l10n_mx_edi" and switch to a Mexican company
- In Accounting > Configuration > Taxes activate the tax "1.25 WH"
- Create an invoice with one line with a price of $50 and the tax "1.25 WH"
- Go to the customer of the invoice
- Sale & Purchase > Fiscal information and activate "No Tax Breakdown"
- Confirm the invoice and Send it to CFDI
- Traceback

### Cause:
This [commit](https://github.com/odoo/enterprise/pull/75381/commits/3f2e9437439fd6f987a13816473da2bd5a26953d) added a part in the code to prevent rounding error when specific discounts are applied which makes the base have a 5 as third digit.

When having a withholding tax and selecting "No Tax Breakdown" on the partner, the base amount will be decreased by the amount of the tax. If this amount has a 5 as third digit, a difference is detected here: `delta_discount = currency.round(sum(x['importe'] for x in line_values_list)) - cfdi_values['subtotal']` because:
- `x['importe']` is 49.375 which rounds up to 49.38
- `cfdi_values['subtotal']` is 49.37 because the tax was rounded up from 0.625 to 0.63 The code will then try to find lines with discounts but there are none so it raises an error at the `max()` function which is given nothing.

### Solution:
Adding `default=None` to `max()` so it doesn't crash.

But the rounding issue still needs to be fixed.
The fix is to select a line with more than 2 digits and to remove the difference with its rounded value. This ensures that the resulting value stay in the same 2-digit range, preventing error CFDI40167, and that the sum of "importe" is rounded down.

opw-4528766