Odoo Changelog — 2023-03-24

Friday, March 24, 2023

65 changes · master

New Features(1)

New functionality added to Odoo

[IMP] stock: add least_packages retrieval strategy

Coremasterstockproduct_expiryMedium

Inventory picking can now prioritize using the smallest number of packages needed to fulfill a request. This helps warehouse teams reduce unnecessary unpacking, streamline logistics work, and keep packaged stock intact when possible.

Original PR description

[IMP] stock: add least_packages retrieval strategy ## Proposed feature and relevance Add a new retrieval strategy for gathering products: "Least packages". The goal of this strategy is to select…

[IMP] stock: add least_packages retrieval strategy

## Proposed feature and relevance
Add a new retrieval strategy for gathering products: "Least packages".
The goal of this strategy is to select specific product quantities from stock by using as few packages as possible, to allow for efficient logistics operations and avoid unnecessary opening/unpacking of packages.

This strategy will behave as follows:
- In case a negative quantity is requested this strategy will behave as a FIFO strategy.
- Otherwise, the strategy will determine a combination using the least amount of packages that sum to the requested quantity, and adapt the provided domain to select only the quantities in these packages. This way no packages need to be opened to select the requested quantity.
- In case an exact matching of current packages to get the requested quantity is not possible, a selection of packages is made where the largest packages are selected one by one until the requested quantity is reached, or until no more quantities are available. For this approach, one package needs to be unpacked as it will not be used completely. The final selected package that will be unpacked will be the smallest one possible, to try to unpack smaller packages over bigger packages.
- In case the search for a minimal matching of packages results in an out-of-memory situation, the strategy will fall back to a FIFO strategy.
- Loose items (not tied to a package) are considered as single-item packages for the purposes of package selection.

**NOTE:** To force the selection strategy to "clean up" certain packages that have previously been opened, it is recommended to unpack these packages into single items, as they will then be consumed to "fill up" requested quantities in later retrievals.

## Changes to allow more complex strategies
To allow for the integration of this new strategy the structure of `_gather()` needed to be adapted to allow a removal strategy to provide not only the SQL `ORDER BY` string but also adapt the domain used to retrieve the requested quantities.
This change is reflected in the method signature of `_get_removal_strategy_domain_order()`.

## How the strategy works
The strategy does one extra query of the database, to determine the different packages and their respective quantities (using the provided domain).
Loose items (that do not belong to a package) are added as single-item packages to also consider them.

For minimal exact package selection, an A* algorithm is used with 2 performance modifications:
- Using the information that the packages are sorted by size (large -> small).
- Using the information that the generated subtree for a specific package of size x is the same as all other packages of size x at a specific node.

By using the A* algorithm, as soon as a matching packaging selection is found, it is ensured to be optimal and other combinations do not need to be considered.
In case the A* algorithm runs out of memory the provided domain is just returned, which equates to a FIFO strategy.
In case the A* algorithm does not find an exact matching of packages for the requested quantity, a selection is made using the least amount of packages, unpacking the smallest possible package (or until no more quantities are available, in which case effectively all quantities in the domain are returned).

## Used heuristic
The heuristic used for the A* algorithm exploits the knowledge that our packages to select from are ordered by the highest to the lowest quantity (on the database side, SQL `ORDER BY`).
It assumes the "best case scenario" as an estimate for the amount of packages remaining, which is if we were to "match" the required quantity using fractional multiples of the next biggest package size.

***Example**:
Remaining quantity to select: 27
Remaining package sizes to select from: [10, 10, 5, 5, 5, 1, 1, 1]
Heuristic for choosing package with qty 10 as next package: 27/10 = 2.7
Heuristic for choosing package with qty 5 as next package: 27/5 = 5.4
Heuristic for choosing package with qty 1 as next package: 27/1 = 27*

This way the heuristic is always a "best case" (fractional) for the amount of packages that still need to be selected.


As required by the A* algorithm this also results in an underestimation as the fractional result is not possible, and it is not certain that there are still enough packages of this size that can actually be selected, but favours larger packages to make the search converge more quickly.

## Performance
### CPU
Two test cases were run to evaluate the performance.

