When an expense is manually created, the document is sent to the OCR,
and the ocr modifies the values of the document.

The issue is that the user cannot see that values have been modified and
submit the expense with the wrong values (the ones returned by OCR which
are not displayed on the form during submission).

So to avoid such behaviour, we've made different fixes:
- We display the banner that it has been sent to the OCR immediatly (not
  after a refresh)
- We make work the refresh button diplayed in the banner
- We don't change the name and/or product of the expense if the name of
  the expense has been entered manually (to know that we check if the
  name is the generated one when we create from attachment or not)
- We don't modify the status of the expense to draft (if it has been
  submited before the response of the OCR we don't want modifications)

The test have been modified the use case, because to correctly work if
the expense is sent to the OCR, it means that there is an attachment
linked to this PR.
Also when we want to check the completion of the OCR, the attachment
name is set as expense name (expense name is required)

The issue comes from an internal feedback

Forward-Port-Of: odoo/enterprise#84897

Creating a temporary table each time reports are requested can lead to timeouts when there are millions of records inserted. This issue prevents clients from upgrading to 18.0, otherwise the reporting feature would be unusable for them. DBs already in 18.0 for which the issue is not happening at the moment will stop working as soon as enough data is added to the DB.

In this patch we propose to switch to a view-based approach. This doesn't create any new data, and it is able to use exiting indexes. The timing goes from minutes to seconds. The frontend is usable again.

Example of the data stored in the temp table:
```
=> select count(*) from analytic_temp_account_move_line
+----------+
| count    |
|----------|
| 60669759 |
+----------+
```

The example DB has 31 "plan columns". In other words we are duplicating 31 times 1957089 rows. That's too much data. It's also a waste of space and time. Especially if we later issue more filtering commands as the report is refined in the frontend. This leads to current approach being unusable for some clients. In the example DB the timing is bigger than the standard timeout for frontend requests.

Planning and execution of for the insert in the temporary table:
```
Insert on analytic_temp_account_move_line  (cost=0.86..6659742.75 rows=0 width=0) (actual time=209651.484..209651.487 rows=0 loops=1)
  ->  Subquery Scan on "*SELECT*"  (cost=0.86..6659742.75 rows=157594266 width=548) (actual time=644.693..92507.579 rows=60669759 loops=1)
        ->  Result  (cost=0.86..5083800.09 rows=157594266 width=548) (actual time=644.689..85762.552 rows=60669759 loops=1)
              ->  ProjectSet  (cost=0.86..1143943.44 rows=157594266 width=366) (actual time=644.657..72959.699 rows=60669759 loops=1)
                    ->  Merge Left Join  (cost=0.86..317844.46 rows=5083686 width=486) (actual time=644.562..22711.962 rows=1957089 loops=1)
                          Merge Cond: (account_analytic_line.move_line_id = account_move_line.id)
                          ->  Index Scan using account_analytic_line__move_line_id_index on account_analytic_line  (cost=0.43..97499.67 rows=1957619 width=150) (actual time=641.529..7738.521 rows=1957089 loops=1)
                                Filter: (general_account_id IS NOT NULL)
                                Rows Removed by Filter: 136994
                          ->  Materialize  (cost=0.43..144877.29 rows=2272735 width=344) (actual time=3.014..13564.293 rows=3022715 loops=1)
                                ->  Index Scan using account_move_line_pkey on account_move_line  (cost=0.43..139195.45 rows=2272735 width=344) (actual time=3.005..11312.577 rows=2274827 loops=1)
Planning Time: 132.775 ms
JIT:
  Functions: 78
  Options: Inlining true, Optimization true, Expressions true, Deforming true
  Timing: Generation 4.236 ms (Deform 2.533 ms), Inlining 64.617 ms, Optimization 351.121 ms, Emission 222.715 ms, Total 642.690 ms
Execution Time: 209672.536 ms
```

