Two key are used for the same purpose. Remove one and
use its content directly in the report
clean commit bef1765b197a9e9d510a7d20d0364333402473b0
Part-of: odoo/odoo#82312
Steps to reproduce the bug:
- Install inventory and sales
- Create a SO > Confirm
- Click on the delivery > print > delivery slip or picking operation
Problem:
Only the name and phone number are in the report
opw-2697221
closesodoo/odoo#82235
X-original-commit: 35e6abce0e662cae6a55293f31620114ad5ecd8a
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Step to reproduce:
Try to print traceability report
Current Behaviour:
Traceback wrongly generated header
Behaviour after PR:
No Traceback, the header is now correctly generated
opw-2704299
closesodoo/odoo#81673
X-original-commit: 6b567326edc7bc691d87d911759ee30a24a8a1d7
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
commit af13e76629
reworked delivery split to add interwarehouse addresses but also
removed the address in a usual case.
opw-2701998
closesodoo/odoo#80609
X-original-commit: 9b9c4a3433d2a052e70e434b11817b791f38e508
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps to reproduce the problem:
- Create a storable product tracked by a unique serial number.
- use the product in a delivery
- try to print the "Picking Operations" document
Problem:
Traceback is triggered because we cannot use two fields in a "t-field"
opw-2692226
closesodoo/odoo#80140
X-original-commit: f478c9f48bc4f8adc0f455df1795de9672a40b78
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When Print Labels was revamped in odoo/odoo#69690 it was decided that
only product barcodes would be printed. Unfortunately we want SN/Lot
barcodes to be printed instead when they are filled in, so we make this
the case when applicable (i.e. when printing Transfer Quantites + qtys
done).
closesodoo/odoo#80079
Task: 2678336
X-original-commit: 105587e9e411442fd8e6d30efaa35b90b0e09959
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Commit d6abfbade9fb7f6dd6b3253551c559b1c7e6ece5 made it so we directly
reference a move's source origin via _get_source_document(). Normally
this is fine when the labels are created because labels would never be
created for a move without a source document, but this isn't safe when
the label is accessed via another way (e.g. test_reports). Therefore,
let's add in a check to prevent a error from trying to access
False.name.
closesodoo/odoo#79585
X-original-commit: 8abba9c3c0c48241e017e87045f392dc403a28e9
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Currently, the order of transfer lines makes no sense for a picker
(it's in the order of the creation of the line). We want to have the
lines of the detailed operation in the same order as the picker will be
picking the products, so we order by source location, destination
location, sequence, and then by id (i.e. creation time) respectively
instead.
Also the printing report of the batch transfer is on too many pages,
it's one page by location, but we always group on 'from location'.
So it would be better not to split by location and keep the report
on the least number of pages possible.
task-2496324
odoo/enterprise#21921closesodoo/odoo#79446
X-original-commit: 9b120caa2a5cd5e2487d663a180b486b5bdb201b
Related: odoo/enterprise#22144
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previously it did not matter that we didn't explictly include the
'res_model' in the action when auto-opening the reception report on
validation. With the barcode OWLification refactoring we now need to
include it otherwise it will never open when a barcode picking is
validated.
Part of Task: 2632884
Related ENT PR: odoo/enterprise#20805closesodoo/odoo#79408
X-original-commit: a966e9d122b6fa91906260e82eaea1ed720bd076
Related: odoo/enterprise#22122
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Simplify user workflow by not showing the "Allocation" button in the
(batch) picking form view if there is nothing to allocate (i.e. when
reception report is enabled).
Also:
- fix the location search condition for the outgoing moves that can
be allocated to (i.e. the same logic used in show_allocation field
compute logic is also used in reception report generation/auto-opening)
- replace ['stock.location'].search() with ._search() for better
performance.
Part of Task: 2632884
ENT PR (for barcode equivalent): odoo/enterprise#20805
X-original-commit: 11ffb85fe7398854e4aefa4f9d0cfbc3b88aad8a
Part-of: odoo/odoo#79408
When reception report is viewed in a mobile screen, the "Print Label(s)"
buttons do not fit well, therefore we use a print icon instead of text
when in a mobile view. To ensure it looks good, we also update the
buttons to have equal width/height where applicable.
Part of Task: 2632884
X-original-commit: fadc2dddf12521b0f81096b6225d67951584b714
Part-of: odoo/odoo#79408
Previously the reception report > "print labels" would only print the
picking name (or SO if provided) + delivery address (if provided) when
not for a MO. Label has been updated to include the product name.
During this update a few other related improvements were made:
- make the label based on stock.move (so extending is no longer
needed in MRP)
- formatting of label is improved so now address will be truncated
instead of wrapping (and potentially losing lines at end of address)
- line padding is reduced so we can fit more lines in the label
- "Print Labels" button at source level will now be enabled when its
corresponding "Assign All" button is pushed (previously only the
"Print Label"s of each moves' line was enabled.
Part of Task: 2632884
X-original-commit: 9774c1ab1d68cf095b64a82b56f100d747fc8a56
Part-of: odoo/odoo#79408
Make it so the (sales order) of a picking is also a clickable link in
the reception report. This was done in a flexible way so it should work
in theory for any stock.move._get_source_document() record, but it is
only applicable to sales orders for now.
Part of Task: 2632884
X-original-commit: d8cd091c3b61ac212fe9e92d532af7cefcf315a6
Part-of: odoo/odoo#79408
Fix a small logic bug which made it so draft outs would only show only
if there were also draft ins.
closesodoo/odoo#79067Fixes: odoo/odoo#78872
X-original-commit: c764709715f0a86ac531f3be6d73ecadacbdeafc
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Due to floating point limitation, the quantities displayed in the
forecasted report should be formatted to ensure the rounding.
Issue example:
(Need stock)
1. Create a storable product P
2. Update its quantity to 7.1
3. Consult the Forecasted Report
Error:
Quantities are "7.1000000000000005 Units". In this case, the
floating-point issue comes from the method `float_round()`
Another example:
(Need purchase_stock)
1. Create a storable product P
2. Update its quantity to 0.1
3. Create a PO with 0.2 x P
4. Consult the Forecasted Report
Error:
The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This
field is directly computed while rendering the report, it's the sum of
0.1 and 0.2 which, in python, results in 0.30000000000000004
(floating-point issue)
Since the rounding of these quantities are actually based on the decimal
precision of the UoM, this commit may slightly change the report.
Suppose the generic precision is .001 and the precision of "Units" is
0.01: if the quantity is 12.34, one zero will be added in the report:
12.340. However, these unnecessary zeros do not change the information
that is initially displayed. Moreover, the UoM precision can not be
greater than the generic precision, so we will never lose a part of the
quantity to display.
OPW-2611892
closesodoo/odoo#78853
X-original-commit: f4df8b5eec788cf701e58b02a4be58266d5ddc71
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Avoid some useless read_group on stock move (fetch too much qty fields
in product.product) and use a query object to avoid fetching data.
To compute 11K of forecasted information of stock move (multi-warehouse
):
- Before: 1.704 ± 0.046 sec and 174 SQL request
- After: 1.554 ± 0.012 sec and 134 SQL request
X-original-commit: 338edd616c2afe1d7a08a06a0b0278c3d7083c05
Part-of: odoo/odoo#77402
Improve the performance/scalability of the forecasted compute.
Duplicate the code of the `_get_report_lines`
(`_get_forecast_availability_outgoing`) and specialize it to only
compute necessary information for the `_compute_forecast_information`.
It is mandatory to readd 'Component/Product Availability' (MO/picking)
which aggregate the result of `_compute_forecast_information`.
Note that with this refactor, it is still too slow to add in the
view normally. We should fetch it with a lazy way.
With a DB populate with 3 company and 6 warehouses (2 for each company),
50 locations, 30K stock moves, 9K quants and 1700 products.
Before fix:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.031 ± 0.0004 sec of SQL, 0.204 ± 0.008 sec of Python
=> 0.235 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
382 SQL request, 1.334 ± 0.052 sec of SQL, 6.807 ± 0.223 sec of Python
=> 8.141 sec
After refactor:
To read 40 confirmed stock move (with forecast information):
35 SQL request, 0.029 ± 0.0004 sec of SQL, 0.074 ± 0.003 sec of Python
=> 0.103 sec
To compute 7300 forecast information (52 draft MO - 99 confirmed MO):
369 SQL request, 0.550 ± 0.009 sec of SQL, 0.969 ± 0.012 sec of Python
=> 1.519 sec
task-2579011
Part-of: odoo/odoo#77092
- Clean the `report_stock_forecasted` for the next commit.
- Add some test about the `_compute_forecast_information` to ensure
the correctness of the forecasted widget.
task-2579011
Part-of: odoo/odoo#77092
- create a second warehouse, resupply from the first
- create a product, replenish W2 from W1
- Goto Inventory Forecast
--> Issue value are wrong.
An OUT is when WH source is Set and WH dest is not set.
An IN is when WH dest is Set and WH source is not set.
closesodoo/odoo#76129
X-original-commit: ad7deb4cfced42f08733da5ed9c1233109900d87
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
We clean various graph archs taking into consideration that:
- the default type of a graph is "bar".
- a bar chart is by default stacked.
- the field attributes type="row" and type="col" does not make sense for
a graph view (since its implementation was separated from the pivot
implementation a long time ago))
- the boolean attributes should now take 1 or 0 as value (but the other
values are accepted for retrocompatibility).
Part-of: odoo/odoo#76065
In case there is a `product_qty` column added by a custom module,
`product_qty`, without specifying from which table to take it from
in the view definition, can lead to an ambiguous definition.
```
2021-08-25 12:25:31,624 1145 ERROR db_23001 odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 424, in load_modules
force, status, report, loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 315, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 202, in load_module_graph
registry.init_models(cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 370, in init_models
model.init()
File "/home/odoo/src/odoo/13.0/addons/stock/report/report_stock_quantity.py", line 126, in init
self.env.cr.execute(query)
File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 173, in wrapper
return f(self, *args, **kwargs)
File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 250, in execute
res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "product_qty" is ambiguous
LINE 21: ...AND whd.id IS NULL) OR ls.usage = 'transit' THEN -product_qt...
```
upg-23001
closesodoo/odoo#76049
X-original-commit: 13468160f8b87fa09a3eb205fb0aacf58650b829
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit removes the pdf and zpl reports for product templates and
variants. Instead, labels are printed via a new wizard allowing to
specify the label quantity, format and optional text.
There are a bunch of usual retail label sizes in pdf or zpl code
Task : 2501730
closesodoo/odoo#69690
Related: odoo/enterprise#20246
Related: odoo/upgrade#2542
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
New reception report added for non-outgoing transfers. This is intended
to support easier stock allocations by allowing dynamic MTO
assignment/unassignment, e.g. if we have an incoming transfer with
products we want to assign to an existing outgoing transfer, then we can
use the report to create a MTO link to the specific outgoing moves. To
support this assignment flow, the report also allows printing of labels
to place on the product so stock workers know which transfer/MO the
product has been assigned to.
Expected use case is when a product is purchased to fulfil a sale.
Demo data has been added so reception report can be immediately
seen/used for this flow.
Implementation Notes:
- Report has been made flexible to work with batch transfers.
- Only done moves can be assigned to moves that already have quants
reserved (prevents undesired behavior + this makes sense logically)
- Confirmed (+ Done and everything inbetween) moves can be assigned to
any confirmed moves that are not already assigned.
- Report does not affect quant reservation/unreservation at all. It
works only with linking moves (i.e. move_orig_id/move_dest_id) so
move/transfer linkage traceability is stored within db (i.e. this
isn't possible with quants)
Limitations: To keep code simple for now, this assignment flow will
break in certain cases:
1. Done amount of an assigned move is less than the Demand amount
(linked move will not autoreserve correctly when assigned move is
validated, same issue already occurs in multi-step transfer).
2. If a linked move is unreserved after its assigned move is
validated, then another move can reserve its quants and its
assignment link will not be accurate.
3. Already reserved SNs + assign move, may lead to mismatching SNs
between report and what's actually reserved.
4. Changing a linked move's Demand amount after a move is assigned to
it.
5. Potential moves to assign to are only checked for being in same
warehouse, not in a matching source location to destination location.
User is expected to make this match on their own.
Task: 2500844
ENT PR: odoo/enterprise#18268
Upgrade PR: odoo/upgrade#2731closesodoo/odoo#70669
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add reference of the traceability report's origin (production.lot,
manufacturing order, picking, ...) to the end of the
report.
Change the layout a bit so the data isn't squashed by
the border.
Task-2467686
closesodoo/odoo#74120
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The template to render location and picking barcodes was not optimized
to print lots of barcode. This could lead to extremely long documents
with a few barcodes to print.
closesodoo/odoo#74966
Opw: 2564764
X-original-commit: 7360db95c32d9cbff5cde49e0fa0e1886f88ad1e
Related: odoo/enterprise#20181
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
- Install Inventory and Studio modules
- Go to Inventory -> Products -> Products
- Open Studio
- Click on Reports tab
- Select `Product Routes Report`
Issue:
Traceback is raised.
Cause:
No 'product_id' provided in data while getting report values.
Solution:
If no `product_id` key or value in data, set `docids` (or an empty
list if no docids) as product_id and set 'warehouse_ids'
to an empty list.
opw-2619142
closesodoo/odoo#74937
X-original-commit: de6b1636818423b2d2b82f900c3b30515af73279
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
replace t-field with t-esc so it's support "or" operation
opw-2589887
closesodoo/odoo#74297
X-original-commit: 193946ff266ee947c7ca976e773849526ed119b1
Signed-off-by: Arnold Moyaux <amoyaux@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>
Before this commit, on the delivery slip, the quantities aren't
displayed at the same way if we display the move ones or move line ones.
In the first case, we print directly the value from a record, so the
float decimal is correclty placed when the float is converted into a
string.
In the second case, we get the value from a dict, so there is no
conversion and the float is simply translated into a string.
For example, for 2 qty.:
- For a move it display 2.00
- For a move line it display 2
task-2373833
Disable the link on the forecasted inventory report graph view, as it leads us to a undesired list view with traceback on opening it.
closesodoo/odoo#70488
X-original-commit: 64afb484b9785a4d739fef1207405a502d668ab8
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
- Fix tends to prevent precision overflow in forecasted report
Current behavior before PR:
- If there are 2 units in stock and product_uom_qty is set to 0.66 the free_stock will be equal to 1.3399999999999999
Desired behavior after PR is merged:
- If there are 2 units in stock and product_uom_qty is set to 0.66 the free_stock should be equal to 1.34
opw-2425473
opw-2459650
opw-2448443
opw-2446985
opw-2440853
opw-2464507
closesodoo/odoo#70321
X-original-commit: c69fb8ec6828676a1900c56f1e87df809b6b70c2
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Report stock quantity defines a custom SQL View in init function,
inline the view CTE to improve performances of the
product.template/product.product forecasted quantity reports.
Remove product_tmpl_id related attribute and add product_tmpl_id
in SQL View's Select/Group_by to allow pushing down tmpl_id filters
in query plans.
closesodoo/odoo#69555
X-original-commit: 4c62765195a6410da1c4e74c0f1a0fcf57c38e97
Signed-off-by: Rémy Voet <ryv-odoo@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>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
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
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
Currently the non-reserved moves in the availability report are sorted
by priority, date, id (same as reserved moves). This commit makes it so
non-reserved moves are now sorted by reservation_date first + the
previous ones (i.e. different sorting logic from the reserved moves).
The idea is to make it easier to reserve moves according to the set
reservation_method logic. Unfortunately there isn't an easy way to split
the sorting logic and we need to search for some overlapping moves
ordered in a different way.
closesodoo/odoo#65730
Task: 2418907
Related: odoo/upgrade#2143
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit adds 2 small feature additions to reservation logic:
1. Add another # days parameter for reserve "before scheduled date"
option for priority moves (i.e. so they can be marked for reservation
earlier)
2. Add Reserve button in the forecast report
It also cleans up some auto-reserving logic:
- 'at confirm' now has a reservation_date = day of confirmation:
- removes need to check `reservation_method` when doing automated
_action_assign (i.e. in scheduler + completed incoming move).
- allows ordering by reservation_date during automated _action_assign
for more consistent and logical reservations.
Task: 2418907
Upgrade PR: odoo/upgrade#2143
With this change, we show the variant price when printing ZPL
product.product report and not the template as we did before.
This way it is the same as what we see in Odoo as well as when printing
PDF label of the product.
targetting only 14.0 for now (but could be backported in stock_zebra)
opw-2455291
closesodoo/odoo#66415
X-original-commit: 7822b5bc76b2cbc1534b8df8d0bb3b5a3b50db0e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Replenishment is great to replace MTO but misses the direct link between SO and PO (smart buttons on both SO and PO to link to the corresponding PO and SO).
The info is actually there in the forecasted report but it is not accessible directly from the PO and in the case of the SO does not highlight the corresponding line of the SO.
This adds a graph icon in the PO, MO and receipt form to directly access the forecasted report (it already exists for SO and delivery).
The information linked to the SO/PO/MO/receipt/delivery is also sent to the forecasted report to highlight the corresponding line.
Note that in the case of the SO, the information needs to go first through the qty_at_date widget (which contains the link to the forecast report).
The graph icon for the PO, receipts and MO turns red when the forecasted quantity at expected date is negative. This is done using the new 'forecasted_issue' field.
closesodoo/odoo#62264
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Use UNION ALL instead of UNION to let PostgreSQL
filter out rows before sorting and avoid Unique check.
Note that it shouldn't change the result because each 3 SELECT
doesn't have domain intersection.
Improve performance the `_get_orderpoint_action` and the Forecasted
Inventory.
Performance Gain:
With a large Database (5K products, 120K stock move, 20K quants, etc):
To open the Forecasted Inventory:
Before: 10.06 sec +- 0.02
After: 3.98 sec +- 0.07
task-2390516
X-original-commit: 0a89bc231aaadee959deb6cda4aa09318b08f591
When using the route `/report/barcode/...` in a report, wkhtmltopdf
makes htpps requests on the server to retrieve the barcode image.
If a lot of barcodes have to be printed, this can overload the server
with too much requests and makes wkhtml crashes.
With this commit, the qweb barcode widget is used to include the barcode
as an img tag with inline barcode image as base64 data.
closesodoo/odoo#64211
Related: odoo/enterprise#15619
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Behavior prior to this commit:
If I have a pre-existing order (confirmed, but without available
product) on a product with an MTO route, and I now place a new order on
that product then confirm the generated PO, in the forecast report the
quantities from the PO will be shown as being applied to the
pre-existing order first.
For example:
- create a product with an MTO route (set a vendor)
- create a SO (SO1) for 5 units of that product and confirm it. Verify that
a PO (PO1) was generated. Cancel the PO.
- create a new SO (SO2) for 10 units of the product and confirm it. Confirm
the PO (PO2) that is generated.
- run the forecast report. It should show:
| Replenishment | Quantity | Used By |
|------------------------------------|
| PO | 10 | SO2 |
| Not available | -5 | SO1 |
But instead it shows:
| Replenishment | Quantity | Used By |
|------------------------------------|
| PO | 5 | SO1 |
| PO | 5 | SO2 |
| Not available | -5 | SO2 |
When the product is received for PO, the quantity received is correctly
applied to SO2, not SO1.
Behavior after this commit:
- when generating the forecast report, we have to tie each outgoing
shipment with 0 or more incoming shipment. After this commit, the
computation will be made without considering candidate incoming
shipments that are linked (via `move_dest_ids`) to a different
outgoing shipment.
- for receipts that are not tied to another move (move_dest_ids is
empty), there is no change of behavior
- for receipts that are "over-delivering", for example if there was a
generated PO for 10 units but they manually increased it to 15 to cover
both SO, there is no change of behavior: it will still show as
replenishing both SO.
Note:
- in a multi step environment the report does not correctly allocate
quantities once some steps of the order are processed (the quantity
will be shown as coming from stock, but in fact not all steps have been
processed), this is accepted as a known limitation to prevent making
too much of a performance hit for the MTO case (this behavior is the
same as what was present before the commit)
opw-2412137
closesodoo/odoo#63529
X-original-commit: 95435c056236438c61688855748b3afac57416a2
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
In the DB with a warehouse with a lot of stock location.
The forecasted widget return a traceback due to a memory error due
to the `_get_domain_locations_new`
(`_get_report_lines`->`read(['qty_available'])`->`_compute_quantities`
->`_compute_quantities_dict`->`_get_domain_locations`)
how returns a extremely long domain (one expression
by location in the context) to compute child location.
But the locations (put in the context) contain already
children locations because of
`('id', 'child_of', warehouse.view_location_id.id)`.
TO SOLVE
Instead of adding location in the context
(for fix 1aa6a323e04232d24175593718637c6dac295eb9),
add the warehouse in the context before
calling the `_get_report_lines` in the `_compute_forecast_information`.
closes#61666closesodoo/odoo#63377
X-original-commit: f8861e6a63fcd85295affdea4b525af753234b14
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Arnold Moyaux