The method 'test_timesheet_delivery' tests the following use case:

Test timesheet invoicing with 'invoice on delivery' timetracked products
1. Create SO and confirm it
2. log timesheet
3. create invoice
4. log other timesheet
5. create a second invoice
6. add new SO line (delivered service)
7. And finally check the AMOUNTS

But it could happen, according to the installed modules, that the class
TestSaleTimesheet, which is directly linked to
-> TestCommonSaleTimesheetNoChart (sale_timesheet)
--> TestCommonSaleNoChart (sale)
---> AccountTestNoChartCommon (account)
----> SavepointCaseWithUserDemo (base)
-----> SavepointCase (base)
is influenced by other installed modules, that in our case, introduce
new res.currency.rate values.

In our test, on the sale.order.line 'so_line_ordered_global_project',
we use the product 'product_order_timesheet2', with a price_unit=90.

Then we call manually the onchange method:
``` python3
so_line_ordered_global_project.product_id_change()
```

As the order has a pricelist and a partner, we recompute the price
unit, in case a discount applies:
``` python3
if self.order_id.pricelist_id and self.order_id.partner_id:
    vals['price_unit'] = self.env['account.tax']._fix_tax_included_price_company(self._get_display_price(product), product.taxes_id, self.tax_id, self.company_id)
self.update(vals)
```

And then , the call the _get_display_price returns an different amount
that what we expect, as
``` python3
product.with_context(pricelist=self.order_id.pricelist_id.id).price
```

will return the price converted using the related res.currency.rate
at the current date.

As we don't wish to test the conversion into another currency in this
test, we simply unlink all the currency rates, to avoid any external
influence.

TaskID: 2166237