Planning and execution of a query based on the new view (note the usage of indexes from the actual tables):
```
Hash Join  (cost=72813.40..294958.00 rows=7724 width=4) (actual time=1760.970..3493.933 rows=61 loops=1)
  Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
  ->  Subquery Scan on account_move_line  (cost=72794.39..294349.71 rows=223360 width=8) (actual time=1725.998..3477.187 rows=246 loops=1)
        Filter: (account_move_line.analytic_distribution = ANY ('{1703,898,896,890,648,670,673,685,818,899,828,837,846,849,848,891,901,904,905,906,907,942,952,1039,980,985,1049,1050,1051,1093,1107,1114,1233,1126,1129,1133,1151,1152,1153,1222,1272,1218,1230,1243,1282,1249,1369,1271,1286,1328,1371,1396,1432,1403,1404,1406,1409,1430,1431,1437,1449,1473,1498,1515,1516,1517,1524,1525,1527,1528,1543,1549,1588,1592,1604,1605,1784,1641,1650,1652,1676,1677,1678,1679,1680,1702,1751,1759,1760,1767,1964,1796,1826,1832,1838,1926,1866,1883,1916,1922,1923,1954,1963,2144,1977,1974,2005,2011,2013,2015,2016,2032,2035,2037,2038,2064,2142,2097,2106,2110,2111,2112,2115,2121,2122,2130,2131,2141,2157,2311,2251,2252,2263,2269,2270,2271,2272,2274,2275,2279,2280,2287,2300,2307,2312,2316,2330,2339,2720,2370,2372,2423,2439,2462,2494,2477,2478,2480,2483,2491,2492,2493,2537,2533,2534,2535,2536,2546,2550,2551,2573,2574,2575,2576,2587,2598,2658,2691,2710,2721,2763}'::jsonb[]))
        Rows Removed by Filter: 2617642
        ->  Gather  (cost=72793.94..290647.16 rows=246807 width=910) (actual time=1720.216..3369.512 rows=2617888 loops=1)
              Workers Planned: 1
              Workers Launched: 1
              ->  Result  (cost=71793.94..264966.46 rows=4500611 width=910) (actual time=1706.592..2884.302 rows=1308944 loops=2)
                    ->  ProjectSet  (cost=71793.94..197457.29 rows=4500611 width=12) (actual time=1706.573..2654.189 rows=1308944 loops=2)
                          ->  Parallel Hash Join  (cost=71793.94..173865.38 rows=145181 width=132) (actual time=1706.560..2554.799 rows=42224 loops=2)
                                Hash Cond: (account_move_line_1.id = account_analytic_line.move_line_id)
                                ->  Parallel Index Scan using account_move_line__journal_id_index on account_move_line account_move_line_1  (cost=0.43..100906.82 rows=149368 width=4) (actual time=2.633..788.321 rows=126675 loops=2)
                                      Index Cond: (journal_id = ANY ('{23,21,17}'::integer[]))
                                ->  Parallel Hash  (cost=67363.05..67363.05 rows=354437 width=136) (actual time=1699.502..1699.503 rows=421304 loops=2)
                                      Buckets: 1048576  Batches: 1  Memory Usage: 54880kB
                                      ->  Parallel Index Scan using account_analytic_line__date_index on account_analytic_line  (cost=0.43..67363.05 rows=354437 width=136) (actual time=9.963..1507.693 rows=421304 loops=2)
                                            Index Cond: ((date <= '2024-12-31'::date) AND (date >= '2024-01-01'::date))
                                            Filter: ((general_account_id IS NOT NULL) AND (company_id = 3))
                                            Rows Removed by Filter: 57954
  ->  Hash  (cost=18.65..18.65 rows=29 width=4) (actual time=16.619..16.620 rows=29 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 10kB
        ->  Index Scan using account_account__account_type_index on account_account account_move_line__account_id  (cost=0.15..18.65 rows=29 width=4) (actual time=16.513..16.592 rows=29 loops=1)
              Index Cond: ((account_type)::text = 'income'::text)
Planning Time: 75.050 ms
JIT:
  Functions: 51
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 4.433 ms (Deform 2.707 ms), Inlining 0.000 ms, Optimization 2.501 ms, Emission 30.127 ms, Total 37.061 ms
Execution Time: 3496.425 ms
```

