**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

Forward-Port-Of: odoo/enterprise#120384
Forward-Port-Of: odoo/enterprise#115256

When reloading a chart of accounts, `_pre_reload_data` resolves an account via its xmlid and then evaluates:
```py
    re.match(f'^{values["code"]}0*$', account.code)
```
`account.code` is a non-stored computed field that reads from the company-dependent field `code_store`. If the resolved account has no `code_store` entry for the target company (e.g. the account was originally set up under a different company but its xmlid was prefixed with the current company id), `_compute_code` returns False instead of a string, causing a TypeError in re.match.
```py
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 442, in _pre_reload_data
    if not account or not re.match(f'^{values["code"]}0*$', account.code):
  File "/usr/lib/python3.10/re.py", line 190, in match
    return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object
```
```sql
apan_4342860=> SELECT
    aa.id,
    aa.code_store,
    imd.module,
    imd.name
FROM account_account aa
JOIN ir_model_data imd
    ON imd.res_id = aa.id
   AND imd.model = 'account.account'
WHERE aa.id = 1056;
  id  |   code_store    | module  |      name
------+-----------------+---------+-----------------
 1056 | {"2": "510500"} | account | 1_co_puc_510500
(1 row)
```

This situation arises when a customer moves or reassigns an account between companies but the xmlid retains the original company prefix.

**Fix:**
After resolving the account via xmlid, check whether it actually belongs to the target company using filtered_domain with _check_company_domain. If it does not pass the check, unlink the stale ir.model.data entry and treat the account as not found, allowing the reload to re-establish the correct xmlid linkage via the code-based lookup that follows.

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

Forward-Port-Of: odoo/odoo#269696
Forward-Port-Of: odoo/odoo#269291

When reloading a chart of accounts, `_pre_reload_data` resolves an account via its xmlid and then evaluates:
```py
    re.match(f'^{values["code"]}0*$', account.code)
```
`account.code` is a non-stored computed field that reads from the company-dependent field `code_store`. If the resolved account has no `code_store` entry for the target company (e.g. the account was originally set up under a different company but its xmlid was prefixed with the current company id), `_compute_code` returns False instead of a string, causing a TypeError in re.match.
```py
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 442, in _pre_reload_data
    if not account or not re.match(f'^{values["code"]}0*$', account.code):
  File "/usr/lib/python3.10/re.py", line 190, in match
    return _compile(pattern, flags).match(string)
TypeError: expected string or bytes-like object
```
```sql
apan_4342860=> SELECT
    aa.id,
    aa.code_store,
    imd.module,
    imd.name
FROM account_account aa
JOIN ir_model_data imd
    ON imd.res_id = aa.id
   AND imd.model = 'account.account'
WHERE aa.id = 1056;
  id  |   code_store    | module  |      name
------+-----------------+---------+-----------------
 1056 | {"2": "510500"} | account | 1_co_puc_510500
(1 row)
```

This situation arises when a customer moves or reassigns an account between companies but the xmlid retains the original company prefix.

**Fix:**
After resolving the account via xmlid, check whether it actually belongs to the target company using filtered_domain with _check_company_domain. If it does not pass the check, unlink the stale ir.model.data entry and treat the account as not found, allowing the reload to re-establish the correct xmlid linkage via the code-based lookup that follows.

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

Forward-Port-Of: odoo/odoo#269696
Forward-Port-Of: odoo/odoo#269291

Steps to Reproduce:
1. Install Accounting module (without Point of Sale).
2. Create a customer.
3. Create a journal entry with that customer set only at line level.
4. Post the journal entry.
5. Open the customer form.

Issue:
The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer.

Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly.

Root Cause:
The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden.

Fix:
Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True.

Result:
The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level.

owp = 6243562

Forward-Port-Of: odoo/enterprise#120294
Forward-Port-Of: odoo/enterprise#119084

Report edits could be applied on shared layouts such as web.basic_layout instead of the report-specific document view.

This caused Studio customization diffs to affect unrelated reports and could also lead to rendering errors when report-specific fields were evaluated in a different report context.

The issue occurred because content was inserted directly into the shared layout article section instead of the nested report document view.

Steps to reproduce:
1. Open Studio on any module and create or edit a report.
2. Select any of the External, Minimal, or Blank report types.
3. Add content to the report body and save the report.
4. Open another module and create a report using the same report type.
5. Observe that the previous customization is already present.

Before this fix, the generated diff could inherit from web.basic_layout. After this fix, body edits are kept inside the report-specific document view.

Related Ticket:
opw-6245485

Forward-Port-Of: odoo/enterprise#120299
Forward-Port-Of: odoo/enterprise#118880

