Currently an error occurs when user quick creates a picking type and tries to create a  receipt with it.

**Steps to replicate:**
- Install stock.
- Go to Inventory > Receipts and create a new receipt > Save it.
- Clear the Operation Type field, type `test` and quick create it.
- Save and the error will occur.

**Error:**
```
UndefinedFunction: operator does not exist: integer = boolean
LINE 1: SELECT number_next FROM ir_sequence WHERE id=false FOR UPDAT...
```

**Cause:**
- As the user quick created the picking type, the `sequence_code` field was not set and it is a required field [1], when we try to get `next_number` to create the name for the current stock picking this error occurs.

- In the versions before `saas-19.1` trying to quick create picking type will lead to a `Not-Null Violation` as `sequence_code` is a required field and then stock picking type form view will open up.

- This error occurs only after `saas-19.1` and above versions because this [PR] made the `sequence_code` field into a related field so its required constraint was removed and hence quick create creates a new picking type.

**Solution:**
- Disabled quick create for stock picking type in multiple views.

[1]: https://github.com/odoo/odoo/blob/fe0550ad23ff9128099e7e4994938879a971dcc8/addons/stock/views/stock_picking_type_views.xml#L93

[PR]: https://github.com/odoo/odoo/pull/190305/changes#diff-79cbc763115661182c02285c07320098510f5686700359ddee67443b4893dc30L32-R32

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

### Issue:
When a Sale Order is delivered but later reimbursed (e.g., via a credit note without a return), it is still considered as to invoice
As a result, it continues to impact the partner’s credit limit

### Cause:
Sale Orders remain included in the `credit_to_invoice` computation even when invoicing is manually considered finished
There was no way to exclude such orders from the credit limit calculation

### Fix:
Use the `invoicing_closed` field to mark Sale Orders as fully processed
When set, the order is excluded from the credit limit computation

### Steps to reproduce:
- Install `sale_management`
- In Settings, enable Sales Credit Limit (default: 3000)
- Create, confirm, and deliver a Sale Order for a new customer (any product, price: 2000)
- Duplicate the Sale Order → a credit warning is displayed
- Go back to the original Sale Order and use Close Invoicing from the gear menu
- Return to the duplicated Sale Order
The warning disappears as the closed order is no longer included in the credit computation

### Note:
For a complete business scenario, refer to the steps described in the related ticket

opw-6013369

Version:
---------
- 19.0+

Steps to reproduce:
--------------------

1.Install modules `sale_management`, `purchase`, and `mrp`.
2. Go to Settings and enable the MTO (Replenish on Order) route.
3. Create a product with:

       i. Configure a Vendor under the Purchase tab.
      ii. Set the route to MTO.
     iii. Create a Bill of Materials for the product.
5. Create a Sale Order with the configured product and confirm it.
6. Open the generated Manufacturing Order.
7. Duplicate the Manufacturing Order.

Issue:
------

* The duplicated Manufacturing Order shows a smart button
linked with the Sale Order, which is incorrect.