OPW-4782916

Forward-Port-Of: odoo/enterprise#85942

Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error:

```
Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')
at ActivityListPopoverItem.template
```

This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly on returned RPCs. The code of VOIP returns activity data with a custom formatter, which omits `persona` that is important for the good templating of an activity in Chatter otherwise there's the crash above.

A recent PR [1] attempted to fix this issue, but the syntax for Store was wrong: it used the syntax for an item in field list (e.g. in `_to_store_defaults`) instead of pure store data from a specific record. This bad use of Store.One() resulted in actually returning `False`.

[1]: https://github.com/odoo/enterprise/pull/84970

opw-4586756

Forward-Port-Of: odoo/enterprise#86037
Forward-Port-Of: odoo/enterprise#85907

1. Create a quote using a quote template that uses the quote calculator (e.g. the demo one, works fine),
2. Modify it using the quote calculator,
3. Duplicate it,
4. Open the quote calculator in the new quote -> it's filled with default values instead of the one from the other quote you dpulicated one could expect after duplication (and so if you save without changing anything in the spreadsheet, you 'reset' the quote even though it's probably not what you wanted to do),

Expected behaviour: the quote calculator spreadsheet is duplicated for the new quote with the same values.

Implementation note:
Why not just `copy=True` on field `spreadsheet_ids`?

Because the spreadsheet should be copied, but not only! The `spreadsheet.revision` linked to the spreadsheet also need to be copied.

If they are not copied, revisions which are not part of the last snapshot will be lost on the new spreadsheet record and it won't lead to the same spreadsheet data.

Task: 4801418

Forward-Port-Of: odoo/enterprise#86017
Forward-Port-Of: odoo/enterprise#85746

## Description

This PR fixes several issues related to comments in spreadsheet cells:

- **Dark Mode Styling**  
  The comment styles were broken in dark mode because the dark SCSS file was in the wrong asset bundle. It's now removed from `assets_backend` and added to `assets_web_dark` to fix the issue.

- **Focus Issue When Using Keyboard**  
  When using the keyboard to move around the spreadsheet, opening a comment popup would focus the composer, stopping navigation. The composer now doesn’t take focus, so keyboard navigation keeps working smoothly.

- **Upload Button & Error Fixes**  
  - The upload button was showing for spreadsheet cell comments but didn’t work. It’s now hidden.  
  - There was also an error when editing a comment because `this.thread` wasn’t always available. Now it falls back to `this.message?.thread` when editing the message.

- **Popover Visibility Fix**  
  When posting the first comment and hovering over it, the action buttons (edit, favorite, delete) were partly cut off. This is now fixed by adding some padding to the thread style.
