#### [FIX] l10n_eu_oss: tax mappings in a hierarchy unique per tax id
Currently creating the tax mappings for a branch company creates the tax
mappings in the first parent company (including the branch) that has
a tax id.
Multiple companies in a hierarchy may share the same tax id.
E.g. let B be a branch of C. Then B would have access to the
mappings created for C. There is no need to also create the tax
mappings for B.

After this commit we only create a tax mapping for a company
if none of the parent companies have the same tax id.
We also ensure that the needed tax mappings in the parent companies are created.

task-4247724

#### [FIX] l10n_eu_oss: tax mappings in a hierarchy unique per tax id

Currently creating the tax mappings for a branch company creates the tax
mappings in the first parent company (including the branch) that has
a tax id.
Multiple companies in a hierarchy may share the same tax id.
E.g. let B be a branch of C. Then B would have access to the
mappings created for C. There is no need to also create the tax
mappings for B.

After this commit we only create a tax mapping for a company
if none of the parent companies have the same tax id.
We also ensure that the needed tax mappings in the parent companies are created.

task-4247724

**Problem:**
When modifying the start time of an all-day Calendar Event created from the Validation of a Time Off Request, the end time will be shortened dramatically, no longer spanning the correct timespan. In the case of the ticket referred to below, this occurs during Google Calendar sync.

**Cause:**
When a Calendar Event is created from a Time Off Request being Validated, its duration is set according to the amount of days the Time Off Request spans multiplied by the employee's daily work hours as defined on their contract, even if the Calendar Event will be an all-day event. When the start time of a Calendar Event is modified, the end time is recomputed according to the duration added to the new start time. As such, if the duration of the Event does not match the duration of the dates covered, it will be shortened dramatically.

**Purpose:**
Modify the values defined when creating a Calendar Event as a result of a Validated Time Off Request so that, if the created Event will be an all day Event, the duration is computed according to `calendar.event._get_duration`.

**Steps to Reproduce in Runbot:**
1. Create and Validate a Time Off Request of the Paid Time Off leave type spanning multiple days.
2. Modify the start time of the Calendar Event that is created as a result of the validation. (This step will likely require a nonstandard flow as the start time field is normally hidden for all-day Calendar Events)

opw-6426586

When a tax affects the base of the subsequent ones — `include_base_amount`,
which is how the ISC is set up in Peru — Odoo links the tax line it generates
to those subsequent taxes, so the ISC tax line ends up carrying the IGV in its
`tax_ids`.

The PLE ledgers build their base columns by summing every move line related to
a given tax group, so that ISC tax line was added to `base_igv` as well and the
ISC ended up reported twice: once inside the taxable base and once in its own
column. A line of 1000.00 with 100.00 of ISC and 198.00 of IGV was declared
with a base of 1100.00 instead of 1000.00.

`l10n_pe_edi` already subtracts the ISC from the `cbc:TaxableAmount` of the CPE
sent to SUNAT, so the electronic invoice and the ledger disagreed on the very
same document.

### What changed

The base taxes are now joined only for base lines, instead of repeating the
condition on each of the twelve `base_*` columns. Besides keeping tax lines out
of the base columns, this also stops a tax line from being counted once per
subsequent tax: an ISC followed by both the IGV and the ICBPER produced two rows
in the join, and its own column was reported twice.

### Scope

`_get_ple_report_data` is shared, so this covers the sales ledger 14.1 and the
purchase ledgers 8.1 and 8.2. A configuration where no tax affects the base of
a later one is unaffected: the standard Peruvian chart template has no purchase
ISC, so ordinary IGV-only purchases report exactly the same values as before.

### Tests

- `test_sale_report_isc_base`: an ISC preceding the IGV, on an invoice and on a
  credit note; the base column excludes the ISC.
- `test_sale_report_isc_reported_once`: an ISC followed by the IGV and the
  ICBPER is reported once.

Both fail without the fix.

Supersedes odoo/enterprise#128300, which targeted 19.0.