***Total nr of pkg**: The total amount of different packages generated during data generation
**Qty to select**: The total quantity that needs to be selected
**Selected nr of pkg**: The amount of packages that was ultimately selected by the algorithm
**Data generation time**: The time required to generate all packages
**Assignment time**: The total time to run `_action_assign()` for the move
**A\* time**: The time to run the `_run_least_packages_removal_strategy_astar()` method*

#### First test case
This scenario simulates a case with a large quantity to select from a large amount of packages, but of relatively homogenous size.

Generate 30 different package sizes between 2 and 1000. For each package size, generate 100 to 250 packages each. Also add 100 to 250 "loose items".

The quantity to select is chosen between 1 and 50000.

|         RESULTS          |  RUN 1   |   RUN 2   |   RUN 3    |   RUN 4   |  RUN 5   |    AVG     |
|--------------------------|----------|-----------|------------|-----------|----------|------------|
| Total nr of pkg          |     5298 |      5772 |       5855 |      5533 |     5179 |     5527.4 |
| Qty to select            |    10319 |     20762 |      44422 |     39306 |     1783 |    23318.4 |
| Selected nr of pkg       |       11 |        22 |         48 |        41 |        3 |         25 |
| Data generation time (s) | 64.59124 | 92.916682 | 133.673384 | 82.711438 | 85.54542 | 91.8876328 |
| Assignment time (s)      | 4.060216 | 11.212937 |   4.763776 |   8.60248 | 3.461941 |    6.42027 |
| A* time (s)              |     0.28 |      6.88 |       0.21 |      3.96 |     0.03 |      2.272 |

#### Second test case
This scenario generates a large amount of small packages of different sizes.

Generate 250 different package sizes between 2 and 10. For each package size, generate 5 to 15 packages each. Also add 5 to 15 "loose items".

The quantity to select is chosen between 1 and 10000.

|         RESULTS          |   RUN 1   |   RUN 2   |   RUN 3   |   RUN 4   |  RUN 5   |    AVG     |
|--------------------------|-----------|-----------|-----------|-----------|----------|------------|
| Total nr of pkg          |      2485 |      2406 |      2491 |      2555 |     2542 |     2495.8 |
| Amount to assign         |        27 |      4029 |      3966 |      3049 |     1833 |     2580.8 |
| Selected nr of pkg       |         3 |       411 |       411 |       306 |      184 |        263 |
| Data generation time (s) | 18.502933 | 18.692048 | 19.969955 | 19.169106 | 19.16439 | 19.0996864 |
| Assignment time (s)      |   1.35635 |  7.958852 |  8.470518 |  6.300406 | 3.895457 |  5.5963166 |
| A* time (s)              |      0.01 |      0.07 |      0.77 |      0.56 |     0.31 |      0.344 |

### Memory
In cases with large amounts of different-sized packages (200+ different sizes and 200+ packages required to get an exact match) the memory performance of the A* strategy might become problematic.
When lots of packages have the same size (which would be considered typical in cases where there are large amounts of packages) the specific modifications to the A* algorithm ensure that the strategy still delivers good memory performance for this use case as the tree size can be significantly reduced, even with large quantities.

### IO
This strategy only requires one extra SQL query to fetch the different quantities and their respective packages.

## Limitations
No tests for this strategy were done for non-integer quantities. In these cases the performance of the A* algorithm might not be satisfactory and another approach might be preferred.
More research could be done for specific use cases where packaged quantities are non-integer values.

#inventory#warehouse#packages#picking

Improvements(10)

Enhancements to existing features

[IMP] spreadsheet: update o_spreadsheet to latest version

PR #116338

CoremasterspreadsheetMedium

This update refreshes the spreadsheet component and improves everyday editing behavior. Users get smoother chart and figure interactions, clearer errors when sheet structure changes, and fixes for menu, side panel, and formula editor issues.