![image](https://github.com/user-attachments/assets/da774829-9fac-4ae0-a91a-6381c2404471)




**Task**: [4708400](https://www.odoo.com/odoo/project/2328/tasks/4708400)

Forward-Port-Of: odoo/enterprise#86032
Forward-Port-Of: odoo/enterprise#83410

**Steps to reproduce:**
With mexican localisation installed:
- Open form view for the model 'l10n_mx_edi.document'
- Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd)
- Remove existing attachment
- Change the attachment on the document to the relatively long XML file

**Issue:**
After saving the change, the attachment_uuid (Fiscal Folio) is left blank.

**Cause:**
Normally, the uuid should be extracted from the uploaded attachment, but
the computation of the 'raw' field on the attachment returns the value
"b'56.00 bytes'", leaving the attachment_uuid field empty because the XML
is assumed to be in the wrong format.
The issue doesn't exist for shorter XML files in the Payment-10 format
(https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd)

**Solution:**
Before computing the attachment_uuid from the attachment, we set the
bin_size to False in the context.

opw-4641487

Forward-Port-Of: odoo/enterprise#83538

This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval.

Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:00 and 05:00 respecively, up to a 1-hour difference for daylight savings time. Now suppose that the paysliip for this work entry only goes up to that following morning. Instead of using the local times of 18:00 and 01:00, the payslip would use the UTC times of 22:00 and 05:00, which would only count 2 of those hours instead of 6.

This is resolved by converting the UTC times to local before using them to clamp the work entries to the payslip interval.

opw-4790119

Forward-Port-Of: odoo/enterprise#85967
Forward-Port-Of: odoo/enterprise#85548

**Problem:**
For products with variants and differents steps for the BoM depending
on the variant, the Manufacturing Order overview for a given product
with a given variant would display the sum of the cost of all variants
possible for this product. If we had a product "Drawer" with a color
variant "Black" and "White", which cost 10 and 20 euros respectively,
the Manufacturing Order overview of a Black Drawer would display the
cost of the drawer + **30** euros (10+20), instead of being the cost
of the drawer + **10** euros. The display cost is the sum of the price
of every variants for this product, instead of being the price of the
current variant of the product.

**Steps to reproduce:**
- Create a product with variants
- Change the BoM and make some components needed only for certain variants and add a price for them
- Go to the MO overview
- The Cost BoM cost total is the sum of all prices AND variants

**Cause of the issue:**
https://github.com/odoo/odoo/blob/d3ab7b2c3ceddbb4cb8d8e91fac0d60e28e5673a/addons/mrp/report/mrp_report_mo_overview.py#L85
This treats every remaining lines of the BoM as a missing component,
thus adding it's price to the total price. Some lines should only be
applied if a specific variant is selected, but with this code, every
line that has a condition depending on variants will be taken in.

**Fix:**
Before adding the product of a BoM line to the missing components, we
check that the BoM line should be applied to the current variant.
The missing components are still used and can be not empty in the
case where the BoM includes a line that was deleted from the MO,
making the MO cost and the BoM cost different. In this case, the
missing components will not be empty and will still work as
intended without taking the unwanted variants into account.

opw-4557169

When a signed document is moved to trash in the documents app, when the cron tries to delete the said document it should raise a foreign key violation error in the terminal not in UI.

**Steps to reproduce:**
* Install document and sign
* Document App> all> click `Employment contract.pdf`.
* Select sign>drag and drop Signature>Sign now
* Sign the document>validate and send completed document
* Documents>certificate of completion or the signed document>actions>trash
* The error will be produced when cron deletes the document.
* You can delete the document from trash to see what error will be displayed by cron.
  
 `ERROR: update or delete on table "ir_attachment" violates foreign key constraint "sign_request_completed_document_rel_ir_attachment_id_fkey" on table "sign_request_completed_document_rel"`
 
**Solution:**
* Modifying the domain for `_gc_clear_bin` via a new function called overridden `_gc_documents_domain` in `documents_sign` this will allow for cron to skip over signed required document during unlink process.
* This will still throw an `Validation Error` when the user tries to delete it from the GUI letting them know it cannot be deleted.

Sentry-6225030131

**Issue**
In the Mexican localization, the CFDI usage (`l10n_mx_edi_usage`) field is not visible on POS orders in the backend. This prevents users from selecting or modifying the usage when manually generating an invoice from the POS order.

**Steps to Reproduce**
1. Install the Point of Sale app and the Mexican localization (l10n_mx)
2. Complete a POS order without generating an invoice
3. In the backend, go to Point of Sale > Orders > Orders
4. Open the newly created order
5. Notice that the CFDI Usage field is missing

**Root Cause**
The usage field is given a default value at the model level: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L65-L70 However, this value gets lost during the order processing flow. When an invoice is requested directly from the POS UI, the usage is explicitly set in the `sync_from_ui` method: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L110-L112 But if no invoice is requested at the time of the order, the usage is not preserved or restored in the backend. 

**Fix**
Explicitly set the CFDI usage to its default value when an invoice is not requested during the POS flow. This ensures the usage field is retained and displayed properly in the backend, allowing users to create invoices manually.

opw-4776487

### Steps to reproduce:

- In the settings enable Multi-Step routes
- Unarchive the MTO route
- Create a storable product using the MTO and buy route
- Create and confirm a sale order for 100 units of that product
- Validate the delivery for only 30 units and backorder the rest
#### > The purchase order demand was updated to 170 units

### Cause of the issue:

Processing the backorder wizard will create and confirm moves for the backorder picking:
https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1916-L1919 However, as these moves are `make_to_order` they are planned to create and run procurements in their respective `_action_confirm`'s: https://github.com/odoo/odoo/blob/a71c0c7d1c3391beb1bf2939ae076a804a627dbd/addons/stock/models/stock_move.py#L1379-L1388

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

Forward-Port-Of: odoo/odoo#209924
Forward-Port-Of: odoo/odoo#209442

The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not support `SUM(timestamp)` — `SUM` can only be used with numeric types such as integer, float, or monetary.

Steps to reproduce:
---
- Install `Gamification` and `hr_appraisal` modules
- Create a Gamification Challenge, and also create a Goal Definition and set `Computation Mode` -> `Sum`, `Model` -> `Appraisal Goal`, `Field to Sum` -> `Created on (Appraisal Goal)`, `Filter Domain` -> `[]`
- `Start Challenge` in Gamification Challenge

Traceback:
---
```
UndefinedFunction
function sum(timestamp without time zone) does not exist LINE 1: SELECT SUM("hr_appraisal_goal"."create_date") FROM "hr_appra...
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
```

To fix this, we now check the field type before applying aggregation. If the computation mode is set to `sum` but the field is not numeric, we gracefully fallback to using `count` instead. This prevents SQL errors and ensures that goal computations remain reliable even with misconfigured definitions.

sentry-6575130734

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

Forward-Port-Of: odoo/odoo#208077

### Steps to reproduce:
	- Navigate to Recruitment > Job Position > Any job position > Job applications (smart button)
	- Create an applicant
	- Set a Recruiter for the applicant
	- Move the stage to 'Contract Signed'
	- Click on 'Create Employee'
	- Notice a validation error that the opertion cannot be completed

### Cause:
This is happening as the 'Job applications' smart button has default value for the user_id in context

https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr_recruitment/views/hr_job_views.xml#L207-L211

so when creating an employee it will add the missing fields from defaults and it will get the default value in the context which for an existing user so when creating the employee with this user_id it will trigger the sql constraint

https://github.com/odoo/odoo/blob/889f25f1322f00dff7cacad95236d6f045c30d64/addons/hr/models/hr_employee.py#L145-L148

### Fix:
clean the context before creating the partner and the employee corresponding to this applicant

opw-4629219

Forward-Port-Of: odoo/odoo#210806
Forward-Port-Of: odoo/odoo#204997

**Steps to reproduce:**
1. Go to definition of default_website and add `<field name="configurator_done" eval="True"/>` .
2. install website module.

**Issue:**
Users are incorrectly redirected to the configurator screen instead of the website page. However, refreshing the page correctly redirects to the home screen as the server-side route is triggered on reload.

**Reason:**
The issue started in Odoo 16. Until Odoo 15, redirection to the configurator route is handled using ir.actions.act_url, which triggered a full page reload, ensuring the server route executed.
From Odoo 16 onwards, this action is removed, and a direct client action is attached. Within `configurator.js`, navigation is now handled using the `history.pushState` method which replace the current url and does not trigger a reload. As a result, even when navigating to the configurator route, the server route is not executed, leading to incorrect redirection.

**Fix:**
Added a check in configurator.js to verify the configurator status. If it is true, the user is redirected to the website page instead of the configurator. Otherwise, the normal configurator flow continues.

**Key Changes:**
1. In configurator_init, added a check: if configurator_done is True, set the default theme using button_choose_theme and store its result (a dict containing the next action to execute) as redirect_url.
2. In the Configurator component, added redirect_url to the store, and inside the onWillStart method, checked if redirect_url exists. If it does, redirect to the home screen using doAction.

This PR ensures the correct redirection behavior when users follow the Industries installation flow.

task-4555467

Forward-Port-Of: odoo/odoo#197593

Scenario:
- create an object_write (Update the Record) action
- update a field with equation evaluation (Python expression) with an
  expression like "record.id"
- click on "Create contextual action"
- go to a list view of the model, execute the action for several records

Result: the value of the field of all records are computed based on the
first selected record.

Issue: we don't change the "record" in the evaluation context and just
keep the first record.

Fix: changing the record.

Note: without the fix, the added test fails because the city of the
second record is set to the value of the ID of the first record.

opw-4491099

__PR code note__:

I did the change in "run" but this could be done in `_run_action_object_write`, I chose run because we are already changing the action_id in it.

The "`if eval_context.get('record') is not None`" is to not change an hypothetical case where `self.model_id` doesn't match the `context.action_model`.

__PR note__:

If it was too risky, we could probably merge in an higher version, the ticket is in 17.0 and this is still happening in master.

I've not heard of this issue before so this must not be very frequent or urgent, but I guess this is because people either use a python constant or they just use a python action with a for loop in general.

Forward-Port-Of: odoo/odoo#211122
Forward-Port-Of: odoo/odoo#210855

Issue: In Barcode, editing the qty_done of a move line and then reseting it to 0 will update the demand.

### Steps to reproduce:

- Create a storable product. Put 5 units in stock.
- Create a delivery order for 5 units and mark as to do.
- Go to the barcode app and edit your delivery order.
- Click on the pencil and set a qty of 1 > Confirm
- Click back on the pencil and reset the quantity to 0 > confirm
#### > On the picking, the demand of the line was edited from 5 to 1.

### Cause of the issue:

Editing the quantity of a move line from the barcode actually updates the qty_done of the move line which updates both the quantity and the picked status of the move line in the backend via the `_inverse_qty_done`: https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/models/stock_move_line.py#L58-L62 Initially, the quantity of the move line was 5 and hence the demand of the line in the barcode was displayed as 5:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L119-L121 The first time you edit the line, you will actually change its quantity to 1 and set it as picked. Once the line state refreshes in the barcode it will then keep the same demand of 5 as it will then be based on the previous demand of the line (since the qty of the move line is set and the qty done is positive):
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045 However, the next time you update the line the `_inverse_qty_done` will leave the quantity of the move line at 1 but will also unpick it. Then, and since the `qty_done` was set to 0, it will update the demand of the barcode line because of these same lines:
https://github.com/odoo/enterprise/blob/cbcff76a94750a6759fd72d9c952d785e603a974/stock_barcode/static/src/models/barcode_picking_model.js#L1037-L1045

### Fix:

Prior to Commit 3af3e00aabecde8b811ac2cbab397f982721f164 the quantity was updated as well as the picked state even when the qty_done was set to 0, so that this issue would not occur as the null quantity would make us keep the demand of barcode line after edition. However, the problem was that this would update the reserved quantity of the move and hence the barcode app demand once you leave the barcode app because of the `split_uncompleted_moves`. However, in the present use case, that same method can save us because if the move is picked and its quantity is null when you exit the barcode app, it will be rereversed.

opw-4700996

Forward-Port-Of: odoo/enterprise#85003
Forward-Port-Of: odoo/enterprise#83623