If you have a company parent with loyaltly programs and you try to confirm a sale order from a child company, an access error will be raised.

Steps to reproduce:
-------------------
* Create a loyalty cards program
* Set company to the current company
* Create a branch company for the current one
* Switch to branch company
* Create a sale order, no need to add products, just a partner
* Try to confirm the order
> Observation: Access Error:
> Sorry, Mitchell Admin (id=2) doesn't have 'create' access to:
> -History for Loyalty cards and Ewallets (loyalty.history)

Why the fix:
------------
Here's where the access error is being triggered:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/sale_loyalty/models/sale_order.py#L106

Branches currently have access to the discounts & loyalty programs from the parent company, we extend the access to include loyalty history.

Another solution could be to create the loyalty history using sudo() if the coupon's program id is a parent of the current company.

opw-5055999

Forward-Port-Of: odoo/odoo#226226

### Steps to reproduce:
- Install l10n_br_edi, switch to Brazilian company
- Set up Avalara
- Create an invoice with the tax "ICMS Exemption Incl." which is included in price
- Click "Generate taxes" to compute the taxes with Avalara
- In "Journal Items" we can see a line for "ICMS Exemption Incl.", its value appears as excluded

### Cause:
The result from Avalara included a value for this tax:
```
'tax': 1.44,
'taxImpact': {
	'accounting': 'none',
	'impactOnFinalPrice': 'Included',
	'impactOnNetAmount': 'Included',
},
```
But the untaxed amount is computed without this tax. Odoo keeps the untaxed amount from the response and add a line for the tax. As a result, the tax is added to the amounts like an excluded tax would.

### Solution:
In the response from Avalara, taxes with `['taxImpact']['accounting'] == 'none'` should be part of the accounting: no line should be created for this tax. So we filter them out in `_get_external_taxes`.

We also log these taxes in the chatter to keep a trace of them. As the parameter `'accounting': 'none'` is linked with the tax and not the line, if a tax on one line has `'accounting': 'none'` then the same tax will also have 'accounting': 'none' on all other lines. We use this to fetch all non accounting taxes, then we use the summary to construct the message like it was done before.

The logging in the bridge with pos needed to ba adapted because now the taxes may not be unarchived as they are ignored when they have `'accounting': 'none'`.

opw-4964315

## Versions:
16.0+

## Issue:
After confirming a Sales Order (SO), loyalty points are incorrectly calculated when applying additional promotions. This causes only one reward to be applied instead of all eligible ones.

## Cause:
When the SO is confirmed, the cost in points for each line is retrieved and deducted to compute remaining available points. However, when promotions are re-applied, the system re-evaluates the total cost of the SO and deducts the points again, effectively double-counting the same lines.

## Steps to reproduce:
- Set up a `Discount & Loyalty` promotion program:
  - 2 points granted per purchase (minimum $0).
  - Rewards:
    - 5% discount on "Simple Pen" (costs 1 point).
    - 10% discount on "Whiteboard Pen" (costs 1 point).
  - Create a Quotation with "Simple Pen" and "Whiteboard Pen".
  - Confirm the Quotation into a Sales Order.
  - Apply promotions:
    - The first reward applies correctly
    - The second reward does not apply

opw-4753472

Forward-Port-Of: odoo/odoo#226656
Forward-Port-Of: odoo/odoo#211342

In this bug, when there are multiple warehouse, and a warehouse is supplied by another one, the security lead time is repeated in calculations.

To reproduce the bug:
1- Create a db with, stock, mrp, sale installed.
2- Unarchive `MTO` route.
3- Set `Security Lead` Time in Setting.
4- Create two warehouses wh1, wh2.
5- In wh1, set `Manufacture to Resupply` to True.
6- In wh2, set `Manufacture to Resupply` to False and make it resupply from wh1.
7- Create a product and track inventory.
8- Create a BOM for the product.
9- Enable `Manufacture`, `MTO`, `wh2: Supply Product from wh1` routes for the product.
10- Create a new Quote for the product and in the Delivery, select `wh2` as the warehouse. Confirm the Quote.
11- Open MO. Security lead time is considered twice in dates calculations which is mistake.

To solve this issue, we must call `_get_dates_info` only once. The current condition might be True more than once for multiple moves. We should also check that it is not True for next moves which otherwise means the security lead time is already effected.

This issue is reproduced because this condition is not sufficient to ensure it is called once:
https://github.com/odoo/odoo/blob/c0a7b51c9e14d29cefa96c29dd716b7aec698818/addons/stock/models/stock_move.py#L1656-L1657

The above condition is written to ensure we are adding the delay only when move location is warehouse stock location.

This cause problem in multi-warehouse because we have this case that move location is warehouse stock location once for wh1 and once in wh2.

To solve this issue, we make sure the call `_get_dates_info` doesn't affect when the move has rules with src location in warehouse stock location.

related: #112325

opw-4889642

Forward-Port-Of: odoo/odoo#226712
Forward-Port-Of: odoo/odoo#224232

**Steps to Reproduce:**

1. Create DB in 18.0 with calendar module and google_calendar without demo data.
2. create a calendar event with videocall location other then odoo generated and mark that as guest_readonly.
3. after that  install appointment module and ``acces_token``.
4. upgrade to 18.3 below mentioned traceback will raise or can update to mail template.

**Issue**

