The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).
We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL
"product moves" part of b2b task: 2882539
closesodoo/odoo#97109
Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Adds a new reporting view for [storable] product.product to allow for
easier analysis by product (rather than by quant which is location
specific).
This includes:
- adding 3 new fields for products:
- avg_cost = total svl value / total qty
- total_value = avg_cost / on hand
- company_currency_id = self.env.company.currency_id (i.e. the
currently selected company) for which currency symbol to display in
the view
- IMPORTANT NOTE:
- these variables (and some of the existing ones) do NOT support
multi-company aggregations due these values being used to calcuate
future svls which should be company specific. Larger refactoring
would be needed to ensure correct calc in both cases. Larger issue
occurs in stock.report which uses these variables in combination
with variables that do take into account multi-company records.
- A customized `SearchPanel` so that a warehouse context can be applied
to the view, rather than a filter. (viewable only when more than 1
warehouse)
"stock report" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Minor UX updates in purchase and stock:
Reworded (in stock):
- Default name location "Partner Locations" => "Partners"
- Default result for "Apply All" wizard "Inventory Adjustment" =>
"Quantity Updated"
- Individual "Apply" move reference/name updated for individual quants
(i.e. "Quantity Updated / Confirmed") so that the scheduled date is
no longer included
Removed (from purchase):
- Duplicated menuitems, i.e. "Purchase > Reporting > Purchase" showed
the same thing as Enterprise menuitem and both were being displayed in
Enterprise version. Also updated the no records found help message
since old message appeared to be slightly out of date.
ENT PR: odoo/enterprise#29974
"other" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Note this includes the view shown when clicking on:
- "History" button in inventory adjustments
- "Product Moves" button in scrap/product forms
- "Reporting" > "Moves History"
At time of this commit being written. Other move line views not changed
since they are specific to inputting data rather than readonly data.
Minor UX updates to stock move lines report:
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated + src/dest location filters replaced with
generic filter that checks if either meets condition
- add src/dest package to list view
- add status, lot, and from/to dest to kanban view and replace picking
with reference so inventory adjustments are visible as well
- order by date desc so most recent ones are first
- always display location src/dest to help understanding of moves
Specific to "History" button in Inventory Adjustments / Reporting >
Locations (i.e. inventory report), moved product_id from domain to
default_search for more user analysis flexibility/ease.
"product moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Minor UX updates to stock moves report:
- don't default groupby source location
- order list by date
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated
- make to location_{dest_}id text-muted when not a physical location
(i.e. internal/transit)
- display "Quantity" instead of "Demand" for product_uom_qty and show
sum at bottom of list
"stock moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Inventory report has been updated to have:
- better applicability: report renamed to "Locations" and is only
visible w/Locations, Consignment, or debug mode active
- improved UX: list view rearranged, buttons added, grouping removed,
sums added to bottom of list
- improved quant "Value": instead of the accounting value, this is now
the average unit cost (i.e. sum(valuation layer values)/sum(valuation
layer quantities) per product x on hand qty (of quant).
- single click load for products
- search based on Warehouse option (including storing
location.warehouse_id to avoid overly complex search function)
- always show "Location" column in this view even if multi-locations is
not active
"inventory report" part of b2b task: 2882539
Upgrade PR: odoo/upgrade#3819
Part-of: odoo/odoo#97109
The goal being to get rid of the `groups_id` feature for backend views
This one is a tricky case
The `create` button should not be visible in the tree and form views
of stock locations when the multi locations feature is not enabled.
If you don't have the group, you do not see the menu bringing
you to the locations list, but though it's still possible
to reach the location form view through a many2one link
on a location field missing the `groups="stock.group_stock_multi_locations"`
e.g. on the stock move form.
If you managed to reach a location form whatever the way,
if you do not have the multi locations enabled,
you shouldn't see the create button.
As we would like to remove the `groups_id` feature of the `ir.ui.view`,
we must find an alternative.
This is the only case using `groups_id` to remove the create/edit
button, so it's not like it's such a common way
to achieve this goal.
The right way to achieve this should be an ACL,
preventing you to create a location at all (even through xmlrpc)
if you do not have the multi-location feature enabled.
Though, currently, there is an ACL giving the right to inventory
managers to create locations, and this is unfortunately impossible
in the ACLs model to make a combined group rule, like you need both
the groups multi-locations and inventory manager to be allowed to create
locations.
Hence, as alternative, we enable/disable the view
removing the create button from the list and form views
when the multi-locations is enabled/disabled in the settings.
Part-of: odoo/odoo#98551
expiration
Previously, we do
{expiration,use,removal,alert}_date = receipt_date + {expiration,use,removal,alert}_time
After this commit, expiration date remains unchange, for the other 3
dates, we calculate them by
{use,removal,alert}_date = expiration_date - {use,removal,alert}_time
Task-2657043
closesodoo/odoo#86760
Related: odoo/enterprise#25419
Signed-off-by: Steve Van Essche <svs@odoo.com>
In some cases, when putting in pack, it will lead to a "unreserve more
than reserved" error
To reproduce the issue:
1. In Settings, enable "Packages"
2. Create a storable product P
3. Update the on-hand quantity: 0.4 x P
4. Create and mark as todo a planned delivery order DO
- Operations: 0.4 x P
5. In the detailed operations, set the done quantity to 0.3
6. Put in Pack
7. Open the detailed operations
- Error: There is a line with 0.11 x P reserved instead of 0.10. The
total reserved quantity is therefore 0.41 which is not possible.
Moreover, the available quantity of the related quant is 0.29 which does
not make sense
8. Set the done quantity to 0.1
9. Put in Pack
10. Validate
Error: a User Error is displayed "It is not possible to unreserve more
products of ... than you have in stock." The user is now stuck, he can
neither process the picking nor unreserve it.
On step 6, when putting in pack, we split the SML into two ones. To do
so, we also split the reserved quantity:
https://github.com/odoo/odoo/blob/fcc74186330c8df37cfac08455bd7bba44d4656b/addons/stock/models/stock_picking.py#L1384-L1388
However, because of a floating point issue, we have:
`0.4 - 0.3 = 0.10000000000000003`
Therefore, since we use the rounding method `UP`, we have:
```py
ml.product_uom_qty == 0.4
quantity_left_todo == 0.11
done_to_keep == 0.3
```
And we then use these values to update the reserved quantity on each
SML:
https://github.com/odoo/odoo/blob/fcc74186330c8df37cfac08455bd7bba44d4656b/addons/stock/models/stock_picking.py#L1391-L1398
When writing on that field, we also try to update the quants:
https://github.com/odoo/odoo/blob/55921e32baa1b4b226bd43edf20e93619e411905/addons/stock/models/stock_move_line.py#L378-L383
(As shown, if an error is raised, we ignore it)
After the reservation of `quantity_left_todo`, there are 0.29 x P left.
Therefore, when trying to reserve `done_to_keep`, it will raise an
error:
https://github.com/odoo/odoo/blob/b5d16141dc48d4379452ea40e167f3b00f956c20/addons/stock/models/stock_quant.py#L679-L680
But as shown above, the error will be ignored. This explains the
inconsistency between the reserved quantity on the SMLs and on the
quant.
On step 10, when validating the picking, we try to unreserve all SMLs:
https://github.com/odoo/odoo/blob/55921e32baa1b4b226bd43edf20e93619e411905/addons/stock/models/stock_move_line.py#L570-L572
So we will try to unreserve more than actually reserved on the quant.
That's the reason why an error will be displayed.
OPW-2942054
closesodoo/odoo#98521
X-original-commit: 4f593706ee6d1b3ddf0f1c9c90c86df2977459d9
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Reproduce steps:
- Create P1: storable, tracked by SN, manufacture
- Create C1: storable, tracked by lot
- Add 100 unit of C1 in Stock location
- Add 2 unit of P1 in Production location
- Create BoM for P1 with C1 as component
- Create MO for 2 unit of P1 > Confirm > Mass Produce > Generate Serials > Apply
=> Traceback on ensure_one()
In mrp_production.py in _split_productions(), the 'move_id' field is removed before unlink() is called in order to avoid calling recompute_state().
As move_id is not guaranteed to exist, we need to check before using it.
OPW-2878461
closesodoo/odoo#98391
X-original-commit: 6f2b7af37468d97b8dd4eb6c8e4bdcbaf472a331
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: DavidFesquet <dafr@odoo.com>
To reproduce the issue:
(Need stock_barcode)
1. Create a product:
- Barcode: 1234567890123
2. Print the label
3. Try to scan the barcode and check the value read.
Error: The value is 1234567890128, the last digit is incorrect (8
instead of 3)
When printing a barcode, we use the library 'report-lab' to generate a
barcode image from a value and a barcode type. In case of EAN-13, if the
value contains a non-digit character, it will raise an error. We then
catch the error and retry to generate the barcode according to the
barcode type Code128:
https://github.com/odoo/odoo/blob/87698d90f02bfe93c6e643f4876a5ccd74788eff/odoo/addons/base/models/ir_actions_report.py#L569-L575
However, if the value contains only digits, the method will use the 12
first digits:
https://github.com/mattjmorrison/ReportLab/blob/dade0f303cb6fcdbe535c4cc92e6102c2417b699/src/reportlab/graphics/barcode/eanbc.py#L187-L188
and will then add the last one, the check digit, which is computed by
the library. This explains why, in the above use case, the barcode value
returned by the scanner is not the same than the expected one.
Note: Similar behavior with type EAN-8
OPW-2902150
closesodoo/odoo#97052
X-original-commit: a2c7470f8fd46b2520f7b8f0750c63216273ce96
Related: odoo/enterprise#30160
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When creating a receipt with products tracked by lot or serial number,
empty move lines are automatically created when the receipt is validated
Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Configuration > Warehouse Management > Operations
Types
3. Open Receipts and enable 'Show Detailed Operations' and 'Pre-fill
Detailed Operations'
4. Go to Overview > Receipts and create a new receipt, in Detailed
Operations add product 'Cable Management Box' with any serial number
and a quantity of 1
5. Validate the receipt, a new line is added in Detailed Operations with
quantity 0
Solution:
When we create a stock move line and we need to create a lot, we create
the lot with the context key `do_not_unreserve`
Problem:
When we create and write the lot on stock move lines, we detect that the
`product_uom_qty` is not set. Because we are in an immediate transfer,
we will try and assign it the `quantity_done`.
https://github.com/odoo/odoo/blob/7fec535f3d84d15899aea5e61b51947f260d9697/addons/stock/models/stock_move_line.py#L467-L469
By writing the `product_uom_qty` on the stock move, we will try to
unreserve and reserve again the stock move (if `do_not_unreserve` is not
in the context)
https://github.com/odoo/odoo/blob/ba3bb9b701a382c4052ddb57392baeee32625937/addons/stock/models/stock_move.py#L569-L576
This will then create the undesired empty move lines (that are supposed
to be the 'Pre-filled Detailed Operations') in _action_assign
https://github.com/odoo/odoo/blob/3e8a45fce0af0aa5792f0aea978d4ab78ab50a40/addons/stock/models/stock_move.py#L1586
opw-2897875
closesodoo/odoo#95983
Signed-off-by: Tiffany Chang <tic@odoo.com>
2-steps receipt. A reordering rule created a picking from Input to Stock
and a purchase order to fulfill the need from Input. The user now
decreases the quantity of the purchase order and then confirms it: an
unexpected picking is created.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- With a vendor
- Routes: Buy
4. Add a reordering rule to P:
- Min = Max = 0
5. Create and confirm a planned delivery order with 5 x P
6. Run the scheduler, it should create:
- An internal transfer IT (Input -> Stock) with one stock move SM
- A purchase order PO
7. Edit PO:
- 4 x P (instead of 5)
8. Confirm PO
9. List all transfers related to P
Error: There is a transfer from Stock to Input with 1 x P. It should not
exist and its stock move should be merged with SM
As explained, when running the scheduler, a stock move from Input to
Stock is created. Let SM01 be that stock move.
When confirming the PO, two stock moves SM02 and SM03 are created, both
from Vendors to Input. The first one has a quantity equal to 5 and the
second one to -1. When confirming these stock moves, we apply the 'push
rules'
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1233
Since SM02 already has one `move_dest_ids` (i.e., SM01), we skip it.
However, we can apply a push rule on SM03. It creates an new stock move
SM04 with -1 x P from Input to Stock:
https://github.com/odoo/odoo/blob/7e8a038e3a08e32a9a32ac66ef0dc67800af95cb/addons/stock/models/stock_rule.py#L192-L196
And, as shown in the above code, we then define this new SM04 as a
`move_dest_ids` of SM03. So, at that point, here is the situation:
| Name | Qty | From | To | Dest |
|------|-----|---------|-------|------|
| SM01 | 5 | Input | Stock | / |
| SM02 | 5 | Vendors | Input | SM01 |
| SM03 | -1 | Vendors | Input | SM04 |
| SM04 | -1 | Input | Stock | / |
Back to the confirmation of SM2 and SM3, we eventually try to confirm
the moves created from push rules (i.e., SM04):
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1268-L1269
As shown, we don't define any `merge_into`. During the confirmation of
SM04, we try to assign it to a picking. However, because of its negative
qty, we skip it:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1077-L1081
Then, still in the confirmation of SM04, we try to merge it with some
other SMs. Because there isn't any `merge_into`, we try to find some
candidates:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L839-L840
And because SM04 does not have any picking, we don't find any candidate:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L826-L828
As a result, we don't merge it and we will create the unexpected
picking.
=> In such situation (when confirming a negative push move), we should
suggest some candidates.
Last but not least: suppose the above issue as fixed and reproduce the
same steps, but this time the product P has a description. Again, when
confirming the PO, the same unexpected picking will be created.
When running the scheduler, SM01 is created and its field
`description_picking` is defined thanks to the description of P:
https://github.com/odoo/odoo/blob/f11d9c3ea08fc98e62459602d9bce004e83898db/addons/stock/models/product.py#L237-L243
However, when creating SM03, we use the name of the purchase line (i.e.,
the product's name) as description because, in our case, the product
does not have any `description_pickingin`:
https://github.com/odoo/odoo/blob/c18b2ce767dd5a5b4dbe766b849b56243dffb723/addons/purchase_stock/models/purchase.py#L523
And, as shown before, SM04 is partially a copy of SM03: it has the same
`description_picking`. As a result, SM01 and SM04 doesn't have the same
value for that field and we can not merge them.
OPW-2861605
closesodoo/odoo#97599
X-original-commit: 43ca47cdfec696b847f716984f76df16de7b97b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
this commit will allow users to setup replenish locations and replenish
them directly if they have negative forecast
instead of checking forecast qty per warehouse,
this adds the abiltiy to replenish to any internal stock location,
marked as replenish location, instead of just the warehouse location
Task Id: 2796757
closesodoo/odoo#93633
Related: odoo/upgrade#3626
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. In the Routes, unarchive the route R called "Replenish on Order
(MTO)"
3. Create a storable product P
4. Update its quantity: 10
5. Create and confirm a sale order with one line:
- Product: P
- Quantity: 10
- Route: R
6. Update the SO line:
- Quantity: 8
Error: Once the SO is saved, 2 new deliveries are created:
- One from Customers to Stock with 2 x P (this one should be merged with
the existing one)
- One from Stock to Vendors with 2 x P (his one should not exist)
The route R only contains one rule, which is a MTSO one. On step 5, when
confirming the SO, `_run_pull` will be called and will create a stock
move SM01 based on that rule. In case of a MTSO rule and because there
are already some available P, the procure method of SM01 will be MTS
(see [1]). Then, once SM01 is created, we will confirm it and we won't
do anything more.
The process is not the same on step 6. When saving the SO, `_run_pull`
is called again but this time, because the needed quantity is negative
(-2), the procurement method is set to MTO (see [1]). Therefore, when
confirming such a stock move, two undesirable consequences occur:
- Because its procure method is not the same than SM01, we won't merge
the stock moves (this explains why a picking is created from Customers
to Stock)
- Because its procure method is MTO, we will create and run a
procurement to get -2 x P at Stock. It will find a rule thanks to the
route "Receive in 1 step". The rule creates a receipt from Vendors to
fulfill the need. This explains why an unexpected picking is created.
When processing a procurement with a MTSO rule and a negative quantity,
if we want to know the procurement method of the new SM, we should try
to find and copy the decision we took for the positive move (if it
exists). That way, we ensure that the 'returning phase' (the quantity
decreasing) will follow the same behavior as the initial one (when we
confirmed the SO).
[1]
https://github.com/odoo/odoo/blob/20e0ad13afa2a0ff85d555ab57a6800d3db30341/addons/stock/models/stock_rule.py#L244-L254
OPW-2885751
closesodoo/odoo#97332
X-original-commit: 8c6d282de13b205436a7c5c49facd3efc71a740f
Signed-off-by: Adrien Widart <awt@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
When getting the on hand quantity of a product in a specific location,
the result may be incorrect.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update its quantity:
- 5 x P at WH/Stock/Shelf 1
4. Inventory > Reporting > Inventory Report
5. Apply the following filters:
- Product: P
- Location: WH/Stock/Shelf 1
- => There is a line with 5 x P at WH/Stock/Shelf 1, which is
correct
6. Click on Inventory at Date, set <Today>, confirm
7. Apply the following filters:
- Product: P
- Location: WH/Stock/Shelf 1
Error: There is a line for P but its on hand quantity is 0, which is
incorrect (should be 5)
In the first search, we let the ORM handle the domain conversion. When
searching for `('location_id', 'ilike', 'WH/Stock/Shelf 1')`, it will
use the `_rec_name` of the model to find the record. In case of a stock
location, its `_rec_name` is the field `complete_name`:
https://github.com/odoo/odoo/blob/94a8ad3fae914b046064bb7ce17572be8280f6e0/addons/stock/models/stock_location.py#L19
However, for the second search, when getting the on-hand quantity of the
product, we force the use of the field `name` to find the location.
Because the `name` of the searched location is "Shelf 1", using
"WH/Stock/Shelf 1" as key search will not work.
OPW-2920904
closesodoo/odoo#97187
X-original-commit: 9a651e13440d807ce3f455a3d334fa90caa3ce04
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
On the commit 69dcdd4, the order='create_date desc'
was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
In addition, the now declaration should be at the beginning of the method action_replenish.
(The MO created is correct, only the notification is wrong)
Should be forwarded
OPW-2877457
closesodoo/odoo#96986
X-original-commit: 029da238a2baaf59bdf9ae828a4739ee4a9f3ede
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
On the commit 69dcdd4, the order='create_date desc'
was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
(The MO created is correct, only the notification is wrong)
OPW-2877457
closesodoo/odoo#96856
X-original-commit: b80287b265a4c01babedcbb58459c35d36a48066
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When a user exports a picking with the option 'import-compatible', he
won't be able to import the record later.
To reproduce the issue:
(Need stock. Use demo data)
1. Inventory > Operations > Transfers
2. Select a transfer (without opening it)
3. Action > Export:
- Enable the option "import-compatible"
- Add the field "Operation Type"
- Export the transfer
4. Back to the transfers list view, click on Import
5. Load the exported file and click on Test
Error: An error message is displayed ("No matching record [...] in field
'Operation Type'"). However, the option "import-compatible" was enabled
and the operation does exist, so the record should be found.
When exporting a record, if one of the selected fields is a relational
one, we use its `display_name` as value:
https://github.com/odoo/odoo/blob/5797fd80a63309269f15bcbe4948d4429a53eec2/odoo/models.py#L883-L886
Then, when importing, we use `name_search` to retreive the record:
https://github.com/odoo/odoo/blob/662ecf4e20ceab92b62804cb2a06e51f6b897623/odoo/addons/base/models/ir_fields.py#L406
Back in the use case: if an operation type has a warehouse, its display
name will be the combination of the warehouse name and its name:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L146-L151
However, the `_name_search` does not handle this type of search key:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L157-L164
Therefore, using that value ("Warehouse: Operation name") in this
`name_search` will not work.
According to the review from odoo/odoo#95526, such a model is considered
as broken: "if the display name (`name_get`) is overridden, then the
`name_search` should be overridden to match". Moreover, the generic
solution proposed in the previous PR would not work in case of
multi-warehouses.
OPW-2739786
closesodoo/odoo#96768
X-original-commit: 456784ca98b3e3bc30c40b1cffe46574930ae492
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
When canceling a transfer, all its moves and move lines having qty done
(if any) are canceled as well. But this doesn't happen on package levels
having such move lines with qty done filled, the state was set to
'confirmed' while all its move lines are 'cancel', which was not
consistent.
closesodoo/odoo#96764
X-original-commit: d9b16c3732c7e935c21a0396bb01ed4f19456827
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When receiving more than expected, we try to redirect the SM thanks to
the putaway rules. This can lead to undesirable behaviors.
To reproduce the issue:
1. In Settings, enable 'Storage Locations'
2. Create a storable product P
3. Edit the operation type "Receipt":
- Show Detailed Operations: True
4. Create and confirm a planned receipt for 1 x P
5. In the Detailed Operations:
- Set the done quantity to 3
- Set the destination location to Shelf 1
6. Validate the receipt
Error: The destination location of the SML has changed: Stock. It should
still be Shelf 1
When validating the SM, because the done quantity is more than the
demand, an exra-move is created. During such a process, the extra move
is confirmed and assigned, so it leads to the destination redirection
thanks to the putaway rules (that's the reason why the destination Stock
will be selected and defined on the SML).
In such situation, we should not try to apply the putaway rules.
OPW-2900283
closesodoo/odoo#96124
X-original-commit: 0183298293192538a801f52262c047ea34a1b76a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Adding a @depend decorator on product_id in the stock_move_line model can trigger a search on stock.move.line.product_id
When the number of StockMoveLine reach a million, a simple `SELECT id FROM stock_move_line WHERE product_id = XXX` can take 200ms.
When a transfer contains a few hundred StockMoveLine (ex: when dealing with serial numbers), the process of validating it will take a few minutes.
Indexing product_id will change the process time back to a few seconds.
OPW-2893131
closesodoo/odoo#95511closesodoo/odoo#95915
X-original-commit: b8156cf9a2d01448244c306c24c3c55687fd0d23
Signed-off-by: DavidFesquet <dafr@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
In a multistep configuration, decreasing the quantity on a line of a
confirmed sale order may create some inconsistencies.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the existing warehouse:
- Outgoing Shipments: 3 steps
3. Create a storable product P
4. Set the on-hand qty to 5
5. Create and confirm a sale order SO with 5 x P
6. Process the PICK/PACK pickings
7. Edit the SO:
- Decrease the qty: 3 x P
8. In the SO's deliveries, open the return of the pack step (Output ->
Packing)
- Error: Nothing changes, there isn't any reserved quantity.
However, there are currently 5 x P at the Output location, so the
reservation should work
9. Inventory > Report > Stock Moves, list all SM related to P
- Error: The origin/destination moves of the pack's return (Output
-> Packing) are incorrect too: the origins contain the pick's return
(Packing -> Stock) while it should not contain anything and the
destination moves contain the ship move (Output -> Customer) while it
should contain the pick's return (Packing -> Stock)
`SM_ship`: SM used to deliver from Output to Customers
`SM_ret_ship`: SM used to return P from Customers to Output
`SM_ret_pack`: SM used to return P from Output to Packing
`SM_ret_pick`: SM used to return P from Packing to Stock
When confirming a move, we transform the move if its demand is negative:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1239-L1247
We reverse the source/destination locations but we don't do the same
with the origin/destination moves. That is an issue: before reversing,
we have:
| SM | Qty | From | To | Origin | Destination |
|-------------|-----|---------|-----------|-------------|-------------|
| SM_ret_pick | -2 | Stock | Packing | / | SM_ret_pack |
| SM_ret_pack | -2 | Packing | Output | SM_ret_pick | SM_ret_ship |
| SM_ret_ship | -2 | Output | Customers | SM_ret_pack | / |
Therefore, reversing the source/destination locations without updating
the origin/destination moves does not make sense: we should reverse them
too depending on their direction (positive/negative) and their
source/destination location.
Also, before trying to transform the moves, we try to merge them:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1236-L1237
This is relevant for `SM_ret_ship`: we find an existing SM (`SM_ship`,
qty=5) that can absorb the negative demand of `SM_ret_ship` (qty=-2). In
such case, we add the origin/destination moves of the negative SM to the
positive one. However, in the above case, it will create an
inconsistency: after the fix, at that point, `SM_ret_pick` and
`SM_ret_pack` have been correctly reversed, so we have:
| SM | Qty | From | To | Origin | Destination |
|-------------|-----|---------|-----------|-------------|-------------|
| SM_ret_pick | 2 | Packing | Stock | SM_ret_pack | / |
| SM_ret_pack | 2 | Output | Packing | SM_ret_pack | SM_ret_pick |
| SM_ret_ship | -2 | Output | Customers | / | SM_ret_pack |
| SM_ship | 5 | Output | Customers | (SM_pack) | / |
Therefore, adding `SM_ret_pack` to the destination moves of `SM_ship` is
incorrect. (Note that, without the fix, `SM_ret_pack` would be added to
the origins of `SM_ship`, which would be incorrect too)
Finally, the reservation (step 8) does't work because of two reasons:
- If there are some `move_orig_ids`, we use the done value of these SM
to assign the current SM. However, as explained above, there is an issue
with this field
- If there isn't any `move_orig_ids`, there is an issue with the procure
method. Its value is `make_to_order`: we skip the reservation for such a
value:
https://github.com/odoo/odoo/blob/53b424d9e43b07fe7aa84ff00035fb7772ef6291/addons/stock/models/stock_move.py#L1499-L1501
OPW-2889679
closesodoo/odoo#95263closesodoo/odoo#95926
X-original-commit: fb94c140a91aca26a56c5162d61b00b4a4b0d85b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
This follows revision
odoo/odoo@9925c8fbaf
On creation of an orderpoint,
if warehouse and location are not specified,
set default warehouse and location
if warehouse is specified but not location,
set default location according to the warehouse chosen
(and not the location of the default warehouse, as formerly)
if location is specified, but not location,
set default warehouse according to the location chosen
(and not the default warehouse, as formerly)
if warehouse and location are specified,
let them, do not overwrite them.
closesodoo/odoo#95851
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Convert the onchange on `picking_type_id` to a compute field
This allows to create a `stock.picking` record without
the need to specify the locations during the creation nor calling the onchange
method. The locations defaults from the picking type locations.
This way, if the database is not configured to use multi locations,
the users do not have the specify the UOM to use.
For instance during an XMLRPC call to create a picking.
closesodoo/odoo#95423
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This allows to create a stock.package_level record without
the need to set the `location_dest_id` during the `create` call.
For instance, this makes easier to create a package level
using XMLRPC when you do not use multiple locations.
closesodoo/odoo#95361
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This allows to create a stock.warehouse.orderpoint record without
the need to call the onchanges to set the warehouse and location
or to set it manually during the `create` call.
For instance, this makes easier to create orderpoints
using XMLRPC when you do not use multiple locations.
closesodoo/odoo#95352
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This allows to create a stock.move record without
the need to call the onchanges to set the uom
or to set it manually during the `create` call.
This allows to create a stock.move.line record
without the need to call the onchanges to set the uom and locations
or to set it manually during the `create` call.
For instance, this makes easier to create stock moves
using XMLRPC when you do not use multiple UOMs or multiple locations.
closesodoo/odoo#95332
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Fixes 38bfbed
We cannot create a `set` from `None`
```
File "/home/odoo/src/odoo/15.0/addons/stock/models/stock_production_lot.py", line 225, in <listcomp>
delivery_ids.update(*[set(delivery_by_lot.get(lot_id)) for lot_id in (producing_move_lines.produce_line_ids.lot_id - next_lots).ids])
TypeError: 'NoneType' object is not iterable
```
Small optimization: no need to create a list that's immediately unpacked.
This error was detected during upgrades.
upg-360084
closesodoo/odoo#95398
X-original-commit: 1870ef4cf4c177846fce72325ff3f2fa97224417
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
Rewrite _find_delivery_ids_by_lot to reduce the number
of recursive calls by grouping the producing move lines
together before each recursive calls. This reduces
the number of search calls, speeding up the whole method.
Add a unittest to check if the delivery_ids field
of a lot recordset is properly computed.
opw-2824464
X-original-commit: e7b9f14d4a9ce4ed61451b24b567f751fb4bcbe2
Part-of: odoo/odoo#95398
Updating the scheduled date of a delivery doesn't update the quantity to
order of an orderpoint
To reproduce the issue:
(Need purchase)
1. Create a storable product P with a seller
2. Create and confirm a planned delivery D with 1 x P
3. Open the replenishment page
- There should be a line for P (Forecast: -1, To Order: 1)
4. Edit D and postpone the scheduled date
5. Go back to replenishment page
Error: The line is still present, its forecast qty is correct (0) but
the quantity to order is still 1 (instead of 0)
`qty_to_order` is a stored field, so when loading the replenishment
page, its compute method is not called. Moreover, even though
`qty_to_order` depends on `qty_forecast` and the compute method of
`qty_forecast` is called, it still won't trigger the compute:
when setting the value of `qty_forecast` from its compute method, it
will lead to:
https://github.com/odoo/odoo/blob/b54f78de307543efcea934206806f361eaac811a/odoo/fields.py#L1106-L1109
So, as shown and explained, we bypass the `write` of `BaseModel` and
skip the business logic and the recomputations
The compute of `qty_to_order` should actually be triggered earlier: when
we edit the scheduled date (step 4). That's the reason why this commit
adds a dependency to the compute of `qty_forecast`: it makes more sense
and becomes an implicit dependency of `qty_to_order` -> update the
scheduled date will trigger the compute of `qty_to_order`
OPW-2868167
closesodoo/odoo#94400
X-original-commit: 791b68fc02cbc4dc5b376e5fc5d37e725f88d0dc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
In picking type, we introduce a new setting ask-always-never setting for
creating backorder. When a backorder is needed, the behaviour will be
different according to this setting:
- ask: popup a wizard to ask if a backorder is needed
- always: generate backorder automatically
- never: no backorder
The main reasoning behind this change is that there are some scenarios
in which operators always create backorders (e.g. by validating the
transfer after scanning a pallet and setting quantities). Hence, always
asking if the user (operator) wants to create a backorder can be confusing.
task-2648993
Part-of: odoo/odoo#83462
Sorting the `stock.quant` by lot_id didn't work correctly
Steps to reproduce:
1. Install Inventory
2. Edit a product tracking to 'By Unique Serial Number' (e.g. Acoustic
Bloc Screens)
3. Go to Inventory > Overview > Receipts, create a receipt for 3
Acoustic Bloc Screens with serial number '05', '01' and '03' and
validate
4. Go to Inventory > Reporting > Inventory Report, remove the
'Group By' filters and sort the entries by Lot/Serial Number
5. The serial numbers are not properly ordered ('01' is between '03'
and '05')
Solution:
Order the `stock.production.lot` by name
Problem:
Sorting the `stock.quant` by lot_id used the id of
`stock.production.lot`
opw-2879464
closesodoo/odoo#94358
X-original-commit: 4c855bd3eeb7ffcebd76eb4eaa1e41edf2935021
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Avoid leaks in case of exception.
closesodoo/odoo#93993
X-original-commit: 1a1a10b7ce53f24eabed3e3a38f34b354d2d1911
Signed-off-by: Christophe Simonis <chs@odoo.com>
Currently, certain fields take the decimal accuracy of the product_uom
whilst other's don't follow this logic.
This causes a discrepancy between the decimal accuracy of all fields
where there should be none.
The purpose of this commit, is to stay consistent across all fields in
the view.
closesodoo/odoo#93935
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the product:
- Create a new product:
- Select “Service” type
- Go to the Sales tab:
- Select "Create a task in an existing project" in the `service
tracking` field
- the `project` field becomes visible
- Change the Type of the product to “Consumable”
- Try to save
Problem:
The field `project` remains visible and as it is a required field,
we have to fill it in before being able to save the product.
While it is a feature only for service-type products
Solution:
- The `project` field is based on the `service_tracking` field
to become invisible or not. So when the product is not of service type,
we must remove the tracking service so that the project field
becomes invisible.
- Prevent the user from changing the type of products already used in
a sale order
opw-2858064
closesodoo/odoo#93804
X-original-commit: 102951140e3f35ced8653d4bedb82b63bb2c963f
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
- Install stock
- Go to Inventory > Configuration > Settings and enable "Lots" and "Storage Locations"
- Create a Product tracked By Lots (i.e. Product X)
- Go to Inventory > Operations > Inventory Adjustments
- Create an Inventory Adjustment for Product X:
Product | Location | Lot/SN | Real Quantity
-------------------------------------------------------------
Product X | WH/Stock | LOT 01 | 20
Product X | WH/Stock | | 10
- Validate Inventory
- Go to Inventory > Operations > Transfers and create one:
* Source Location: WH/Stock
* Destination Location: WH/Stock/Shelf1
* Operation Type: Internal Transfers
* Operations:
[Product: Product X, Initial Demand: 25]
- Save Transfer, Mark As Todo and Check availability
- Click on list icon of Operation line for Product X to display Detailed Operations
- 20 units of LOT 01 and 5 units without lot have been reserved
- Set LOT 01 for the 5 reserved units without lot and confirm
- Open Detailed Operations again
- There are now 20 units of LOT 01 and 5 units of LOT 01
- Remove the row with 5 units and confirm
- Check availability and open Detailed Operation
- There is now only a row with 25 reserved units of LOT 01
- Unreserve
The following errror is raised:
"It is not possible to unreserve more products of P than you have in stock."
It happens because the system is not able to manage quants with lots and
wihtout lots at the same time. When modifying the move line to 25
reserved units. It's composed of 20 quants with lot and 5 quants without
lot. And when unreserving it will check if there is a quants with 25
units with the lot and if it's not found 25 units without lot. But never
25 units of quants with lots and without lots.
opw-2419444
Close#64497closesodoo/odoo#66029closesodoo/odoo#93141
X-original-commit: 83d55d8ed8b8b5a5232e3cdfc09abf5285f18ed7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since https://github.com/odoo/odoo/pull/86682, when a user opens
the replenishment view, the Days to Purchase are not taken into
consideration when calculating the forecast of a product.
This was due to the fact that the Days to Purchase are now taken from the
orderpoint and not from the company settings. This is fixed by taking
the company setting if no value from the orderpoint is sent to the
method.
closesodoo/odoo#93252
Task-id: 2871408
X-original-commit: ac1df1949e4523aff65543f1381300fc7de3b4e4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: npi-odoo <npi@odoo.com>
account.account: code was already in unique constraint
account.journal: inverting compound unique constraint to benefit from indexing company_id
hr.employee: user_id already in unique index
phone.blacklist: number already in unique index
stock.orderpoint: product_id already in unique constraint/index
closesodoo/odoo#92932
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Tiffany Chang (tic)