Steps to Reproduce:
1. Install Accounting module (without Point of Sale).
2. Create a customer.
3. Create a journal entry with that customer set only at line level.
4. Post the journal entry.
5. Open the customer form.

Issue:
The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer.

Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly.

Root Cause:
The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden.

Fix:
Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True.

Result:
The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level.

owp = 6243562

Forward-Port-Of: odoo/enterprise#120294
Forward-Port-Of: odoo/enterprise#119084

**Steps to reproduce:**
1. Install l10n_mx_hr_payroll.
2. Create an employee with a contract date over 35 years ago (e.g., 1985).
3. Create a payslip for this employee.
4. Click on "Compute Sheet".

```Error: KeyError(36) while evaluating```

**Cause:**
The rule parameter [rule_parameter_holiday_table](https://github.com/odoo/enterprise/blob/c02c4571bb7db7197b07539ba390d4d20fdce9fe/l10n_mx_hr_payroll/data/hr_rule_parameters_data.xml#L722-L758) defines values
only up to 35 years. Seniority exceeding this range causes a KeyError.

**Solution:**
Extended the `rule_parameter_holiday_2024` table from 35 to 60 years,
following the Mexican Federal Labor Law (LFT) reform formula
(+2 days every 5-year milestone from year 6 onwards).

**NOTE:**(Alternative approach)
```python
@staticmethod
def _get_mx_holiday_days(years_worked):
    if years_worked <= 0:
        return 0
    if years_worked <= 5:
        return 12 + (years_worked - 1) * 2
    five_year_periods = (years_worked - 6) // 5
    return 22 + five_year_periods * 2
    
  ```
This approach removes the need for XML data maintenance and handles
all future seniority values mathematically without any cap issues.
  
  
opw-6090590

Forward-Port-Of: odoo/enterprise#113536

The `tax_ids` field on `pos.order.line` is defined with `readonly=True`. When editing a POS order from the backend (e.g. during a return/exchange flow), the `_onchange_product_id` method correctly sets `tax_ids` from the product, and the computed `tax_ids_after_fiscal_position` displays the mapped taxes in the UI. However, because `tax_ids` is readonly, the web client does not include it in the save payload. As a result, the taxes are silently dropped on save and `tax_ids_after_fiscal_position` recomputes to empty.

Steps to reproduce:
1. Create and pay a POS order with a product that has taxes
2. Go to the backend (Point of Sale > Orders) and open that order
3. Initiate a return for the order
4. In the return order, add a new product (exchange scenario)
5. Observe that taxes are correctly shown on the new line
6. Click Save
7. The taxes disappear from the order line

The fix adds `force_save="1"` to the `tax_ids` field in both the list and form views of `pos.order.line`, consistent with how `price_subtotal` and `price_subtotal_incl` are already handled in the same views.


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

Forward-Port-Of: odoo/odoo#261103
Forward-Port-Of: odoo/odoo#253680

**Steps to reproduce:**
1. Install l10n_mx_hr_payroll.
2. Create an employee with a contract date over 35 years ago (e.g., 1985).
3. Create a payslip for this employee.
4. Click on "Compute Sheet".

```Error: KeyError(36) while evaluating```

**Cause:**
The rule parameter [rule_parameter_holiday_table](https://github.com/odoo/enterprise/blob/c02c4571bb7db7197b07539ba390d4d20fdce9fe/l10n_mx_hr_payroll/data/hr_rule_parameters_data.xml#L722-L758) defines values
only up to 35 years. Seniority exceeding this range causes a KeyError.

**Solution:**
Extended the `rule_parameter_holiday_2024` table from 35 to 60 years,
following the Mexican Federal Labor Law (LFT) reform formula
(+2 days every 5-year milestone from year 6 onwards).

**NOTE:**(Alternative approach)
```python
@staticmethod
def _get_mx_holiday_days(years_worked):
    if years_worked <= 0:
        return 0
    if years_worked <= 5:
        return 12 + (years_worked - 1) * 2
    five_year_periods = (years_worked - 6) // 5
    return 22 + five_year_periods * 2
    
  ```
This approach removes the need for XML data maintenance and handles
all future seniority values mathematically without any cap issues.
  
  
opw-6090590

Forward-Port-Of: odoo/enterprise#113536

When calling on a empty recordset action_mark_as_done, it creates a traceback.

**Observation**

When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 
Inside button_finish, it retrieves all open workorders and marks them as done:
 - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 
 - mark them as done:
https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678

Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 

-> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback.

opw-6239910

Forward-Port-Of: odoo/enterprise#118718
Forward-Port-Of: odoo/enterprise#118403

### **Steps to reproduce:**
- Install Payroll and Attendance apps.
- Create an employee with a flexible working schedule and work entry source as attendance.
- Create an attendance record for this employee.
- Create and compute a payslip for this employee.

### **Observed Behavior:**
 Worked Day lines are not generated, and Basic Wage is calculated as 0.

### **Expected Behavior:**
Worked Day lines should be populated based on attendance records.

### **Root Cause:**
During payslip computation, [_compute_worked_days_line_ids](https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1846) only generated work entries for versions having a `resource_calendar_id`  at [1]. As a result, fully flexible employees without a working schedule were excluded from work entry generation, preventing worked day lines from being computed.

[1]- https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1890-L1898

### **Fix:**
Remove the `resource_calendar_id` filter when calling `generate_work_entries` in `_compute_worked_days_line_ids` so work entries are also generated for fully flexible employees using attendance-based work entries.

**opw-6146452**

Forward-Port-Of: odoo/enterprise#119673
Forward-Port-Of: odoo/enterprise#117409

## Issue
When scheduling a sign request, the request appears immediately on the portal for the requested signer.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Create and send a sign request
    - Signer 1: Any portal user (e.g., Joel Willis)
    - Use the clock icon to schedule the signature request to a future date
3. Log in as the portal user used in step 2
4. Navigate to Signature Requests
5. **The signature request already appears in the list, even though it was scheduled for a future date.**

## Cause
The portal filters the sign requests shown based on the `is_mail_sent` field, which does not properly reflect when the signature request is shared to the user.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/controllers/portal.py#L40

In fact, when scheduling a signature request, the `is_mail_sent` field is unconditionally set to `True`, even if the signature request will only be sent later.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request_item.py#L289

## Fix
Since the `"scheduled"` `sign_request_item.state` option introduced by https://github.com/odoo/enterprise/commit/ed8d5a653e01b1378f0020e2f7a7c2d39fadf3e9 in 19.1, we can easily filter out the sign request items that are scheduled. That state is automatically updated by the `_cron_update_state`, introduced by the same commit as the `"scheduled"` option.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request.py#L493-L503

opw-6227472

Forward-Port-Of: odoo/enterprise#119007
Forward-Port-Of: odoo/enterprise#118491

Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.

## Steps to produce:
- Install the Inventory module
- Go to Settings and enable Storage Locations.
- Inventory > Configuration > Operation Types > Internal Transfers > Barcode App
- Configure the Destination Location to require scanning after each product.
- Create an Internal Transfer for Pedal Bin, demand 1.
- Mark the transfer as To Do and open it in the Barcode app.
- Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493).
- Delete the newly added line and attempt to Validate.

## Observed Behavior:
The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line.

## Root cause:
This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates.

As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned.
[1]:
https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] :
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]:
https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948

