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.

Forward-Port-Of: odoo/enterprise#131475

When the VAT of an Ecuadorian company's partner contains characters other
than decimal digits, confirming an invoice raises a traceback.

Steps to reproduce the error:
- Install ``l10n_ec_edi`` module and switch to EC Company
- Open the partner of EC Company > Set a VAT containing non-digit characters
- Create a new invoice > fill the required fields > Confirm

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'E'
```

During invoice confirmation, ``_l10n_ec_set_authorization_number()`` method is
called to generate the authorization number at [1],
It builds the ``key_value`` using the vat of company's partner at [2].
The generated ``key_value`` is then passed to ``_l10n_ec_get_check_digit`` method,
which converts each character of ``key_value`` to an integer using ``int()`` at below line.
https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L830
When the VAT contains a character that cannot be converted to an integer,
It will raises the above traceback.

To build the ``key_value``, the company's partner vat should be RUC consisting of 13 digits.
Ref: https://www.sri.gob.ec/o/sri-portlet-biblioteca-alfresco-internet/descargar/fb95cafc-a8ca-4a4c-afb6-12c4153165f0/FICHA%2520TECNICA%2520COMPROBANTES%2520ELECTR%25C3%2593NICOS%2520ESQUEMA%2520OFFLINE.pdf

Solution:
If the identification type of the company's partner is not RUC, return an empty string.

[1]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L806
[2]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L825-L826

sentry-7642961403

Related Community PR: https://github.com/odoo/odoo/pull/280047

When the VAT of an Ecuadorian company's partner contains characters other
than decimal digits, confirming an invoice raises a traceback.

Steps to reproduce the error:
- Install ``l10n_ec_edi`` module and switch to EC Company
- Open the partner of EC Company > Set a VAT containing non-digit characters
- Create a new invoice > fill the required fields > Confirm

Traceback:
```py
ValueError: invalid literal for int() with base 10: 'E'
```

During invoice confirmation, ``_l10n_ec_set_authorization_number()`` method is
called to generate the authorization number at [1],
It builds the ``key_value`` using the vat of company's partner at [2].
The generated ``key_value`` is then passed to ``_l10n_ec_get_check_digit`` method,
which converts each character of ``key_value`` to an integer using ``int()`` at below line.
https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L830
When the VAT contains a character that cannot be converted to an integer,
It will raises the above traceback.

[1]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L806
[2]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L825-L826

Solution:
Raise the ValidationError when the vat contains non-digit character.

sentry-7642961403

Related Enterprise PR: https://github.com/odoo/enterprise/pull/126519

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Problem:
Closing the chat window of a chat request sent to a website visitor crashes
with `TypeError: Cannot read properties of undefined (reading '_proxy')`.

Cause:
When a record is deleted, `MAKE_UPDATE` clears it from the relations holding
it. Holders still alive come from `recordByLocalId` as proxies, holders already
deleted in the same update come from `deletingRecordsByLocalId` as raw records.
On a raw record, `usingRecord[one] = undefined` overwrites the `RecordList`
instead of emptying it, and the next read of that field crashes.
Regression from [7432827d09e6](https://github.com/odoo/odoo/commit/7432827d09e667bb1e2670c7bb719fe24edec59d).

Solution:
Backport of [7b457e243bdf](https://github.com/odoo/odoo/commit/7b457e243bdfcdd4c4b61b4771643c1985bde9cf)
from 19.0: always work on the raw record and remove the deleted record from
its `RecordList`, for `one` and `many` fields alike.

Steps to reproduce:

    Set a Livechat channel on the website and add yourself as an operator.
    Website > Reporting > Visitors > click `Chat` on a visitor.
    Close the chat window. => Error dialog with the `TypeError` above.

opw-6564629

Circular 99/2025/TT-BTC (effective FY2026) replaces Circular
200/2014/TT-BTC. The Profit & Loss statement (Mẫu B02-DN) gains a
new mandatory line, "Lãi/lỗ của hoạt động bán, thanh lý bất động sản
đầu tư" (mã số 21), computed from the new 5117/6327 sub-accounts
(see the paired l10n_vn commit). Financial income, financial
expenses and the interest memo line shift to mã số 22/23/24
accordingly, the "Net profit from operating activities" formula is
updated to include the new line, and all following line
numbers/labels are renumbered to match the printed form. The
interest memo line itself is renamed from "Chi phí lãi vay" to
"Chi phí đi vay" (Borrowing costs), per the gazette text.

Also, per revised guidance:
- Revenue and cost of goods sold now exclude the new investment
  property sub-accounts (5117/6327), so those amounts aren't
  double-counted between the main lines and the new gain/loss line.
- Other income is now computed from the "income_other" account type
  instead of a hardcoded account code, matching how the chart of
  accounts already classifies it.

Both the Balance Sheet and Profit and Loss VN reports also declare
an extra "Code" string column (for the printed-form mã số) alongside
"Balance". Core's growth-comparison heuristic only turns on the auto
growth-% column when there are exactly 2 total columns; with
Code+Balance that becomes 4 once a comparison period is added, so
the % never renders even though the underlying side-by-side
comparison values are fine. account.report exposes
filter_growth_comparison as a toggle independent from
filter_period_comparison for exactly this case (see Trial Balance
and the Deferred reports), so both reports set it to False: period
comparison stays available, only the auto growth-% column is
suppressed.

Task-6518304

# How to reproduce
- Go to Settings > Default Terms & Conditions > Preview
- Open the editor
- Add a Content Block
- Add an Accordion in that Block
- Save

# The issue
The accordion gets messed up and trying to add a new item to that accordion raises a traceback

# Cause
`invoice_terms_html` is an html field with some sanitization enabled : https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/account/models/company.py#L172

This sanitization will remove the accordion snippet's buttons that controls the functionality of the snippet :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website/views/snippets/s_accordion.xml#L9

This issue was already addressed by :
https://github.com/odoo/odoo/commit/b6b4db5fb5690436a4284f6a22abf9f3b346a324

But it is not enough in the case of the accordion. The buttons will be removed by the lxml clean.Cleaner :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/odoo/tools/mail.py#L364

# Proposed Solution
Disable sanitization entirely, like for blog's content, which can also be edited in the website editor :
https://github.com/odoo/odoo/blob/c11ca6d10cac99b367078823dafef46808346267/addons/website_blog/models/website_blog.py#L29

opw-6500378

Problem:
When sorting by name in the contact list view when a different language is selected, the records were not sorted correctly.

Steps to reproduce:
1. Select another language than English in the user preferences.
2. Go to Contacts app.
3. Click on the "Name" column to sort by name.
4. Observe that the records are not sorted correctly.

Cause:
The field used for name was "display_name" which is a computed field that is not stored in the database. The field was used so that the name is displayed in the correct language, but it cannot be used for sorting. When used for sorting, the database will use the value of the field in the default language, and will show the records in the selected language, which will result in incorrect sorting.

Solution:
Use the field "complete_name" instead of "display_name" for showing the name in the list view. This will enable sorting by name correctly, but will not show the name in the correct language. As discussed in the task, this is an acceptable compromise for now.

Reverts odoo/odoo#257539

opw-6475119

Description of the issue/feature this PR addresses:
When a customer earned loyalty points on a POS order and then refunded that order, the points were never deducted. This allowed a trivial exploit: buy a product to earn points, refund it to get the money back, and keep the points. Repeating this cycle let customers accumulate unlimited loyalty points at no cost to themselves.

Current behavior before PR:
The root cause was that the refund flow in POS only copied product lines with negative quantities into the new refund order. It never touched couponPointChanges, so _postProcessLoyalty had nothing to process and confirm_coupon_programs was never called for the refund.

A secondary issue was that _updatePrograms() runs reactively on every order change and calls pointsForPrograms(), which skips lines where totalProductQty < rule.minimum_qty. For refund lines with negative quantities this condition is always true, so the result was always 0 points — silently overwriting any couponPointChanges we tried to set.

Desired behavior after PR is merged:
The fix works at two levels:

- Server-side (pos_order.py): override action_pos_order_paid() to call _reverse_loyalty_points_for_refund() when the paid order is a refund (negative total linked to an original order via refunded_order_id). This reads the original order's loyalty.history, computes a ratio for partial refunds, and directly deducts points from the loyalty card. Points are allowed to go negative intentionally — this prevents the fraud pattern where a customer earns points, spends them on a reward, then refunds the original purchase to reclaim the money while keeping the reward. Expired or inactive cards are skipped since they carry no meaningful balance. An idempotency guard prevents double-processing on retries.

- Client-side (pos_store.js): override _updatePrograms() to detect refund orders and route them to _updateProgramsForRefund() instead of the normal pointsForPrograms() path. This reads couponPointChanges from the original order, negates them proportionally, and sets them on the refund order so the loyalty points widget at the bottom of the product screen correctly shows the deduction in real time. After sync, postSyncAllOrders skips confirm_coupon_programs for refund orders (since the server already handled it) and instead re-reads the updated card balance from the server.

The order summary widget (order_summary.xml) and receipt template (order_receipt.xml) are updated to display a deducted line alongside the existing won and spent lines, so cashiers and customers can see the point reversal clearly.

Fixes #257767



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Since [1], the registry is loaded without a request context, so a module installation now goes through the fallback of `get_current_website` that reads the url stored on the current thread. That value is a full url, not the `domain:port` the method expects, so IDNA-encoding it splits it on the dots of the path rather than on those of a host name and raises `UnicodeError` as soon as one of the resulting parts reaches 64 characters.

The thread url is now reduced to its `domain:port` part.

Steps to reproduce:
- Start the server locally on a database with demo data, served on `http://localhost:8069`, with only `Website` installed
- Create a new website
- In the configurator, choose `I want an online store`
- Go through each step
- After the last step, a traceback appears while loading the accounting demo data: the configurator should apply without error

[1]: https://github.com/odoo/odoo/commit/1ae80f9fb18c9c9e67fe0367b94f0d882c711570


Also reported here: https://github.com/odoo/odoo/issues/286432

Issue:
----------------------------------------
On the Attendances dashboard view, days marked unavailable (greyed out) for an employee don't match the working schedule that was actually in effect during each displayed period.

Steps to reproduce:
----------------------------------------
- Create two working schedules with different days off (e.g. "Monday off" and "Friday off")
- Give an employee a contract on the first schedule, close it, then start a new contract on the second schedule.
- Open the Attendances dashboard for a period spanning both contracts
- The greyed off day is always the one from the current schedule

Cause:
----------------------------------------
`_gantt_unavailability()` computes unavailable intervals via `_get_unavailable_intervals()`, which only looks at the resource's current calendar for the whole requested range, ignoring the different calendars that applied during earlier contract periods.

Solution:
----------------------------------------
`calendar_periods_by_employee` already contains the periods with their corresponding calendar. We use it to call `_unavailable_intervals_batch()` on each calendar with their interval and combine the results.

opw-6460004

**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

Forward-Port-Of: odoo/odoo#284552