Original PR description

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/59f25bb4 [REL] 16.3.0-alpha.2
https://github.com/odoo/o-spreadsheet/commit/d0189bd0 [FIX] config: bump owl version
https://github.com/odoo/o-spreadsheet/commit/115e1d2b [FIX] tests: fix component tests and their organization
https://github.com/odoo/o-spreadsheet/commit/e42786ad [FIX] Top_bar: Opening a menu should close the composer Task: 3076218
https://github.com/odoo/o-spreadsheet/commit/45f4c5c3 [FIX] range: show ref error after removing col/row
https://github.com/odoo/o-spreadsheet/commit/c55d601d [IMP] figure: add snap to figure drag & drop
https://github.com/odoo/o-spreadsheet/commit/7cbde524 [FIX] side panel: onSidePanelClose prop never call on X symbol click
https://github.com/odoo/o-spreadsheet/commit/308e5d6c [IMP] figure_chart: Double click on chart open the sidepanel
https://github.com/odoo/o-spreadsheet/commit/9781b7e3 [FIX] composer: fixed composer placeholder issues

Bug Fixes(7)

Resolved issues and error corrections

[FIX] mail: fix temporary_id not supported as message_post parameter

PR #116333

Coremastermailim_livechatMedium

This fixes a problem that could cause crashes when users sent messages in the chatter. The change keeps temporary message tracking internal so messages can be matched correctly without disrupting normal business communication.

Original PR description

Since [1], the `temporary_id` of a message is passed to the `message_post` route in order to renconciliate the temporary message on the client side and the real message created by the server.

This led to crashes when sending message on the chatter because this parameter was not allowed as a `_notify_thread` parameter.

Since this parameter is highly specific and isn't linked to any business/model code, this parameter is now passed via the context thus solving this issue.

[1]: https://github.com/odoo/odoo/pull/116085

Refactoring(4)

Code cleanup and technical improvements

[REF] *: dynamicInfo receive dynamicInfo

PR #115197

Coremastercalendarloyaltymailmass_mailingprojectsalesmswebMedium

This change improves how Odoo handles screens where the same field appears multiple times with different rules or filters. Each field instance can now use its own settings, reducing incorrect behavior in forms and lists across several apps.

Other(43)

Miscellaneous changes

[FW] Saas 16.2 project remove display project id xbo

PR #115781

Coremasterhr_timesheetprojectsale_projectsale_timesheet

Forward-Port-Of: odoo/odoo#115546

Original PR description

Forward-Port-Of: odoo/odoo#115546

[FW][CLA] Dinuth Perera

PR #116112