Root Cause:
------------
 This issue is coming form this [Commit](https://github.com/odoo/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a#diff-2b9de2e50ff5e1dc0362b825bac2b07623770fb3275b3257ef972f255f3ccb8b) 

* During Sale Order confirmation, the flow
`action_confirm` → `_action_confirm` → `_action_launch_stock_rule`
→ `run` → `_run_pull` → `_action_confirm` calls
`_prepare_procurement_values`.
which gather all procurement values.
In sale_stock, the super call adds `sale_line_id` to the
generated Manufacturing Order when using MTO:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/sale_stock/models/stock.py#L138-L140

* So, when the Sale Order is confirmed, the generated
Manufacturing Order contains sale_line_id, and when this
Manufacturing Order is duplicated, the sale_line_id is also
copied.

* In sale_mrp, the smart button uses sale_line_id to compute
the linked Sale Order count:
https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/sale_mrp/models/mrp_production.py#L19

Solution:
-----------
* Prevent copying of sale_line_id when duplicating a
Manufacturing Order, ensuring duplicated records are not
linked to any Sale Order.

---

opw-6113149


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

Forward-Port-Of: odoo/odoo#259128

Sending the final invoice of a sale order to ZATCA crashed with `ValueError: Expected singleton: account.move(a, b)` when the sale order had multiple down-payment references.

Steps to reproduce:
1. Configure a SA company and setup ZATCA
2. Create a sale order and confirm it
3. Deliver the product line.
3. From the sale order, create a down-payment invoice (fixed amount, e.g. 115) and post it (DP1).
4. On DP1, click "Credit Note" and choose "Full refund and new draft invoice"; validate. DP1 becomes `reversed` and a new draft down-payment DP2 is created. Post DP2.
5. From the sale order, create the final regular invoice and post it.
6. Send the final invoice to ZATCA (or generate its XML) -> `ValueError: Expected singleton: account.move(a, b)`.

Root cause: _l10n_sa_get_line_prepayment_vals looks up the related down-payment move through the down-payment sale order line shared with the product line. The filter matched any out_invoice with _is_downpayment() == True, so the reversed DP1 and the active DP2 both ended up in the recordset, and reading .name raised the singleton error.

Prefer non-reversed down-payment moves when available, but fall back to reversed ones if no alternative exists (e.g.
when generating a credit note of the final invoice after the original down-payment was itself reversed).

opw-6116265

Forward-Port-Of: odoo/odoo#264435
Forward-Port-Of: odoo/odoo#259384

**Description of the issue/feature this PR addresses:**
This PR fixes an "Invalid Operation" UserError during the Bill Matching process. The error occurs when Odoo attempts to call the line addition method on a Posted Vendor Bill, even when there are no new residual lines to add. This triggers a write attempt on read-only fields (such as invoice_line_ids) of a validated account move, which is prohibited by Odoo’s ORM.

Furthermore, this addresses a functional inconsistency: Odoo allows users to select "Posted" bills in the matching view, but the underlying code is not prepared to handle a "zero residual" scenario on a validated move. If Odoo intends to prevent matching on posted bills, they should be filtered out from the view; since they are available to select, the system must be able to process them when no further modifications to the accounting entries are required.

**Current behavior before PR:**
When performing a match between a posted Vendor Bill and Purchase Order lines where the "residual" (lines left to add) is zero:

The system executes _add_purchase_order_lines() regardless of whether the recordset of lines is empty.
Odoo's ORM detects an update attempt on a posted record.
A UserError is raised: "You cannot modify the following readonly fields on a posted move: invoice_line_ids".
This blocks the user from completing the matching process even if the lines are already technically accounted for.

**Desired behavior after PR is merged:**
The system will check if residual_purchase_order_lines contains any records before attempting to update the bill.
If there are no lines to add, the method call is skipped.
The matching process completes successfully without attempting an illegal write on a posted move.

**Steps to Reproduce**
1) Create a Purchase Order (PO): Add a product (e.g., "Acoustic Bloc Screens") and confirm the order.
2) Create a Vendor Bill manually: Do not use the "Create Bill" button from the PO. Instead, go to Accounting -> Vendors -> Bills and create a new bill for the same vendor and product.
3) Post the Bill: Set a bill date and click Confirm to move it to the "Posted" state.
4) Open Bill Matching: Go back to the Purchase Order and click the Bill Matching button (or navigate to the matching view).
5) Select Lines: Select the PO line and the corresponding Bill line (which are already equal in quantity/price).
6) Trigger the Match: Click on the Match button.

Observe Error: An "Invalid Operation" popup appears, preventing the link because Odoo tries to "add" zero lines to a posted invoice.


**Video:**
https://drive.google.com/file/d/12aeZIx1JRRSKA9TaWfXy0TeSOgMUMQcg/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#241171

Steps to reproduce:
- Install `Accounting` module
- Search `Analytic Report` > Click on `Total` > `Custom Group`
- Select `Journal Item` > Now again close and select `Journal Item`

Traceback:
```js
TypeError: Cannot destructure property 'fieldName' of 'searchItems.find(...)' as it is undefined.
    at AnalyticPivotRenderer.onGroupBySelected (http://localhost:8069/web/assets/3b7bf10/web.assets_backend_lazy_dark.min.js:434:7)
    at Object.onSelected (eval at compile (http://localhost:8069/web/assets/b0799bf/web.assets_web.min.js:1376:421), <anonymous>:78:62)
    at DropdownItem.onClick (http://localhost:8069/web/assets/b0799bf/web.assets_web.min.js:2373:24)
 ```

Cause:
Custom groupBys were not being added to the search items list in `onGroupBySelected`, causing a lookup failure when selecting a custom groupBy from the dropdown.

Solution:
Added custom groupBys to the search items list so they can be found and applied correctly.

opw-6227164

