The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Problem:
- In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant.

Current behaviour:
- Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient.

Expected behaviour:
- Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided.

Solution:
- Do not set ‘state=“open”’ for payment records created from a sale involving
  the data wizard for records. Ensure they remain in “draft”.
- Confirm registrations once attendee details are present.

Advantages:
- Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner.
- Meets functional expectations for administrative control and proper recipient targeting.

Tests to reproduce the error:
- Create quote with payment entry
- Confirm SO
- Enter attendee details and confirm
- Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee.

@Tecnativa TT58160

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

**Description of the issue/feature this PR addresses:**

Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time.

Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events.

**Current behavior before PR:**

Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer:
	•	the synchronization fails,
	•	and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo.

**Desired behavior after PR is merged:**

The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`.

If the parameter is not set, the behavior remains unchanged (default 3 seconds).
Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs.


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

**Steps to reproduce:**

- Install the `purchase_stock` module.
- Create a product and configure a Vendor Pricelist for a vendor.
Include a discount on the vendor pricelist line.
- Create a Purchase Order for the same vendor.
- In the Purchase Order, add a Purchase Order Line using 
the catalog (vendor catalog popup) and add a configured product.

**Observed behavior:**
- The unit price on the Purchase Order Line becomes vendor `unit price − discount`
The `discount` field remains empty, causing incorrect price calculations.

---
**Example**
---

Product-A  - > Vendor Price list - > Vendor - > Test Vendor, Unit price = 100 and discount 10

- Create PO with `Test Vendor` and add a Product to POL via catalog then

 **Current behavior:**
Product - A , qty - >1, unit price -> 90, discount->0% , subtotal ->90 

 **Expected behavior :**
Product-A , qty->1, unit_price->100, discount->10%, subtotal->90

---

**Cause:**
- The catalog selection applies the vendor pricelist discount directly to 
the unit price instead of populating the discount field.

**Fix:**
- Use the vendor pricelist's price as the `unit_price` and apply 
vendor pricelist discount to the discount field on the Purchase Order Line.

---
`NOTE` - This issue is resolved from version 18.2, In this [Commit](https://github.com/odoo/odoo/pull/227695/commits/6b91f393353bcdaeed076d58dcac3149ed587e77#diff-1281da5f4d0a3daaf162a2e6456469537d1b74b8034437783c9c717307aa8fcd)

---
opw-5217345

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

**Problem:**
When splitting a MO that has products with components tracked by
lots, the new MOs won't follow the removal strategy assigned to
said product. The first MO will have the first lot, and the
second MO will have the second lot, even if some products are still
available in the first lot. Once every lot has been used once,
the removal strategy is applied as intended on the remaining MOs.

**Steps to reproduce:**
- Make a product, that has a BoM with a component that is tracked by lots
- Make two lots for this components
- Set the removal strategy for this component to FIFO (or another one)
- Make a manufacturing order with quantity high enough to use multiple lots
- Confirm the MO and then split it in as much parts as components were used
- Look at the lot of the second MO, it is the second lot, even though there are still components available in the first lot

**Cause of the issue:**
The removal strategy was not taken into account as a whole
when splitting the MO. Thus resulting in values that seems
kind of random. As the components were assigned one at a time
to the backorders, they did not synchronize between
themselves before being assigned, which explains why they
did not have a correct lot assigned.

**Fix:**
As the components are assigned one at a time during the MO
splitting, it is not an option to try and sort them according
to the removal strategy during the assignation. We instead
wait for all of the components to be assigned (in a wrong way)
then unassign them all just to assign them the right way right
afterwards. This is done by calling *_action_assign* which takes
the removal strategy into account. This time around, all the
components are assigned at them same time, making the
removal strategy applicable.

opw-4678932

**Steps to reproduce:**
* Install the **l10n_ch** module for a Swiss company.
* Create a vendor bill for a **foreign vendor**.
* Apply a reverse charge tax:
  * **8.1% R C** (figure **383a**), or
  * **7.7% R C** (figure **382a**).
* Confirm the vendor bill.
* Go to **Accounting → Reporting → Tax Report**.
* Generate the VAT report for the relevant period.

**Observed behavior:**
* Figure **383a** (8.1% reverse charge) is reported as **negative**.
* Figure **382a** (7.7% reverse charge) is reported as **negative**.
* This results in incorrect VAT reporting.

**Cause:**
* Reverse charge taxes use **negative tax rates** to model the reverse mechanism.
* The base amounts were tagged with **positive** signs, leading to negative values in the report.

**Fix:**
* Invert the base tax tag signs for reverse charge taxes:
  * **382a**: change base tag from `-382a` to `+382a`.
  * **383a**: change base tag from `-383a` to `+383a`.
* Reverse charge base amounts now appear as **positive** values in the VAT report.

opw-5257445