[IMP] stock: add least_packages retrieval strategy ## Proposed feature and relevance Add a new retrieval strategy for gathering products: "Least packages". The goal of this strategy is to select specific product quantities from stock by using as few packages as possible, to allow for efficient logistics operations and avoid unnecessary opening/unpacking of packages. This strategy will behave as follows: - In case a negative quantity is requested this strategy will behave as a FIFO strategy. - Otherwise, the strategy will determine a combination using the least amount of packages that sum to the requested quantity, and adapt the provided domain to select only the quantities in these packages. This way no packages need to be opened to select the requested quantity. - In case an exact matching of current packages to get the requested quantity is not possible, a selection of packages is made where the largest packages are selected one by one until the requested quantity is reached, or until no more quantities are available. For this approach, one package needs to be unpacked as it will not be used completely. The final selected package that will be unpacked will be the smallest one possible, to try to unpack smaller packages over bigger packages. - In case the search for a minimal matching of packages results in an out-of-memory situation, the strategy will fall back to a FIFO strategy. - Loose items (not tied to a package) are considered as single-item packages for the purposes of package selection. **NOTE:** To force the selection strategy to "clean up" certain packages that have previously been opened, it is recommended to unpack these packages into single items, as they will then be consumed to "fill up" requested quantities in later retrievals. ## Changes to allow more complex strategies To allow for the integration of this new strategy the structure of `_gather()` needed to be adapted to allow a removal strategy to provide not only the SQL `ORDER BY` string but also adapt the domain used to retrieve the requested quantities. This change is reflected in the method signature of `_get_removal_strategy_domain_order()`. ## How the strategy works The strategy does one extra query of the database, to determine the different packages and their respective quantities (using the provided domain). Loose items (that do not belong to a package) are added as single-item packages to also consider them. For minimal exact package selection, an A* algorithm is used with 2 performance modifications: - Using the information that the packages are sorted by size (large -> small). - Using the information that the generated subtree for a specific package of size x is the same as all other packages of size x at a specific node. By using the A* algorithm, as soon as a matching packaging selection is found, it is ensured to be optimal and other combinations do not need to be considered. In case the A* algorithm runs out of memory the provided domain is just returned, which equates to a FIFO strategy. In case the A* algorithm does not find an exact matching of packages for the requested quantity, a selection is made using the least amount of packages, unpacking the smallest possible package (or until no more quantities are available, in which case effectively all quantities in the domain are returned). ## Used heuristic The heuristic used for the A* algorithm exploits the knowledge that our packages to select from are ordered by the highest to the lowest quantity (on the database side, SQL `ORDER BY`). It assumes the "best case scenario" as an estimate for the amount of packages remaining, which is if we were to "match" the required quantity using fractional multiples of the next biggest package size. ***Example**: Remaining quantity to select: 27 Remaining package sizes to select from: [10, 10, 5, 5, 5, 1, 1, 1] Heuristic for choosing package with qty 10 as next package: 27/10 = 2.7 Heuristic for choosing package with qty 5 as next package: 27/5 = 5.4 Heuristic for choosing package with qty 1 as next package: 27/1 = 27* This way the heuristic is always a "best case" (fractional) for the amount of packages that still need to be selected. As required by the A* algorithm this also results in an underestimation as the fractional result is not possible, and it is not certain that there are still enough packages of this size that can actually be selected, but favours larger packages to make the search converge more quickly. ## Performance ### CPU Two test cases were run to evaluate the performance. ***Total nr of pkg**: The total amount of different packages generated during data generation **Qty to select**: The total quantity that needs to be selected **Selected nr of pkg**: The amount of packages that was ultimately selected by the algorithm **Data generation time**: The time required to generate all packages **Assignment time**: The total time to run `_action_assign()` for the move **A\* time**: The time to run the `_run_least_packages_removal_strategy_astar()` method* #### First test case This scenario simulates a case with a large quantity to select from a large amount of packages, but of relatively homogenous size. Generate 30 different package sizes between 2 and 1000. For each package size, generate 100 to 250 packages each. Also add 100 to 250 "loose items". The quantity to select is chosen between 1 and 50000. | RESULTS | RUN 1 | RUN 2 | RUN 3 | RUN 4 | RUN 5 | AVG | |--------------------------|----------|-----------|------------|-----------|----------|------------| | Total nr of pkg | 5298 | 5772 | 5855 | 5533 | 5179 | 5527.4 | | Qty to select | 10319 | 20762 | 44422 | 39306 | 1783 | 23318.4 | | Selected nr of pkg | 11 | 22 | 48 | 41 | 3 | 25 | | Data generation time (s) | 64.59124 | 92.916682 | 133.673384 | 82.711438 | 85.54542 | 91.8876328 | | Assignment time (s) | 4.060216 | 11.212937 | 4.763776 | 8.60248 | 3.461941 | 6.42027 | | A* time (s) | 0.28 | 6.88 | 0.21 | 3.96 | 0.03 | 2.272 | #### Second test case This scenario generates a large amount of small packages of different sizes. Generate 250 different package sizes between 2 and 10. For each package size, generate 5 to 15 packages each. Also add 5 to 15 "loose items". The quantity to select is chosen between 1 and 10000. | RESULTS | RUN 1 | RUN 2 | RUN 3 | RUN 4 | RUN 5 | AVG | |--------------------------|-----------|-----------|-----------|-----------|----------|------------| | Total nr of pkg | 2485 | 2406 | 2491 | 2555 | 2542 | 2495.8 | | Amount to assign | 27 | 4029 | 3966 | 3049 | 1833 | 2580.8 | | Selected nr of pkg | 3 | 411 | 411 | 306 | 184 | 263 | | Data generation time (s) | 18.502933 | 18.692048 | 19.969955 | 19.169106 | 19.16439 | 19.0996864 | | Assignment time (s) | 1.35635 | 7.958852 | 8.470518 | 6.300406 | 3.895457 | 5.5963166 | | A* time (s) | 0.01 | 0.07 | 0.77 | 0.56 | 0.31 | 0.344 | ### Memory In cases with large amounts of different-sized packages (200+ different sizes and 200+ packages required to get an exact match) the memory performance of the A* strategy might become problematic. When lots of packages have the same size (which would be considered typical in cases where there are large amounts of packages) the specific modifications to the A* algorithm ensure that the strategy still delivers good memory performance for this use case as the tree size can be significantly reduced, even with large quantities. ### IO This strategy only requires one extra SQL query to fetch the different quantities and their respective packages. ## Limitations No tests for this strategy were done for non-integer quantities. In these cases the performance of the A* algorithm might not be satisfactory and another approach might be preferred. More research could be done for specific use cases where packaged quantities are non-integer values.

### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/59f25bb4 [REL] 16.3.0-alpha.2 https://github.com/odoo/o-spreadsheet/commit/d0189bd0 [FIX] config: bump owl version https://github.com/odoo/o-spreadsheet/commit/115e1d2b [FIX] tests: fix component tests and their organization https://github.com/odoo/o-spreadsheet/commit/e42786ad [FIX] Top_bar: Opening a menu should close the composer Task: 3076218 https://github.com/odoo/o-spreadsheet/commit/45f4c5c3 [FIX] range: show ref error after removing col/row https://github.com/odoo/o-spreadsheet/commit/c55d601d [IMP] figure: add snap to figure drag & drop https://github.com/odoo/o-spreadsheet/commit/7cbde524 [FIX] side panel: onSidePanelClose prop never call on X symbol click https://github.com/odoo/o-spreadsheet/commit/308e5d6c [IMP] figure_chart: Double click on chart open the sidepanel https://github.com/odoo/o-spreadsheet/commit/9781b7e3 [FIX] composer: fixed composer placeholder issues

Since [1], the `temporary_id` of a message is passed to the `message_post` route in order to renconciliate the temporary message on the client side and the real message created by the server. This led to crashes when sending message on the chatter because this parameter was not allowed as a `_notify_thread` parameter. Since this parameter is highly specific and isn't linked to any business/model code, this parameter is now passed via the context thus solving this issue. [1]: https://github.com/odoo/odoo/pull/116085

## Current behaviour When checking on the activities that are "Late/Today/Future", the resulting search view doesn't apply any filter. ## Expected behaviour If you click on "Late" activities for Tasks, then you should see only the "Late" activities, not all of them. ## Steps to reproduce - Install Project - Create a project and 3 tasks for that project - On each task, put an activity that is "Late"/"Today"/"Future" respectively (1 activity per task) - Click on the activity widget (top-right in the header) > Tasks > Today - All tasks are shown, not only those for "Today" ## Reason for the problem Since the view refactoring from b77f60b155bf97a115aa209847dc791677b2e924 , search filters follow an hierarchy of inheritance to reduce code duplication. The issue is that it's "delegation" inheritance (so the childs have a mode of type "primary") but all their priorities are the sames, so the algorithm for view matching (refer to documentation) matches the parent view, that doesn't contains the necessary filters for the activities, which are defined a few level lower in the inheritance. ## Fix Add descending priority in the inheritance chain so we match the lowest child when web-client requests the search view. ## Affected versions - saas-16.1 - saas-16.2 - master --- opw-3234525 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#116188

This issue was caught in sentry. When we try to create or update an invoice by uploading an `.xlsx` attachment, it raises an Error as it will go to convert it into XML tree because the concerned LOC will check `xml` in `mimetype` of attachment which is `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet`. ``` XMLSyntaxError: Start tag expected, '<' not found, line 1, column 1 (<string>, line 1) File "addons/account_edi/models/account_edi_format.py", line 207, in _decode_xml xml_tree = etree.fromstring(content) File "src/lxml/etree.pyx", line 3252, in lxml.etree.fromstring File "src/lxml/parser.pxi", line 1913, in lxml.etree._parseMemoryDocument File "src/lxml/parser.pxi", line 1800, in lxml.etree._parseDoc File "src/lxml/parser.pxi", line 1141, in lxml.etree._BaseParser._parseDoc File "src/lxml/parser.pxi", line 615, in lxml.etree._ParserContext._handleParseResultDoc File "src/lxml/parser.pxi", line 725, in lxml.etree._handleParseResult File "src/lxml/parser.pxi", line 654, in lxml.etree._raiseParseError ``` sentry-3929855076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#116231 Forward-Port-Of: odoo/odoo#115653

New Features(1)

[IMP] stock: add least_packages retrieval strategy

Improvements(10)