Forward-Port-Of: odoo/odoo#265810

**Steps to reproduce**
1. Create a customer invoice with Invoice Date `2025-05-27` and accounting Date `2026-05-04`.
2. On the *Other Info* tab, set the Delivery Date to `2026-05-04` and post the invoice.
3. Generate the FA(3) XML.

**Issue**
`P_6` is omitted from the payload even though the delivery date differs from the invoice issue date.

The FA(3) information sheet (Warsaw, September 2025, binding from 1 February 2026) defines `P_6` as *"the date of delivery [...] if such date is specified and differs from the date of issue of the invoice"*, where the date of issue is `P_1` (Art. 106e sec. 1 item 1 of the VAT Act). In Odoo `P_1` maps to `invoice_date`, but the template at
https://github.com/odoo/odoo/blob/4890b8021af2a5c025944220043d295bb7bbbb9b/addons/l10n_pl_edi/data/fa3_template.xml#L132 compares `delivery_date` against `invoice.date`, the accounting/entry date. When the invoice is posted on the delivery day the accounting date equals the delivery date, the guard evaluates to false, and `P_6` is wrongly dropped.

Comparing against `invoice.invoice_date` aligns the guard with `P_1` as the spec requires.

Ticket [link](https://www.odoo.com/odoo/project.task/6211119)
opw-6211119

Forward-Port-Of: odoo/odoo#266667

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.

Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212



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

Forward-Port-Of: odoo/odoo#256636

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.
Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212

Forward-Port-Of: odoo/enterprise#112482

__

## Short functional explanation of the error
When rescheduling the deadline only of a task that has dependencies, other dependencies won't be moved in time, even if we select `Auto-Reschedule (Keep Buffer)`.

## Reproduction Steps
1. Go to Project. On a given project, click on the 3 dots on the top right of the project card. Then, click settings and under Task Management, check Task Dependencies.
2. Create 2 tasks for this project. On task 1, click on the Deadline field, then click on the top right of the calendar card to set a planned date.
3. On task 2, click on the Blocked By tab. Then, add a line with task 1. Select a planned date like you did with task 1.
4. Go back to the project and on the top right, click on the Gantt view. Make sure that above the calendar, the Auto-Reschedule (Keep Buffer) option is selected. Then, move forward (or backward) the deadline of task 1 by only clicking on the right edge of the pill and dragging/dropping it to the left/right.

### Expected behavior
As task 2 depends on task 1, and we need to keep the buffer. The start date of task 2 should be moved left when we drop the deadline of task 1 further left, or right when we move the deadline of task 1 further right.

### Unexpected behavior
Nothing happens.

## Origin of the issue
### JS side
When we click on the whole task 1 and drag it to the right (thus changing the start date *and* the deadline), the dependent tasks are also moved right. When performing this action, this calls the method `dragPillDrop`. In it, we can see this piece of code: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L1484-L1489 where `this.isAutoPlan` indicates whether we checked the Auto-Reschedule (Keep Buffer) option. In that case, we call `rescheduleAccordingToDependency`, which performs this ORM call: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L500

However, when only moving the deadline of the task, we call the method `resizePillDrop`. In this method, we don't check if `this.isAutoPlan` is True, as we perform in all case the call to: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L2822 Which will trigger the orm call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L479 which will call the `web_gantt_write` method in Python, only writing on the task we changed the deadline of.

### PY side
Inside `web_gantt_reschedule`, to reschedule dependent tasks, we have to reach the method call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L247 However, there's a condition preventing us from reaching that code when only changing the deadline:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L230-L235 Yet, we need to trigger the code and reschedule dependencies even if there's no planned date as soon as we change the deadline.

Once we're in `_web_gantt_action_reschedule_candidates`, we check if we're in the case of preponing or postponing the task (i.e the direction of the rescheduling):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L410 This call is performed with `start_date_field_name`, which is present in the `vals` in the case of moving a whole task. Yet, in our case, we only move the deadline, so `start_date_field_name` isn't in our `vals`. So, to get the direction of our rescheduling, we have to use `stop_date_field_name` instead.

Then, we perform this call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L412 However, in our case, the dependent tasks are still found under the `dependency_inverted_field_name` field.

This leads us to the return of the function, where we call `_web_gantt_move_candidates`. In it, we retrieve the previous values of the pill we're modifying with:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1366 using `vals`. Later we use `start_date_field_name` to update the dates of dependent tasks:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1413-L1415 Still, in our case, we don't have `start_date_field_name` in vals. Thus, we have to define `old_vals_per_pill_id[self.id][start_date_field_name]`.

Next, we define the start date and end date of the intervals in which we reschedule the dependent tasks (so, the left and right bounds of intervals):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1392-L1401 In case of a `search_forward`, this is natural. Nevertheless, in the case of a backwards search, we can't consider the start date of the first task to be the right bound for our dependent tasks, as they occur after the first task! This would mean that our right bound is set before the dependent tasks even start. So, in our case of changing only a deadline, we have to set the right bound to the latest deadline of the dependent tasks. They won't be set to later, as we are moving the deadline backward.

Finally, in the case of setting a deadline backwards, we have to keep the time gap between task 1 and the dependent tasks, based on the working hours. This feature wasn't implemented.

__
opw-6080405

Forward-Port-Of: odoo/enterprise#113787

Issue
Upon initialization of the pos a PaymentInterface is constructed for every pos_payment_method (even archived pos payment methods ?!). [As we allow only one WebSocket subscription per channel](https://github.com/odoo/odoo/blob/4e1c89890c5fd54a79dcf5bf20268e51d8fe6e69/addons/point_of_sale/static/src/app/utils/payment/payment_interface.js#L100) for the PaymentInterface, all webhook responses will be linked to only one PaymentInterface. Meaning that when you have two Mercado Pago pos_payment_method terminals configured, only the first pos_payment_method (id=1) will be subscribed to the WebSocket and all the webhook responses from the second pos_payment_method terminal (id=2) will arrive to the PayementInterface of the first pos_payment_method (id=1). Where payload.payment_method_id (id=2) != this.payment_method_id.id (id=1).

Solution
- Only iterate and create a PaymentInterface for compatible pos_payment_methods which are active
- Check if the webhook response is linked to the PendingPaymentLine

opw-6069455

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

Prevent an internal server error when a customer cancels a Redsys payment
and returns to Odoo.

Current behavior before PR:

When the customer cancels the payment from the Redsys checkout page,
Redsys redirects back to Odoo without the `Ds_MerchantParameters`
parameter.

The payment flow assumes the parameter is always present and tries to
decode it unconditionally, causing an internal server error.

Desired behavior after PR is merged:

Odoo gracefully handles payment cancellations when
`Ds_MerchantParameters` is missing from the callback parameters.

The customer is redirected correctly without triggering a server error.

Steps to reproduce:

1. Install the Redsys payment provider.
2. Configure a test environment.
3. Create a sales order or invoice.
4. Start the payment process.
5. Cancel the payment from the Redsys checkout page.
6. Return to Odoo.
7. Observe the internal server error caused by the missing
   `Ds_MerchantParameters` parameter.


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

Forward-Port-Of: odoo/odoo#265655

Currently an error is generated when the user tries to cancel a
draft POS order as follows:

- Install the `pos_enterprise` module with demo data
- Open the register of `Furniture store` and select any product
- Click on the `Upload` icon to save the draft order and go to the backend.
- Navigate Orders > Orders > open Draft order
- Click the `cog` icon and click `Cancel Order` >>> Error occurs

This issue is caused by the recent refactor introduced in [1]. The
`action_pos_order_cancel` action now returns the `order`
(`pos.order` recordset) instead of default returning `None`.

As a result, the `action` variable contains a `pos.order` recordset, and
an error is raised at line [2] when `setdefault` is called on it, since
`setdefault` expects a dictionary-like object.

This commit fixes the above issue by removing the code that returns the
`pos.order` object from the action. As a result, the action now behaves
as expected and returns the default value (`None`).


[1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93
[2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24

Sentry-7354160052

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

Forward-Port-Of: odoo/odoo#264294

Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines.

Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10)
= 98.889
This does not equal the expected outcome of $100.

Expected Behavior: Based on the previous example, the formula for the calculation should be:
(raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9
= 100
The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts.

Steps to reproduce the issue:
- Bug was encountered when implementing a global discount solution for l10n_co_dian.
- Create an invoice with a product line and in-line discount and another line for global discount
- Setup the base lines for the invoice and attempt the following:
 - _dispatch_global_discount_lines
 - _squash_global_discount_lines
 - _add_and_round_raw_gross_total_excluded_and_discount

opw-5412446


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

Forward-Port-Of: odoo/odoo#266584
Forward-Port-Of: odoo/odoo#262137