**Problem**
When opening a timesheet record from the *My Timesheets* grid view (via the magnifier icon that appears on cell hover) and refreshing the page, the wrong form view is loaded: the generic "Analytic Items" form on `account.analytic.line` instead of the timesheet-specific form.

**Steps to reproduce**
1. Go to *Timesheets* → *My Timesheets* → switch to **Grid** view.
2. Hover a cell with a timesheet entry and click the magnifier (search) icon.
3. The list opens; click a record to open its form view.
4. Observe the URL: `/odoo/timesheets/<id>`.
5. Refresh the page (F5).

**Expected**
The same timesheet form view is shown after refresh.

**Actual**
The "Analytic Items" form view (`analytic.view_account_analytic_line_form`) is shown instead, exposing the wrong layout/fields.

**Cause**
The grid renderer's `openRecords` builds an inline `ir.actions.act_window` with no `path` and no `id`. When the page is refreshed, the action service reconstructs the action from the URL state alone — model + resId — and resolves the form view by priority. Two priority-1 form views exist on `account.analytic.line` (`analytic.view_account_analytic_line_form` and `hr_timesheet.hr_timesheet_line_form`); the lower-id one wins, which is the analytic one.

**Fix**
Override `openRecords` in `TimesheetGridRenderer` to carry the current action's `path` (or `id`, for non-pathed database actions) onto the inline action. The URL then stays anchored to the original act_window (e.g. `/odoo/timesheets/<id>`), and on refresh the action service rebuilds it with the correct views, including the timesheet-specific form.

opw-6133602

Before this commit:
1. Create a POS order with no discount and a quantity that does not divide evenly into the unit price (e.g. price=10.0, qty=3)
2. Send the order to Jofotara

Jofotara rejects the invoice because the AllowanceCharge/Amount on the invoice line is a small negative value like -0.000000001 with the error `"EINV_MESSAGE":"discount cannot be negative"`

This happens because _add_document_line_gross_subtotal_and_discount_vals computes the discount as: gross_subtotal - total_excluded_currency

where gross_subtotal goes through two independent rounding steps (round unit price, then round unit_price * qty). When the quantity is indivisible, the reconstituted gross_subtotal can land just below total_excluded_currency by a floating-point epsilon, producing a tiny negative discount. The same subtraction also produces a legitimate negative value for refund lines (negative quantity), which was already handled by abs() in _add_pos_order_discount_vals for the document-level total but was left unguarded at the per-line level.

After this commit:

Apply abs() to vals[f'discount_amount{currency_suffix}'] in _add_pos_order_line_allowance_charge_nodes so that discount_amount_currency is always non-negative.

opw-6183423

**Problem:**
When a combo product has a price but all of its combo components have a zero list price, the quotation shows the combo's price twice: once on the combo line itself and once on the last combo item line.

**Steps to reproduce:**
1. Create a combo product with a non-zero price and two or more combo groups whose component products have a zero list price.
2. Create a sale order, add the combo, pick one item per group.
3. Look at the quotation/order: the combo line total and the last combo-item line both show the full combo price.

**Current behavior:**
The full combo price ends up on the last combo item line; the other combo items show 0. The combo line then displays the same total via `_get_combo_totals`, so the same amount appears twice.

**Expected behavior:**
The combo's price is spread across its combo items so no single line duplicates the combo total.

**Cause of the issue:**
`_get_combo_item_display_price` prorates the combo price by each combo's base price. When every base price is 0, every prorated price is 0, so `combo_price_delta` equals the full combo price and is added to the last combo as a rounding correction, concentrating the whole price there instead of spreading it.

**Fix:**
Treat an all-zero base case as "no proration signal" and split the combo price evenly across combos before the delta adjustment runs. The delta correction then only handles rounding, as intended.

opw-6217945