mrp - when a MO is generated from replenishment report, a log note is added
to chatter with the link of replenishment report, as this report got deleted
when to to qty is 0.0 then link dost not work. Hence added the simple text
for Relenishment report.
purchase_stock - When click on the order once button of replenishment report,
if vendor is not added on product then, added a new wizard with functionality
to directly jump on the edit product.
Added log note to the PO if po lines are generated through the Replenishment
report.
TaskId - 2427738
[IMP] stock: split method to create new or unlink unused OP
As, server action was added to the Replenishment menu, unless
until user clicks on the menu, new order point will not get
generate. Hence splitted the method and added to auto vaccum for
this.
TaskId - 2427738
closesodoo/odoo#66130
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase:
- Product A 10 units in stock
- Do a planned transfer of 7 units to customer
- Reserve
- Do an rpc or execute code to call copy on the stock.move.line
It will result with 2 sml that have 14 units reserve and 7 units
reserved on stock.quant
It's the same result if you create twice the stock.move.line without
updating the stock.quant at the same time. However in stable we
try to only use _update_reserved_quantity on stock.move or some
override in create/write method for 'done' stock.move.line in unlock
cases.
So we never use the copy in stable and define the basic behavior as
'we don't copy the reservation' could prevent some usecase where
the update on the stock.quant is forgotten after.
closesodoo/odoo#74489
X-original-commit: e5041ee1d9b5036cab55f4332977aeb818a3b1e1
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Step to follow
Do not activate multiple companies, keep it standard to 1
Enable multi-locations and routes
Create a second location for raw materials and a new Receipt operation type with the new location as destination location
Go to routes -> edit the buy route -> add a second rule with "Buy" and save.
Cause of the issue
When a stock rule is created from a stock route, the default company
cannot be found as there is none assigned to the stock route.
Solution
Override the default_get method for stock rules in order to use the
current company
opw-2578984
closesodoo/odoo#74380
X-original-commit: 2b8d7d76adceeca16f97e394a6734bb5be633c3b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, it was required to always use the widget to edit the
consumed quantity of a component when multi-location or packages setting
is active. This was not user friendly so this commit relaxes the
requirement to only tracked products and gives users the option to still
edit the consumed move lines directly if desired. We also distinguish
between when using the widget is required or not with the widget button
color. Note that if quantity consumed is greater than amount reserved in
different locations, the difference will default to the move's source
location (this is consistent with what happens when the `qty_producing`
is changed in the MO and the consumed quantities are scaled to match.)
Task: 2518523
Upgrade PR: odoo/upgrade#2655closesodoo/odoo#73939
Related: odoo/enterprise#19732
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Define a [DEMO] prod with tracking by SN and add some SNs
- Activate "use existing lot/serial number" on the receipt picking type
- Create a purchase order for [DEMO]
- Process the receipt in the barcode app:
* Scan the product
* Scan the SN barcode
* Validate
User will get an error.
It seems that Odoo is trying to create this SN instead of
matching the existing one
opw-2474347
closesodoo/odoo#73610
X-original-commit: 09a1252b8a5bc194ffccd6c2437985328d08ba08
Related: odoo/enterprise#19632
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
And convert the `t-esc` in the template to `t-out` while at it.
So this was a bit of a bummer initially, the PopoverWidgetField gets a
pile of JSON as its value (so from the server), and that pile contains
a template name (optionally) and... the template context,
basically. For leadDaysPopOver the issue was some of that context is
supposed to be rendered HTML to straight inject into the template,
marking that as HTML-safe would be a bit of an issue (having the JSON
specify which parts of the value it returns are HTML-safe being a bit
of a conflict of interest).
However turns out the thing is way over-complicated and
over-engineered: `lead_days_description` necessarily has a very
regular structure owing to being injected as a set of table rows, so
the various overrides to `_get_lead_days` just make their own lives
complicated by formatting the values they want to return into table
rows matching the format of an unrelated template.
Instead we can change the signature of `_get_lead_days` so the
"description" is a list of values to inject in the table (list of
pairs, each pair matching the corresponding columns of the table). The
template can then take care of formatting those values into table rows
the usual way, removing the need for any injection of raw content.
This also makes for better / clearer translation strings.
Currently the replenishment report look for forecasted quantity of
product today. It means that for a product if the delivery is planned
for today the forecast will be -1, at j-1 it will be 0. However for the
majority of use case, products take days to order and arrive.
Example:
- Product A, purchase delivery time 5 days.
- You are the 01-01-2021 and create a SO for 10-01-2021
Currently:
- Product will appear in the replenishment report the 10-01-2021 and
you will receive it the 15-01-2021. So you are late to deliver your
customer.
Desired behavior:
- Product appear in the replenishment report the 05-01-2021 and if you
order it directly you will receive it the 10-01-2021.
If you want to have more time to deliver than one day, security lead
time are there for it.
However the usecase like:
Product arrive in 2 months and you receive it in 3 days, the product won't
appear in the replenish report anymore since the forecast in 3months is
0
It could happens that more product are missing in 3 months than today,
so the system could have more delivery lead times and forecast at date
to compute -> be slower. In that case a parameter could be
added to skip the delivery times computation for each product/warehouse
and just display the forecast in 3 months and let user compute their
schedule themself.
closesodoo/odoo#73737
X-original-commit: f988b7629f8f54e8e3f48bf76e6af9d97b4f47da
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
During the creation of the second warehouse,
a warning popup to tell that it will activate also the
Storage Locations setting even if this one is already activate.
Only raise this warning if the is Storage Locations not activate yet.
task-2558097
1. When creating a putway rule, default location_in_id is receipt
destination location (in case of single warehouse).
2. When changing location_in_id, copy value to location_out_id.
3. Allow to hide some fields and change of some labels.
4. Move location tab to a smart button.
closesodoo/odoo#69580
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Move candidate.unlink out of the for loop to unlink
records in batch.
Remove to_unlink_candidates.move_id from move_to_recompute as
move_line.unlink() will trigger recompute of their move's state.
---
opw-2585598
closesodoo/odoo#73160
X-original-commit: e2e51c15d082ec17743b73ad1422e4a223268be9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Infobox to help the user with the replenishment. Allow those actions:
- See the different supplier with their lead time, price and quantity
- Be able to select a supplier and set it on the orderpoint
⁻ See the last delivery by mmonth for the product
- Last purchase date for each supplier
Technicaly it use a wizard and a fields char with JSON used by
a widget to display a static template. Also it creates directly
the wizard in backend instead of just let the view manage the new
object since we need a button on a one2many and if the records do
not have an id, it's not possilbe to use it.
closesodoo/odoo#72039
Task: 2519761
Related: odoo/upgrade#2596
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase to reproduce:
- Setup a maximal of 100units in a storage category
- Set the storage category on shelf1 and shelf2
- Create two putaway rule from wh/stock to wh/stock/shelf1 and
wh/stock/shelf2
- Create an immediate receipt
- Set 100 units of product on stock move line (should suggest shelf1)
- Put in pack
- Create a new stock.move.line in the receipt.
It will suggest the same location than in the first line despite the
location is the same. It happens because the check look only at quantity
reserved in the location but the user could have create new line without
quantity reserved.
This commit, take the maximum between the quantity reserved and the
quantity done to give an estimation of what could happens.
closesodoo/odoo#72689
X-original-commit: d9d98d4264295532f2248c6072aabbd72f32f054
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When consulting a delivery slip, a portal user won't see the lots/serial
numbers used.
To reproduce the error:
(Need demo data)
1. Create a product P
- Product Type: Storable
- Tracking: By Lots
2. Update its quantity
3. In Settings, enable "Display Lots & Serial Numbers on Delivery Slips"
4. Create + Validate a SO:
- Customer: Joel Willis
- Lines: 1 x P
5. Validate the delivery
6. Log in DB with 'portal' (Joel Willis)
7. On SO, open the Delivery Slip
Error: The product's lot is not mentioned
Here is the condition to display the lot:
https://github.com/odoo/odoo/blob/c61db20204700a375f7005f50f95b44a60c3bb70/addons/stock/report/report_deliveryslip.xml#L77-L79
Problem is that portal users are not part of
`group_lot_on_delivery_slip`
When enabling the option, the groups are updated here
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L570-L576
`implied_group` (which is `stock.group_lot_on_delivery_slip` in our
case) is added to `groups.implied_group`
The variable `groups` comes from `classified`, which is defined thanks
to method `_get_classified_fields` (see L553 in above code block)
And here is an extract of how this method works:
https://github.com/odoo/odoo/blob/adccb562209c2431a49438d36794f0765f1bc86d/odoo/addons/base/models/res_config.py#L460-L462
At some point, it checks if the field `group_lot_on_delivery_slip` has
an attribute `group`. In case `group` is not defined, the group
`base.group_user` is used. This is the reason why, by default, the
option is enabled for internal users only instead of all users.
Therefore, we just need to define the attribute `group` to the field
`group_lot_on_delivery_slip`
OPW-2558761
closesodoo/odoo#72656
X-original-commit: 475b35397b7254012a082a1206c478084c069857
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Improve res.patner._compute_on_time_rate performances by calling
mapped('quantity_done') once on all the order_lines.move_ids.
Moving it out of the for loop allows to befinit from the performance
gains of the read_group call in stock.move._quantity_done_compute.
closesodoo/odoo#72422
X-original-commit: 2841525a3a2f1273783874947884b57494def849
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Some changes in the delivery slip layout:
- For delivered products, replaces the Quantity column by two other
columns: Ordered and Delivered;
- Shows the non-delivered products even when the delivery is done and
haven't any backorder.
task-2373833
closesodoo/odoo#61366
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
A security has been added to avoid an infinite loop due to custom
code if the failing orderpoints were not correctly return in order
to exclude them from the set to retry.
However after a first batch if some orderpoints were correctly exclude
orderpoints_exceptions will not be empty and during the second iteration
failed_orderpoints will be always filled from exceptions of previous
iterations and the infinite loop will not be detected.
opw-2525893
closesodoo/odoo#71938
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently there is an action_assign_serial_show_details button within
the detailed operations form of a serial tracked product move.
Unfortunately there is no way to undo the assigning/creating of move
lines from this action (including via clicking the "Discard" button).
This can lead to a lot of manual work (e.g. 500 SNs produced instead of
50) to remove unwanted move lines. To remedy this, we add in a button
to unlink all of the move's move lines whenever the Assign Serial
Numbers button is visible.
closesodoo/odoo#71831
Task: 2426281
X-original-commit: a6191c43001f961c20b5b4d32e1fcb218df69d17
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
1. Add product category in inventory report.
2. Default quantity when creating a transfer switched to 1 instead of 0.
3. Remove the reorganize lines step in purchase tour (there is only 1
line).
closesodoo/odoo#69483
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider that Reservation = manual (Inventory>Configuration)
- Let's consider two interna users I1 and I2 with the following access rights:
-Sales: own document only
-Inventory: user
- Login as I1 : Create sale order SO1 to sell a storable product P
- Confirm SO1 to create delivery order DO1
- SO1's Sales Person should be assigned to I1 and DO1's status should be "waiting"
- Login as I2 : Create sale order SO2 to sell P
- Confirm SO2 to create delivery order DO2
- SO2's Sales Person should be assigned to I2 and DO2's status should be "waiting"
Bug:
When I1 or I2 tried to access DO1 or DO2, an access error was raised due to personal order line record rule
opw:2530101
closesodoo/odoo#71725
X-original-commit: ab2663ae0e6f29540b8b8e8ef8b6178ecbd9d7b8
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fieldss
1) stock.location -> comment
2) stock.picking -> note
Task Id: 2499504
X-original-commit: 96f5316a219568add44bee528245c2c8e49c3bbc
General improvements of the new Inventory Adjustment mechanism, among which:
From the Inventory Adjustment page
- A new inventory_quantity_set Boolean field is used to hide the Counted Quantity when not set instead of showing 0.
- Possibile to set 0 as a Counted Quantity directly (not using the set button).
- Allows to provide a name for the Inventory Adjustment when using the Apply button at the top of the tree view. This name is applied on the corresponding stock moves.
- Add warnings when trying to Apply/Set on multiple records when some records are not set/already set.
- Highlight lines when there is a mismatch between Quantity / Counted Quantity / Difference. If the user still tries to Apply, shows the option to either keep the current Difference or the current Counted Quantity for all records.
- Set the user when directly inserting a Counted Quantity (before only when using the Set button)
- Add the possibility to import records.
- Add "To Apply" filter.
- Add a 'Reset' button at the top of the tree view for multiple records.
From the Update Quantity page of a product
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
- Pre-fill a default location (Last used location for tracked products or default destination location in single WH environment)
From the Inventory Report
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
closesodoo/odoo#71199
Task-id: 2495664
Pr-community: 71199
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
On a delivery, when changing the initial demand of a stock move, if its
value was 0 and becomes > 0, its state will be 'Partially Available' but
the reserved quantity will still be 0.
To reproduce the error:
1. Create 2 products P01, P02
- Product Type: Storable
- Qty On Hand: 1
2. Create + Confirm a SO with 1xP01 and 1xP02
3. Open SO's delivery
4. Unlock, set P01's initial demand to 0, Save, Lock
5. Unreserve, Check Availability
6. Unlock, set P01's initial demand to 1, Save
7. Click on PO1 line
Error: The stock move state is "Partially Available", but the initial
demand is 1 and the reserved quantity is 0. It should be "Waiting
Availability"
On step 5, since the wanted quantity of P01 is 0, the state of the stock
move becomes "Available". Then, when increasing the requested quantity,
the state automatically becomes "Partially Available" because the module
does not consider the case where the state is "Available" with a
reserved quantity equal to 0.
OPW-2488580
closesodoo/odoo#71445
X-original-commit: 05b6dfa0b1e4daf46d569c2e0a330b35e6437f8d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The `groupby` function is used to builds groups of(product, lot) keys
and their corresponding move lines / quants. `groupby` groups
*consecutive* keys, which is why the input is sorted by the keys.
`sorted` on recordsets keys will not sort as we would expect in this
particular situation, as the comparison operators on records act as
Set Comparison operators on the record ids, i.e. to compare the sets
superset/subset relationships:
```
>>> env["product.product"].browse(1) < env["product.product"].browse(2)
False
>>> env["product.product"].browse(1) < env["product.product"].browse([1, 2])
True
```
Example of sorted on stock.move.line records, where the product id 7313
is both in the slots 4 and 12 instead of being consecutive:
```
>>> [l.product_id.id for l in sorted(lines, key=itemgetter('product_id'))]
[7436, 7437, 7352, 7423, 7313, 7351, 7423, 7424, 7320, 7398, 7312, 7352, 7313, 7436, 7437, 7442, 7443, 7320, 7423, 7424, 7318, 7396, 7368, 7355, 7316]
```
Now when we group by id the 2 ids 7313 are correctly placed together in
slots 1 and 2:
```
>>> [l.product_id.id for l in sorted(lines, key=attrgetter('product_id.id'))]
[7312, 7313, 7313, 7316, 7318, 7320, 7320, 7351, 7352, 7352, 7355, 7368, 7396, 7398, 7423, 7423, 7423, 7424, 7424, 7436, 7436, 7437, 7437, 7442, 7443]
```
This commit aims to sort by "id" of the related records, to ensure the
same (product, lot) couples are consecutive.
closesodoo/odoo#71276
X-original-commit: d53d8bdf789e8f79ea4d531d944686abb59d6a26
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
1. activate routes setting + multi-step incoming shipments (2 or 3,
doesn't matter)
2. create an immediate transfer receipt
3. add a done quantity (optional: validate)
4. open corresponding 2nd step internal transfer
Expected result:
- amount done in immediate transfer receipt will be demand of internal
transfer
Actual result:
- demand (and all other values) will be 0
closesodoo/odoo#68885
Task: 2492994
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
If you modify an archived warehouse, it may happen that the associated operations get unarchived. Operations should be active only if their warehouse is active.
closesodoo/odoo#70607
X-original-commit: 63167ac8ae6ac08fa54a133ed9089dd872c7d73c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
Before this commit, when quants where automatically unlinked, all empty
quants were took.
Now, quants with a defined `user_id` will not be unlinked because they
can legitimately be to 0 and we should wait inventory was processed
before empty quants were unlinked (as once the inventory is processed,
the `user_id` on quant is removed).
closesodoo/odoo#70275
X-original-commit: 7c5143e95ef1fcceafe5e331c3e8649e08666ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
add the name of argument, if not precision_digits is used.
closesodoo/odoo#70242
X-original-commit: 2e7dfec50e9104adf8efbc64e0342359dc8947a7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create SO with deliverable product, confirm
- Change delivery Address on SO and on Transfer
- Inventory > Stock moves (debug mode)
- Group by > Picking and Destination address
The address shows is the original and not the updated one.
opw-2429018
closesodoo/odoo#67407
X-original-commit: c813655074b3b83bdf9345ef12399b0b96feaf71
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Usecase to reproduce:
- create a product with 0 stock
- Sale order 500 units
- a RFQ is created for 500 units
- in replenishments, you have 0 units to order, OK
- RFQ --> confirm PO
- in replenishments, now the quantity to order is 500
--> should still be 0, it leads to confusions
It happens because the replenish action check the missing
quantity for today. It result by -500 units since the delivery
is planned for the next day (default supplier lead days = 1).
But since the orderpoint exist, the quantity forecasted is
already computed correctly with the right lead time.
But the action will remove the 500 missing today from the
quantity forecasted (The idea is to add the missing quantity on
the main location. e.g. I have
-10 units in WH/Stock/Shelf1
-20 units in WH/Stock
The orderpoint will only look for its own location -> 20 to reorder
The replenishment report look by warehouse and not by location -> 30
missing. So 30 missing + 20 incomming -> 10 to add (by default on
WH/Stock)
The fix is to add a step when a product is missing then compute its
virtual available with lead days (to avoid missing confirmed moves
during the lead time).
opw-2456978
closesodoo/odoo#69527
X-original-commit: f939c7b2c4143d685c25d155a164d63070d36ed2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Fix the access for stock user to stock.quant.
Since the inventory adjustement feature has been moved on
the stock.quant. The user should be able to write on them to
make their count. However we kept that a stock user can't validate
an inventory nor modify quantities on product
closesodoo/odoo#69006
X-original-commit: 6b8d40ec494dfbcaaef0da438692c76d0088f671
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
We introduced new Smart Putaway Rules.
Locations now can have a storage category, on each storage category,
we can specify the amount of products/packages(with certian package
type) that can be stored in the location.
On putaway rules, we can also set a storage category. Now when apply a
putaway rule, we will find a suitable child location of the out
location according to quantity/weight setting on the storage category.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
Currently, delivery packaging and product packaging share the same
model product.packaging. In this commit, we make delivery packaging
a new model stock.package.type. The code is also moved to stock
instead of delivery for compatibility reasons.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
Let's say we have location A, B, and C. A is the parent of B, B is the
parent of C. And we have a putaway rule to move product from A to B. Now
receive product at C, because currently when we can't find a putaway
rule at one location, we will loop to check its parent locations. So the
puteaway rule A -> B will be found, and product received at C will in
the end be stored at B.
After this commit, we don't check the parent locations when we can't
find a putaway rule.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
This method is useless and it bypass the computation of some fields
(qty_available, virtual_available, incoming_qty, outgoing_qty). Then
this method is not cache-friendly, and we should use `read` instead.
task-2439019
closesodoo/odoo#66621
Related: odoo/enterprise#16584
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
To avoid multiple search of the get_warehouse for the same location
and extra SQL request (it happens a lot for complicate flow, e.g.
mrp_mps, replenishment report).
Translate it into a standard compute to use the cache of
the ORM for no-store compute field (`warehouse_id`) and put
some depends to be always correct (even if `warehouse_id` shouldn't
change in the same request).
task-2439019
Pratima Gupta