Currently a `ParseError` arises when the user installs the modules after deleting the `Service` Category in Invoicing.

Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Categories > Delete `Service`
- Now installs the modules (event_product, sale, sale_timesheet)

Traceback:
---
```
ValueError: External ID not found in the system: product.product_category_services

ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/event_product/data/event_product_data.xml:4, somewhere inside <record id="product_category_events" model="product.category">
            <field name="parent_id" ref="product.product_category_services"/>
            <field name="name">Events</field>
        </record>
```

The error occurs because the user deleted the category, and then installed the modules, that reference the missing product category.

This commit resolves the error by providing a False value for the field if the product category is missing.

sentry-6235143606

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

Forward-Port-Of: odoo/odoo#198465

Steps to reproduce
------------------
- Create a product with price $80
- Create a fixed discount reward for this product with $40
- In PoS config, enable global discount
- In a new PoS order, add the product created in the first step and observe that we now have 2 orderlines, the product at $80 and the discount at $40. Total amount remaining to pay is $40
- Add a global discount of 50%

-> At this point, we are expecting to apply the 50% discount on the remaining $40, and hence, a discount of $20, which changes the order's total price to $20. We also expect the fixed discount line of $40 to remain at $40, as it's a fixed price discount.

Indeed, we now see a $20 global discount as an orderline, but the $40 fixed discount has changed its value from $40 to $53.33, and thus, the total amount has decreased to $6.67 instead of $20 -> A corrupted final amount!! In some other pricing configs, this final total amount will even become negative.

Reason
------
After applying the global discount, we recalculate the value of the discounts to keep everything in sync, so we recompute the discount value of the fixed $40 discount in `_getRewardLineValuesDiscount`, and since now the total amount to pay, i.e. `order.get_total_with_tax()` is less then the value of the product (due to the global discount), `discountFactor` [1] of the fixed discount increases since `discountable` decreases. However, at the end when we calculate the new `unit_price` of this fixed discount, we multiply the `discountFactor` by the intial product price, i.e. by the price before the global discount, and hence, the amount of the fixed tax will be higher than expected, causing this buggy behavior. Below is a math representation of the bad (current) vs good (new) behavior:

Bad:
discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount,
	       i.e. (80-40)*0.5
discountFactor = $40 / $60 = 0.666666
price_unit = 0.666666 * $80 = $53.3333 (instead of $40)

Good should be:
discountable = $60 = $80 - $20, where $20 is (total - fixed) * discount,
	       i.e. (80-40)*0.5
discountFactor = $40 / $60 = 0.666666
price_unit = 0.666666 * $60 = $40

I.e the good behavior should be multiplying the `discountFactor` by the the min of the remaining total price (after applying the global discount, so $60), and the initial value of the product (here $80).

The formula has been updated accordingly.

[1]: https://github.com/odoo/odoo/blob/76e2aa6b70d1fb03b8ce2f8e4a7e9c3d9425270f/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1163

opw-4622428

Forward-Port-Of: odoo/odoo#206426
Forward-Port-Of: odoo/odoo#202334

### Steps to reproduce:
- Create a storable product tracked by lot and avco valuated.
- Put 10 units of that product in stock withtout set lot.
- On the stock quant, click on history
- Modify the inventory adjustment move to set a quantity of 3 and a lot.
- Inventory > Reporting > Valuation
#### > Stock valuation layer inconsistency: +10, -10, -7, +3 > the -7 should not be there

### Cause of the issue:

If you change the quantity of a move line you will automatically reconcile the quantity difference because of these lines: https://github.com/odoo/odoo/blob/6f3f89f55ab67d39b2487fdf8220747f568b7eb0/addons/stock_account/models/stock_move_line.py#L34-L36 However, if you change the lot of your move line you already plan to conter balance the entire quantity of the previous lot because of these lines:
https://github.com/odoo/odoo/blob/6f3f89f55ab67d39b2487fdf8220747f568b7eb0/addons/stock_account/models/stock_move_line.py#L37-L46 In partciular, the first reconciliation should not be performed in case we change both the quantity and the lot of the move line.

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

Forward-Port-Of: odoo/odoo#204960

### [IMP] account: fix the summary of account.move.send.batch.wizard
*: account_peppol, snailmail_account

The summary was displaying wrong numbers of invoices.
Indeed, it was computed on default methods, instead of methods that are applicable
to the move. For example, if a move was not possible to send through Peppol because
the partner is not registered on the network, it was still displayed in the summary
of the batch sending (then not used when the async processing happened).

