Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
This reverts commit 656d8ace87.
The rational was: "If people don't have inventory, they will need a
backorder anyway and it's logical to not display the popup even
if the picking type has 'ask' for create backorder".
Also for the barcode application in OE we only show the reserved lines and
you could have the message if the picking was not fully reserve. Even if
you completed all the lines. So we could have a single flow for backend
and frontend.
But it's difficult for poeple to understand that the backorder is
base on the reservation and not on the initial demand. So we do a
step back. On top of it, people usualy won't mix flow. So they
could totaly use the "always create a BO" option on picking type
when they use the barcode and "ask" when they use the backend.
closesodoo/odoo#136725
X-original-commit: ed291c4d47783c5912ffb40db7893c321ccdb1e2
Related: odoo/enterprise#47959
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
On a putaway rule, the "Having Category" condition is not always
respected.
To reproduce the issue:
1. In Settings, enable:
- Storage Locations
- Storage Categories
2. Create a Storage Category SC:
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- L2 only:
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Store to: WH/Stock
- Having Category: SC
5. Create one storable product
6. Update its on hand quantity:
- 1 product at L1
7. Create a planned receipt R for one product
8. Mark the receipt as Todo
9. Click on 'Set Quantities'
10. Open the detailed operations
Error: The destination location is L1. The putaway rule has been
applied without the storage category constraint: the destination
location should be L2
When applying the putaway rules, we first check if one of the
relevant locations already contains that product. And, if it's the
case, we use that location as destination location. However, we
don't filter out the locations without the correct storage category.
This explains why L1 is found and used.
OPW-3437174
closesodoo/odoo#131361
X-original-commit: 66c11acdbedf8d1bcae6deb8ec54c5da5a3ae16d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
When creating a scrap order on a product which has at least one kit BoM, an option is added to create a scrap order for this kit.
The user can select from the kit BoMs of this product and the scrap order will add stock moves for all the components of the selected kit instead of for the product itself.
Task: 2479234 (nr 9)
Community PR: https://github.com/odoo/odoo/pull/114315
Enterprise PR: https://github.com/odoo/enterprise/pull/37764
Part-of: odoo/odoo#114315
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
An error appears when we try to change the product in transfer line via
product/search
steps to reproduce the error :
1- create 2 products : Test 1 (UoM is Cm) and Test 2 (Uom is g)
2- create a delivery order and add Test 1
3- UoM error due to the UoM not being updated at the time of change
The error was happening because when updating the product directly in
the line section , the stock_move item already has a UoM and the if
statement makes it impossible to change it , so the error appears.
opw-3231298
closesodoo/odoo#117504
X-original-commit: ece3dea8c1ab43a854a57513cc317e8618010542
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Steps to reproduce the bug:
- Create a Storable product “C1” tracked by Lot:
- Update the Qty to 10
- Create a Storable product “P1”:
- Add a BoM:
- add 1 unit of “C1” as component
- Enable 3 steps for the manufacturing operation in warehouse settings
- Create a Mo to produce 1 unit of “P1”:
- Confirm the MO
- Click on related transfer:
- Select the “Pick component”
- check that the qty is reserved correctly
- Try to validate it without setting Qty done
- The immediate transfer is triggered, validate it
Problem:
The backorder's wizard triggers when it shouldn't
To know if we should create a backorder, we check if the qty reserved
is equal to the qty done, and as the qty done was not set correctly
during the validation of the immediate transfer, the two quantities
are not identical, therefore the widget is trigger:
https://github.com/odoo/odoo/blob/15.0/addons/stock/models/stock_picking.py#L1128-L1132
opw-3240264
closesodoo/odoo#117706
X-original-commit: dd44e1f69dfd217fafa9c2ec5da8b211b2ff3513
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
How to reproduce:
- Create a tracked product;
- In the receipt picking type form view, for the lot and serial numbers,
uncheck "Create New" and "Use Existing ones";
- Create a planned receipt for some of this tracked product;
- Confirm and validate the receipt:
It opens the "Immediate Transfer" wizard;
- Apply the immediate transfer:
-> It asks if you want to create a backorder.
Since the picking type doesn't use new or existing LN/SN, it accepts to
be confirmed even if some move lines for tracked product have no
tracking numbers.
The issue was, when a `stock.move` sets its done quantity to its
reserved quantity, if its product is tracked, it doesn't change its done
quantity if it has no tracking number, regardless the picking type's
configuration.
OPW-3186155
closesodoo/odoo#115234
X-original-commit: 89567288e9c134f1262e8ba8b5fc65f730a239cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
This commit allows the user to choose which quants to reserve from stock
and the quantity to reserve from each quant, making reservation much more
flexible from the picking form.
In addition, the `reserved_uom_qty` of stock.move.line
is now editable in views to allow for users to change the qty reserved
by existing move lines. When editing the reserved qty, if quantity is not available,
it will reserve only what is available..
closesodoo/odoo#106006
Taskid: 3090913
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Issue:
Since PR #80434, for versions 15.2 onward stock.move.line changed the
product_qty field to reserved_qty. When doing this change, the compute and
inverse function definitions were changed, but the inverse method on the field
was never corrected. This means that if something tries to write to reserved_qty
a traceback will occur:
AttributeError: 'stock.move.line' object has no attribute '_set_product_qty'
To recreate this error, make a write call on stock.move.line to reserved_qty
and you will get the traceback instead of the UserError.
Solution:
Change the field's definition to the correct function name (_set_reserved_qty)
leads to the proper UserError instead of a traceback.
opw-3204213
closesodoo/odoo#113812
X-original-commit: 5ac0568af2909864a2231309fa3e72397a581957
Signed-off-by: Tiffany Chang <tic@odoo.com>
In `_check_backorder`, changes the condition so it checks if the qty
done is enough compared to the actual reserved quantity (instead of the
demand).
Also, removes an unused bloack of code and makes minor visual changes.
task-3076044
Part-of: odoo/odoo#109511
Small copy/paste error during odoo/odoo#95332 made it so
`line.picking_id.location_id` was used when assigning `location_dest_id`
of a directly created `move.line` in a picking. Usually this would not
be noticeable due to `default_location_dest_id` in the views ensuring
the correct value, but move lines created directly will be incorrect.
In addition to adding this case to existing test, the test has also been
updated to use non-default locations to ensure no other default values
are causing the result to be correct when it may not be under other
circumstances.
Issue noticed during master refactoring to remove location_id /
location_dest_id fields from views when multi-location is not active.
closesodoo/odoo#110672
X-original-commit: 74bfa154dde72ce792428521aea128408965dcc1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- create a storable product with serial_number tracking
- create an confirm a PO that porduct
- recieve the product
- add serial_numbers to the list view and enter a number
- validate the reciept
- an error pops up (You need to supply a Lot/Serial Number for product)
Bug:
entering a serial_number creates a new stock_move_line with qty_done
while also setting qty_done of the already exising line
Fix:
If a stock move line already exists to reserve the product
use the existing line instead of creating a new one
opw-3060668
closesodoo/odoo#110407
X-original-commit: f1541c62b099ab40c295c60e86094232f5c51a2c
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
When applying the putaway rules, if we redirect a package (with a
specific type), we don't check the category of the package products.
To reproduce the issue:
1. In Settings, enable
- Packages
- Multi-Step Routes
- Storage Categories
2. Edit the warehouse:
- Receipt: 2 steps
3. Create three categories C1, C2, C3
- Parent: All
4. Create three locations L1, L2, L3
- Parent: WH/Stock
5. For each location Lx, create a putaway rules PRx:
- From: WH/Stock
- Category: Cx
- To: Lx
6. Create a product P
- Type: Storable
- Category: C2
7. Create a planned receipt R with 1 x P
8. Mark it as todo, set the done quantity and put it in pack
9. Set a type on the package
10. Mark R as done
11. Open the associated internal transfer
Error: the destination location of the package is not L2 -> an
incorrect putaway rule has been applied
When we try to apply the PR on the SML "input to stock", because
this is a package with a type, we don't provide the list of the
products. Therefore, we have no idea about the product category.
This is a shame in case of a package that contains some products of
the same category. We should be able to apply the putaway rules
related to that category.
Moreover, this commit also fixes two other issues explained in [1]
and [2]. The FW of these commits have been stopped for the current
one because they didn't fix the above use case. Moreover, this commit
simplifies/clarifies the filtering and sorting of all putaway rules
[1] 03e47b165e7f6c59b41509d9229e8e2074aa3f34
[2] e0098eb281d886797a888a6f8fac474bbacb1b09
OPW-3098452
X-original-commit: c99523bc3a4a5a335f1928cf9bb53bb8483b492e
Part-of: odoo/odoo#109669
Commit 168cbe66bee7824bdf389de5c6c680342e27bc6d removes fields
with the 'groups' attribute from views when the user is not part
of the groups.
This is the case of product_uom_id in stock_scrap_form_view2,
but the field is mandatory for scrap creation,
therefore we use the unit of measure of the scrapped product
when not provided (as this is the case when uom are not checked).
Task: 2985735
Part-of: odoo/odoo#104062
Steps to reproduce:
- Create a product and complete a sales order.
- Then try to change the product type.
- The following message is shown:
"You cannot change the products type because it is already used in sales orders."
However, we can close the message and save.
Problem:
If some sales were already made, it should not be possible to change the product type.
There is a warning message on the onchange but it's not blocking.
This causes inconsistencies between the quantities and value shown in the quants and in the valuation layers.
Solution:
Raise an user error when trying to save the changes.
opw-3000886
closesodoo/odoo#105496
X-original-commit: 1b468ad100960cbd6940a24fbfaeeae4f01994de
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Suppose a product P with an available quantity equal to 1. Suppose a
user writes on an existing SML for that product and sets the reserved
quantity to 2. When writing on such a field, `StockMoveLine.write` tries
to reserve the same quantity on the quants. If it fails (which would be
the case here because there is only one P available), the reserved
quantity of the SML is reset to 0 (and so does the reserved quantity of
the quant).
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L301-L313
However, there is an issue: the incorrect reserved quantity is still in
`vals`. As a result, later on in the method, this incorrect value is
written on the SML:
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L362
This creates an inconsistency: a SML affirms that 2 x P are reserved
while the reserved quantity of the quant is 0. Moreover, when marking
the SML as done, it will lead to a "unreserve more than..." issue.
OPW-2936689
closesodoo/odoo#100858
X-original-commit: 2ea52bbcdbc2beaac916fa5f127ffc0ab2650708
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@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>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
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>
- 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>
A user should be able to scrap some products thanks to an internal
transfer.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a storable product P and update its quantity (> 1)
3. Create a planned and internal transfer T:
- From: WH/Stock
- To: Virtual Locations/YourCompany: Scrap
- With: 1 x P
4. Mark T as done
Error: T is still in draft
The `_compute_state` of a picking should not ignore the scrapped moves.
However, if we include them, we need to think about this use case: a
picking with a cancelled normal move and a done scrapped move -> its
state should be cancelled (see use case and test from [1])
[1] 429b589618e8dc2b0c0ccdec3f6eed88f1c73fc8
OPW-2841190
closesodoo/odoo#90870
X-original-commit: 1c956d49b45e9d3fec2bfa2c2020ea278ea80507
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The total ordered quantities on a delivery slip with order lines of the
same product was wrong + this PR
https://github.com/odoo/odoo/pull/83591 was incorrect, the undelivered
products should be displayed once
Steps to reproduce:
1. Install the Sales and Inventory app
2. Create and confirm a sale order with two order lines, both with the
same product
3. Go to the delivery and confirm it with all demands met
4. Print the delivery slip
5. The ordered quantity of the product is wrong, it should be equal to
the delivered quantity
Solution:
Use all empty moves in package-less products
`qty_ordered` = `qty_done` when in a package (the potential remaining
quantities will be displayed in the package-less products or in the
backorder section) or when there is no backorder (as the undelivered
products will either be added to the package-less products section or
the ordered quantity will be incremented later)
If we are not in a package and there is a backorder, adapt the ordered
quantity to remove the quantity of the packages considered before
Convert `qty_done` to the UoM of the stock move
opw-2722203
opw-2758840
opw-2782572
closesodoo/odoo#87072
X-original-commit: 332ec796ac77c8383a04a924508013c735f67d1e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
On a SML, when setting the done quantity, the onchange may change the
destination location selected by the user
To reproduce the issue:
1. In Settings:
- Enable "Storage Locations"
- (Then, ensure "Storage Categories" is disabled)
2. Inventory > Operations Types, edit "Internal Transfers":
- Enable "Show Detailed Operations"
3. Create an internal transfer IT:
- From: WH/Stock
- To: WH/Stock
4. Add a detailed operations to IT:
- Product: anyone
- To: WH/Stock/Shelf 1
- Done: 1
Error: One the field "Done" is modified, the "To" changes and becomes
"WH/Stock". This location should not change (it should be
"WH/Stock/Shelf 1")
When setting the done quantity, an onchange recomputes the destination
location of the SML. To do so, it uses a initial location and searches
among its children. Here is the issue: when "Storage Categories" is
disabled, this initial location should be the one selected by the user.
OPW-2704665
closesodoo/odoo#85151
X-original-commit: 4202e46a8313fa9f1487d372ef0cb771f769be8d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@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
We fix 2 related UoM issues:
1. Fix quant inconsistency from changing the UoM of Done
stock.move.lines
Steps to reproduce:
- Enable "Storage Locations" setting
- Create a new "Storable Product" and create a receipt for 1 unit of it
- Validate the 1 unit receieved
- Open "Detailed Operations" of the move and change the stock.move.line
UoM to dozen.
Expected result: 13 on hand
Actual result: 1 on hand
To fix this:
- prevent users from editing the UoM after the picking is
done (i.e. unless adding a new stock.move.line and not saving).
- update the write on done logic so stock.move.line UoM changes are
considering and will update the quant correctly (in case of RPC or
direct write).
2. Prevent changing UoM of Done stock.move to prevent inconsistent field
values within stock.move and confusion for users
Steps to reproduce:
- Complete a picking (incoming is easiest to see) with a new product
(i.e. 0 qty) having 1 unit done.
- Unlock picking and add a new stock.move with 1 unit done and save.
- Edit the just added stock.move's UoM from Units to Dozen.
- Check the quantity on hand / Done qty of stock.move after leaving and
returning to form.
Expected result: 13 On Hand
Actual Result: 2 On Hand and the "Done" qty in the picking is 0.0083
(i.e. 1/12 of a dozen)
To fix this:
- prevent users from editing the UoM after the picking is done (unless
adding a new stock.move and not saving)
- if a Done stock.move UoM is uodated, a UserError occurs because there
is no straightforward way to ensure the quant is updated correctly
since is handled within the move.line (i.e. has no visibility to its
move's uom change => changing only UoM and not qty done will result in
no quant update)
closesodoo/odoo#76916
X-original-commit: 72a1e7d75f0b13f23def912c8bcc758c58438b04
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
reserved_availability is expressed in move uom
forecast_availability must be in product base uom
closesodoo/odoo#75077
X-original-commit: fa9abcc1b105c07e1eaf6bdd3010abe19a056088
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>
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>
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>
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
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>
Add and improve onchange warnings when a duplicate SN is used in
following cases: inventory, picking (any type), manufacturing, scrap,
and "Update Quantity" (i.e. directly edit quants from product form).
Improvement includes:
- include location where the existing SN is
- auto-correct source location when appropriate (e.g. trying to scrap a
SN in the wrong location)
The goal of this is to prevent but not restrict duplicate SNs so users
can have some flexibility (especially if a dupe SN occurs because of an
error such as doing pick-pack-ship out of order.)
closesodoo/odoo#61287
Task: 1924758
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
This commit sets up the logic and adds the button for "Put in Pack"
action that already exists in stock.picking. Reuse/extension of logic
from stock.picking reused where possible, including extension of pack
wizard to handle products with different destination.
Note that logic to handle "Delivery Packaging" wizard when "Delivery
Methods" is active was purposely not extended to work correctly in batch
pickings due to complexity of adding in a new module just to handle
conflicting carrier_ids across pickings in the same batch. It is
expected that this use case will not occur except in case of user error.
Additionally, stock.picking implementation of 'put_in_pack' method has
been renamed to 'action_put_in_pack' to have consistent naming (and
support enterprise level code).
Part of "1. Improve Batch Pickings" specification of overall barcode
improvements task.
Task: 1884520
Enterprise PR: odoo/enterprise#12086Closes: odoo/odoo#55096
1) Create a stockable product > Add some quantities on hand
2) Edit this product > set it as a consumable or service
3) Create an inventory adjustment on all products
Error will raise "Something went wrong! You can only adjust storable products.
This occur because when switching product type the available quantity
was not cleared, so it will get in the next inventory, but only storable
products can have inventory. So the product should to have no
quantity left before switching type
opw-2300478
closesodoo/odoo#55062
X-original-commit: be17e31307070498ba9ac7dc594443730caa7404
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Let's say we have a chain of move
wh1 - intercomp transit -> intercomp transit - wh2
The second move will be reserved according to what the first move
brought since they are chained. This behavior resulted in rev[0] which
tries to work around the ir.rule limiting the access of stock.move and
stock.move.line records in multi-company environment.
This patch wasn't perfect since, if the first move brought a lot, the
second move will reserve this lot and it will result in another access
error since the lot will still have the company of the first move.
We fix this by implementing the following logic: receiving from another
company should behave the same as receiving from the supplier, no
reservation is applied. We fix this by marking the inter company transit
as `_should_bypass_reservation` and we break the move chain if the
pull/push rule create an intercompany chain.
[0] 6ff34073153767d449804669f31e26c04de0a670
closesodoo/odoo#45601
Task: 2160847
X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Create an immediate transfer for a receipt, add a move, set a quantity
done and due to rev[0], an initial demand is set, then
_autoconfirm_picking is called and action_confirm of picking calls
_action_assign if the location source bypasses the reservation. Set
again an inferior qty_done, the initial demand is also updated due to
rev[0] and somehow the system tries to write on a now unlinked move
line.
fixes
- never reserve an immediate transfer
- never update the initial demand if the move is reserved to fix the
existing databases.
- adapt _compute_state so that immediate transfer moves considered
reserved so that they're always "ready"
- adapt the test that was working on an immediate transfer picking and
setting the initial demand while it's not possible through the
interface, the user can only set the done quantity.
[0] 8303b1aclosesodoo/odoo#45317
X-original-commit: 357e0a862744f1bc23a9643a1822d2ee4a2eb7a2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, validating an unreserved move of a dozen while 12
units were reserved resulted in a quant with 0 unit as quantity and 11
units as reserved quantity.
closesodoo/odoo#45132
X-original-commit: bf7d76a7127521ba17f29bc470c3d551cc9988d5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a user unreserve a picking or a move it will
drop all the linked move lines. However it could
happens that some move line already have a done quantity
and the user won't lose this information.
This commit filters move lines in order to only drop
the move line without quantity done and remove the
reserved quantity on others.
Joint work with William Henrotin <whe@odoo.com>
task-2069646
Triet Ngo