[IMP] spreadsheet: update o_spreadsheet to latest version

Bug Fixes(7)

[FIX] mail: fix temporary_id not supported as message_post parameter

Refactoring(4)

[REF] *: dynamicInfo receive dynamicInfo

Other(43)

[FW] Saas 16.2 project remove display project id xbo

[FW][CLA] Dinuth Perera

New Features(1)

[IMP] stock: add least_packages retrieval strategy

Improvements(10)

[IMP] spreadsheet: update o_spreadsheet to latest version

Bug Fixes(7)

[FIX] mail: fix temporary_id not supported as message_post parameter

Refactoring(4)

[REF] *: dynamicInfo receive dynamicInfo

Other(43)

[FW] Saas 16.2 project remove display project id xbo

[FW][CLA] Dinuth Perera

[IMP] account: tax tag on any journal item

[IMP] l10n_pe: Add List of Peruvian Banks

[IMP] *: remove "French spacing"

[IMP] l10n_es: translation to English + new tax taxonomy

[IMP] l10n_es_reports: translation to English

[IMP] assign vat 66666666-6 when partner is End consumer

[IMP] *: remove "French spacing"

[IMP] account_reports: multi-vat cross country

[IMP] l10n_pe_edi: Move Bank Data to l10n_pe

[FIX] mail: fix message unread counter

[FIX] web,mail,web_tour,test_main_flows,tests: no hardcoded user agent

[IMP] delivery: carrier is not set after delivery generated

[FIX] web: Domain: improve validation

[FIX] mail: do not return when processing notifications

[FIX] knowledge: use correct cover_image_position field in frontend

[REF] point_of_sale,pos_*: convert barcode_reader to service

[REF] pos_*: convert barcode_reader to service

[REF] *: dynamicInfo receive evaluated

[FW][FIX] web: popover collapsed when fewer fields available.

[FW][FIX] web: properties test very slow

[FW][FIX] web: binary field filename in form view not updated with pager

[FW][FIX] project: search view for activities on tasks should be correct

[FW][FIX] account_edi: file validation while uploading

[FW][FIX] account: do not recompute account when partner change for ODs

[FW][FIX] event{._sms}: clean duplicate views and make no traceback

[FW][FIX] point_of_sale: crash at startup number_buffer

[FW][I18N] *: export saas-16.2 source terms

[FW][FIX] mail: fix recipients (partner) not displayed in preview

[FW][FIX] pos_sale: add down payment limit

[FW][FIX] account: change move currency

[FW][FIX] account: invoice analysis total always positive

[FW][FIX] website_sale: do not use cached pricelist on partner update

[FW][FIX] web_editor: traceback on empty selection.

[FW][IMP] hr_expense: edit account on expense sheet

[FW][FIX] product_expiry: fix MemoryError on module installation.

[FW][FIX] sale_timesheet: adapt fields desciption to compute method deletion

[FW][FIX] point_of_sale: display the correct discount name in paid orders

[FW][FIX] web_tour: put dropdown above when the tooltip is active

[FW][FIX] mrp: find BoM with other picking type

[FW][FIX] website_sale_digital: unable to download digital resources.

[FW][FIX] website: support RTL for the opening direction of the sub-menus

[FW][FIX] core: allow translated sized char fields

[FW][FIX] web_editor: page crash on colour selection

[FW][FIX] product{,_expiry},stock: print labels of GS1 lot

[FW][FIX] point_of_sale: correctly set owner on pos order refund

[FW][FIX] website_sale: abandoned cart wrong template

[FW][FIX] point_of_sale,pos_restaurant: customer button

[FW][FIX] pos_settle_due: customer button

[FW][FIX] documents : split tools not available from list view

[FW][FIX] l10n_in_reports_gstr: fix IAP account name

[FW][IMP] account_reports: perf improvements

[FW][FIX] account_journal_report: line with same id

[FW][FIX] quality_control: edit done qty of SML

[FW][I18N] *: export saas-16.2 sources terms

[FW][FIX] account_reports: support translated fields in Profit and Loss

[FW][FIX] l10n_mn_reports: Correction BS

[FW][FIX] documents_account: company dependent journal

[FW][FIX] helpdesk_stock: remove suitable_picking_ids for returns w/o ticket_id