why from 18.3 [from](https://github.com/odoo/odoo/commit/999df6d4a3b5d21648e5e09757661714e99e1154#diff-bd520efea06a5449c8694b54f5f7aa8587c929a5669ea0439bb9d5e38f8d29c8) this commit now template will render on record for checking.  During render checking the  ``videocall_redirection``  field value as it [compute](https://github.com/odoo/enterprise/blob/f5d99ea7ae7c2748c4a23a793c46ab1a123b3aad/appointment/models/calendar_event.py#L188) and non store field it going for compute over here the access_token is missing so it will go for compute and during that this [validation](https://github.com/odoo/odoo/blob/1ac89eb71aab48fa8d50fbae01d96bec23d88418/addons/google_calendar/models/calendar.py#L106) is triggering and it breaking because env user is odoobot and user_id is different this issue occur during checking on write on mail template.

**Fix:**

 For fixing this checking is the fields syncable with calendar or not

```
 File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1751, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1914, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/saas-18.4/addons/calendar/models/calendar_event.py", line 696, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/addons/mail/models/mail_thread.py", line 469, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 4620, in _compute_field_value
    determine(field.compute, self)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 81, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 207, in _compute_videocall_redirection
    event.access_token = uuid.uuid4().hex
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1847, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/enterprise/saas-18.4/appointment/models/calendar_event.py", line 246, in write
    res = super().write(vals)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 96, in write
    self._check_modify_event_permission(values)
  File "/home/odoo/src/odoo/saas-18.4/addons/google_calendar/models/calendar.py", line 108, in _check_modify_event_permission
    raise ValidationError(_("The following event can only be updated by the organizer "
odoo.exceptions.ValidationError: El organizador es el único que puede actualizar el siguiente evento de acuerdo con los permisos del evento establecidos en Google Calendar.
```
opw-5042454
upg-3113613
TBG - 2082


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

Forward-Port-Of: odoo/odoo#226890

## **Issue Before This Commit:**
In the workcenter planning view, the total hours displayed were misleading,
as they always showed 24 hours of the day instead of the workcenter’s
defined working hours.
This caused confusion for users since the displayed total hours did not
match the actual available working time of the workcenter.

## **Steps to Reproduce:**
- Create a Manufacturing Order (MO).
- Add "Drawer" as the product.
- Add a "SEC-ASSEM: [FURN_8855] Drawer" BOM.
- Set the quantity to produce as 10.
- Confirm the MO and plan it.
- Open the planning view and notice that the total hours count
  incorrectly shows 24 hours instead of the defined working hours.

## **Cause of the issue:**
The bug was introduced by this PR (https://github.com/odoo/odoo/pull/205486),
as the related changes were not adapted here.
Because of that, pill.record.workcenter_id[0] returns an undefined value.

## **With This Commit:**
The calculation of total hours has been corrected to consider only
the workcenter’s defined working hours.
Users now see accurate hours in the planning view, making it easier
to plan and schedule work orders reliably.

task - 4900885

Forward-Port-Of: odoo/enterprise#93035

Currently, an error occurs when generating a Delivery Guide if the Barcode Scanner is disabled in the Inventory settings.

**Steps to reproduce:**

- Install the `l10n_ec_edi_stock` module and switch to the `EC company`.
- Uncheck `Barcode Scanner` in the Inventory `settings`.
- Create a new warehouse and set the `Entity` and `Emission Point`.
- Navigate to Inventory > Operations > Deliveries and create a new delivery.
- Add details > mark as Todo > Validate > Generate Delivery Guide.

**Error:**
`AttributeError: 'stock.move.line' object has no attribute 'qty_done'`

**Root Cause:**
At [1], the code references `line.qty_done`, but this field is defined in the
`stock_barcode` module at [2]. When the Barcode Scanner is `disabled`, 
the field is not available, leading to the `error`.

**Fix:**
This commit updates the delivery guide values to use `line.quantity` instead
of `line.qty_done` at [1] and at [4]. Since in the `stock_barcode` module at [3],
`qty_done` is derived from `quantity`.

[1]:
https://github.com/odoo/enterprise/blob/ba5b9790f28e2f7eabda22e5992737eab0e82c6e/l10n_ec_edi_stock/models/stock_picking.py#L354

[2]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L23

[3]:
https://github.com/odoo/enterprise/blob/8c53e50df1cf9dc6d3ca4cae19c39135ac85d4e4/stock_barcode/models/stock_move_line.py#L48-L50

[4]:
https://github.com/odoo/enterprise/blob/8b72fdef63f634ccf436b49adbac5c1f9358c127/l10n_ec_edi_stock/views/report_delivery_guide.xml#L165

sentry-6851008674

Forward-Port-Of: odoo/enterprise#93775

Issue Before This Commit:
============================
When only the quants/move line were changed without modifying the quantity,
the system automatically marked components as consumed (manual consumption
and picked boolean were set). This created confusion for the user since
no actual consumption took place.

Steps to Reproduce:
============================
- Install the `mrp` module.
- Create a tracked product (lot/serial) with quants.
- Create and confirm an MO having that product as a component.
- Change only the quants (e.g., location of the quant, not quantity);
  notice that manual consumption and picked boolean are set.

Cause of the Issue:
===========================
This issue occurs when clicking the 'Details' button (`action_show_details` 
method) on a stock move. That action passes the context `force_manual_consumption`, 
based on that which directly sets the `manual_consumption` and `picked` booleans in the 
`write` and `create` methods. [see](https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_move.py#L276).

With This Commit:
============================
Manual consumption and picked boolean are no longer set when only quants
(not quantity) are changed. Component consumption is now triggered only if
the quantity differs from the demand, ensuring consistency and avoiding
confusion for the user.

This fix avoids unintended behaviour by ensuring that the picked and manual
consumption booleans change only when the quantity differs from the demand.

TaskID:- 5062365

Forward-Port-Of: odoo/odoo#225386