## Solution:
We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product.

To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed.

However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned.

To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily.

opw-6069614

Forward-Port-Of: odoo/enterprise#119870
Forward-Port-Of: odoo/enterprise#113618

### Issue before this commit:
In accrual reports (e.g., "Bill To Receive", "Billed Not Received", "Invoices To Be Issued", and "Invoices Not Delivered"), when grouping the list view by fields such as Vendor, the group header totals for the "Received", "Billed", and "Amount" columns display 0.00 even if the interanl lines of the group are not 0.00.

### Steps to reproduce the issue:
1. Download Purchase Accounting and Sale Accounting
2. Go to one of this pages: Billed Not Received, Bill To Receive, Invoices To Be Issued, and Invoices Not Delivered
3. Ensure the view is in its default grouping (grouped by Vendor or Customer)
4. Observe the group header rows for the Received (or Delivered), Billed (or Invoiced), and Amount columns. They all display 0.00
5. Expand a group that contains records with values greater than zero
6. Observe that the individual records populate correctly, but the aggregated group header row continues to display 0.00.

### Cause of the issue:
The commit ddc1b681656ea8c70f3231cda20b5a58b9ff7dd6 adapted the code to retrieve the new accrual reports but attempted to fetch grouped records using group[0].id as the dictionary key, while the grouped() method actually used the recordset object as the key. This mismatch caused the dictionary lookup to fail, resulting in 0.00 sums. https://github.com/odoo/enterprise/blob/c8535a7a0e2eae811048a34a0bae187a1fa45311/account_accountant/models/analytic_mixin.py#L40-L48

### Reason to introduce the fix:
This fix restores the core analytical utility of the accrual reports, which are crucial for accountants during period-end closings to evaluate totals at a glance.

opw-6232273