We also always put email as a fallback, even if no email is set, since it can
be added through the wizard.

task-no (review with TSB/PMAX)

----------------------------

### [FIX] account_peppol: Remove 'skipped' state of Peppol moves
This state doesn't really make sense. It only happens when there is
an error while generating the XML file to send, which can be considered
as a blocking error.

task-no

----------------------------

### [FIX] account_peppol: fix batch send of Peppol invoices when no format set

In previous commit[1], we set the BIS3 format on invoices that were meant to
be sent trough Peppol, even if no invoice_edi_format was set on the Partner.
This commit fixes some cases when sending multiple invoices with no
invoice_edi_format but Peppol as default sending method ended up
not being sent.

[1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad

task-no

Forward-Port-Of: odoo/odoo#206428
Forward-Port-Of: odoo/odoo#204419

This error occurs when a user creates multiple rewards of the same program using below steps :

Steps to Reproduce :

- Install module `sale_management` and `sale_loyalty.
- In Products, go to Discount & Loyalty.
- Create two new `Discount & Loyalty` with the program type `Coupons` and
 `Generate coupons. `
- Add multiple rewards to one coupon program.
- Create a sale order and apply a coupon code from the first Discount & Loyalty
  program. Repeat the process with the coupon code from the second program.

ValueError : Expected singleton: loyalty.reward(3, 4, 5)

This error occurs when the system tries to fetch global_rewards but receives multiple values instead of a single record.

This commit resolves the error by ensuring that only the global reward with the highest discount is selected.

Sentry - 6417784661

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

Forward-Port-Of: odoo/odoo#206535
Forward-Port-Of: odoo/odoo#202524

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

Since c18a7d2dc36d33134c5bdb1569865bd554e04130, the rentable forecast for future dates ignores the `rented_qty_during_period` if the setting "Rental transfers" is enabled. This happens because that rented quantity during period is supposed to be absorbed by the stock forecast: https://github.com/odoo/enterprise/blob/8ea5f4f9a0a907c57844c6274688171193f6a904/sale_stock_renting/models/sale_order_line.py#L132-L134 
However, the stock forecast of the 'virtual_available' relies solely on deliveries and receipt happening prior to the start of the renting period. Therefore the rental orders that are planned to start during the renting period should still contribute to the
`rented_qty_during_period` in that use case.

opw-4552760

Forward-Port-Of: odoo/enterprise#83262
Forward-Port-Of: odoo/enterprise#82172

*: l10n_br_edi, l10n_co_dian, l10n_mx_edi, l10n_uy_edi

1. fix the summary of account.move.send.batch.wizard

The summary was displaying wrong numbers of invoices. Indeed, it was computed on default methods, instead of methods that are applicable to the move. For example, if a move was not possible to send through Peppol because the partner is not registered on the network, it was still displayed in the summary of the batch sending (then not used when the async processing happened).

We also always put email as a fallback, even if no email is set, since it can be added through the wizard.

2. fix batch send of Peppol invoices when no format set

In previous commit[1], we set the BIS3 format on invoices that were meant to be sent trough Peppol, even if no invoice_edi_format was set on the Partner. This commit fixes some cases when sending multiple invoices with no invoice_edi_format but Peppol as default sending method ended up not being sent.

[1]: https://github.com/odoo/odoo/commit/84a0b81a258262e3bb9dbaa9c9f37796303a9dad

3. Remove 'skipped' state of Peppol moves

This state doesn't really make sense. It only happens when there is an error while generating the XML file to send, which can be considered as a blocking error.

task-no (review with TSB and PMAX)

Forward-Port-Of: odoo/enterprise#83601
Forward-Port-Of: odoo/enterprise#83443

Currently, a traceback is occurring when trying to approve a leave having
the same time off with the refused state of another leave.

<b>To reproduce this issue:</b>

1) Install planning_holidays without demo
2) Enable flexible hours for the working schedules of an employee 
3) Create two time-offs for an employee with the same date and time
4) Refuse the first one and try to approve the second one

<b>Issue:-</b>

```
ValueError: Expected singleton: hr.leave(5, 6)
```

When there are more than one leave record with different states, 
leave_date will search the record based on the employee, date and time only.

https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/planning_holidays/models/resource_calendar.py#L16-L24

So indeed we get multiple records, and this leads to the above traceback 
when accessing values from the leave_data.

<b>Solution:-</b>

Make the domain of leave_data more robust by including the state containing no refused leaves.

opw-4712858,4700495

Forward-Port-Of: odoo/enterprise#83354