### Steps to reproduce:

- Create a fiscal position that converts 19% tax-inclusive into 19% tax-exclusive.
- Create a product with 19% tax inclusive.
- Create a contact and assign the above fiscal position.
- Navigate to a field service project and add an employee with a tax-included rate in the employee mapping.
- Create a new field service task for the customer with the assigned fiscal position and add one hour for the employee in the mapping.
- Add the product with 19% tax included to the task.
- Mark the task as done.

#### Current Behavior:

- The product unit price is calculated excluding tax.
- The service unit price remains calculated as tax-included.

#### Expected Behavior:

Both product and service unit prices should be calculated consistently as tax-excluded when the tax is set to 19% exclusive.

### Cause of the issue:

When creating a new sale order line if the unit price is not specified "product_id_change" is called which set the correct unit price after applying the fpos by calling `_update_taxes` on the line:
https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L617-L628
But in our case we are setting the `unit_price` to the employee rate here:
https://github.com/odoo/enterprise/blob/e23e01337faeec652d400618cf14aaf3d6d47ef2/industry_fsm_sale/models/project_task.py#L408-L412
and the taxes are not taken into account.

### Fix:

The unit price of the employee rate should be updated to reflect the changed taxes from fpos. However, since `_update_taxes` relies on the unit price of the product rather than on the one given to the line:
https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L685
we can not call the `_update_taxes` directly to update the sol.

opw-3853196

Co-authored-by: waha <waha@odoo.com>

Forward-Port-Of: odoo/enterprise#67730

## Analysis
Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues.
This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config:
```
_computeDataContext() {
...
        const data = toRaw(this.data);
        for (const fieldName in data) {
            const value = data[fieldName];
            const field = this.fields[fieldName]; // field == undefined
            if (field.relatedPropertyField) { // traceback
                continue;
            }
...
}
```

## Steps to reproduce
- Create a product "TEST"
- Create a BoM For product "TEST", with a new product "TEST Component".
- Add 1 Operation OP1 (keep default value), set a description
- Add 1 step to OP1, with type "Register Production"
- Create MO for "TEST", Confirm, Plan, 
- Start operation OP1
- On ShopFloor, go to MO, select workcenter, open step
- Update quantity: Error

## Solution
We make a way for manually fetched fields (most probably, all HTML fields which can contain base64 images) and add it to the fields to avoid them being undefined and causing tracebacks.

 ## References
opw-4103712


--
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)