Forward-Port-Of: odoo/enterprise#118399

Steps to Reproduce
---
1. Open the Planning module
2. Create an open shift with allocated_hours
3. Click Auto Plan
4. Click Undo on the auto-plan notification

Issue
---
Undoing an auto-plan operation triggers recomputation of allocated_hours,
causing the shift to lose its original workload value.

Current Behaviour
---
When resource_id is set to False during undo:
- _compute_allocated_hours is triggered (depends on resource_id)
- _compute_allocated_percentage is triggered (depends on allocated_hours)
- Both fields are recalculated, potentially changing allocated_hours
  from its pre-assignment value

Expected Behaviour
---
Undoing auto-plan should preserve allocated_hours at its pre-assignment
value while allowing allocated_percentage to adapt to the new context
(open slot vs assigned resource).

Fix
---
Use protecting context manager in action_rollback_auto_plan_ids
to prevent allocated_hours from being recomputed when resource_id is
removed. This allows allocated_percentage to recalculate naturally based
on slot duration while keeping allocated_hours stable.

task - 4952149

Forward-Port-Of: odoo/enterprise#119941
Forward-Port-Of: odoo/enterprise#102864

Steps:
- Install an Odoo 17.0 database with the Indian Payroll module and demo data.
- Upgrade the database to 18.0.

Issue:
- The Indian payroll demo data creates leave allocations and approves them through an XML function call.
- During a fresh installation, demo files are loaded in 'init' mode, so the approval function is executed and the allocations move from 'confirm' to 'validate'.
- However, during a 17.0 >>> 18.0 upgrade, demo files are loaded in 'update' mode. Odoo automatically loads demo files with 'noupdate=True' from the load_demo() >> load_data() function:
- This value is passed to the XML importer and becomes the default noupdate state for the file. Since the demo XML file does not explicitly override this value, the function tag uses 'noupdate=True'.
- When the XML parser reaches the approval function, _tag_function() skips its execution because of noupdate = 'True' and mode = 'update' condition.
- As a result, the approval function is not executed during the upgrade and the leave allocations remain in 'confirm' state. Subsequent demo payroll data expects validated allocations and fails during loading.

Fix:
- Explicitly set 'noupdate=0' on the demo XML file. This overrides the default 'noupdate=True' value applied to demo files, making the parser evaluate the section with 'noupdate=False'.
- As a result, '_tag_function()' executes the approval method during upgrades, the demo leave allocations are validated in both fresh/new db installations and 17.0 >>> 18.0 upgrade scenarios.

runbot error-https://runbot.odoo.com/odoo/error/230430 

task-6268381

Version:
----------
- 18.0+

Steps to reproduce:
-----------------------
1 - Install the `purchase` and `stock` modules.
2 - Create a storable product with tracking enabled.
Set the Cost (standard price) to 50.
3 - Open the product form and go to the Purchase tab.
   * Add a vendor with:
   * Quantity: 2
   * Price: 10
 
4 - Create a Reordering Rule for this product:

   * Route: Buy
   * Trigger: Manual
   * To Order Quantity: 2
 
5 - Click on the Order button to generate a purchase order.
6 - Open the generated Purchase Order and verify the Unit Price
on the purchase order line.
7 - Open the same product and go to the Purchase tab.
In the existing vendor line, add an End Date lower than today so
the vendor pricelist becomes expired.
8 - Reopen the same reordering rule.
Change To Order Quantity to 1.
9 - Click on the Order button again

Issue:
-----
The generated purchase order line gets a Unit Price of 0
instead of keeping the product cost or a valid fallback price.

Root Cause:
--------------
- When clicking on `Order`, it triggers `action_replenish`, which calls the
procurement flow:
`_procure_orderpoint_confirm` → `run` → `run` → `_run_buy`.

- Inside `_run_buy`, the system checks whether a `purchase.order.line`
already exists. In this case, the PO line exists, so it calls
 `_update_purchase_order_line`.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L137

- In `_update_purchase_order_line`, the system tries to fetch a seller using
 `_select_seller`,
- which internally calls `_get_filtered_sellers`.
https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L759

- However, if the seller's `end_date` is less than `today`,
 `_get_filtered_sellers` skips that seller and returns no valid seller.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/product/models/product_product.py#L731-L733

- As a result, `_update_purchase_order_line` does not find any seller and falls
back to setting `price_unit` to `0`, causing the purchase order line price to
be updated incorrectly.

https://github.com/odoo/odoo/blob/47ef8b75d0c90001b9989a95f09b962c5b286c53/addons/purchase_stock/models/stock_rule.py#L259

---

opw-6117461

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