Error due to other module (e.g. purchase_stock, mrp) that will
define their own rules in order to merge or not moves together.
Usecase:
- Install purchase_stock
- Create a product MTO + buy with a vendor
- Create a SO of 1 unit
- On the PO receive 2 units
- On the delivery deliver 2 units
It will create an empty delivery and put the entire move in
a back order.
First issue the extra move is created as a MTO if it's copied from an
MTO move. So il will trigger all the pull rule. We won't it because it's
an extra quantity and the rules should be only trigger by the original
document (SO/MO).
Also an extra move in a picking do the hypothesis that the original move and
the extra move will always be merged together. But in the previous
usecase, the module purchase add the condition that 'created_purchase_line_id'
and 'purchase_line_id' should be the same in order to merge move.
'created_purchase_line_id' is also copy=False, so the move and the
extra move will not be merged. create_extra_move only returns the extra
move and _action_done only process the moves returned by _create_extra_move.
It result by an original move not merged and not processed by _action_done,
it will be automaticaly set in a back order and the extra move is
processed.
In order to fix it, check if the move and the original move will be
merged. If not, returns both moves.
opw-2008113
Close#34005closesodoo/odoo#34411
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Change the domain to not include `.id` and to use `in` to prevent subqueries
to be ran by the ORM for each attribute value.
On the filter, directly use `attribute_value_ids` instead of the computed field
`product_template_attribute_value_ids` that leads to the same result, to prevent
unnecessary compute of that non-stored field.
Cache the result of the method. The cache is invalidated when the configuration
of attributes and values change.
We can remove all cache invalidation from the tests since it is done at the
appropriate times in the business code now.
opw-1923999
task-1922055
PR: #30274
`_action_done` could unlink a quant. This happens when moving a product from a
location to another one and makes null the quantity of this product in one of
theses locations. In this case, we unlink the quant because it is now useless
and could be confusing on reports based on quants.
The unwanted side effect is that unlinking a record will invalidate the cache. In
some pathologic cases, like making an inventory adjustment of 600 products
and reseting their quantity back to 0, the time of the operation is around 15
minutes. With this patch that tries to work carefully with the cache invalidation,
the same operations takes around 15 secondes.
This commit do not unlink quant anymore, instead it use a 'garbage
collector' on quants without quantity. The garbage collector is trigger
on the scheduler and when the user open the inventory view.
The default resupply feature can be configured by going on the route and activating
it for the warehouse. This field is therefore useless and this commit remove it.
The field 'resupply warehouses' is reworded an hidden when there is only one active warehouse
PR:22085
TASK:38933
- Create a PO with 5 units of A and 10 units of B
- Receive the products
- Return the picking, but return 12 units of A and 10 units of B
The first picking (done state) will contain:
- 7 units of A, 0 qty done => it is an extra move
- 10 units of B, 10 qty done
But another picking (not done) is created, with
- 5 units of A, 12 qty done
The core of the issue is that the `origin_returned_move_id` is not
copied on the extra move. Therefore, it is not merged by `_merge_moves`
since the latter field is in the list of
`_prepare_merge_moves_distinct_fields`.
opw-1882959
Usability improvement:
- Common view for push and pull rules
- Add an help text in order to describe the rule
- Rules menu
- Warehouse checked by default on route created by a warehouse
- Lower the MTO route sequence in order to take it first.
- Tooltip cleaning
Technical improvement:
The purpose of this task was also to merge stock.location.path(push rule) and
procrement.rule. Those two model were design to execute the same task
but in a different direction. Thus it contains duplicate code.
Task ID 1852969.
The method 'action_done' on inventory adjustment became private and the
action launched from the view is now 'action_validate', so we adapt
those tests to use the new function.
TASK-30921
We added a model to work easily with packages, using the quant packages
was not a good solution to move entire package and plan package moves,
because we always had to give the picking in context, and create some
move lines, so it was only possible when state was assigned (when move
lines exists)
So we created a model package level, linked to picking, move and move
lines allowing to easily plan package transfer and put in pack.
Depending on the situation, it is possible to have move with origines
and destinations that have a loop.
A simple example is a return of a return, the origin and destination of
the return of a return is the return itself.
opw-1845444
closes#24787
This commit remove force_assign method in every tests of point_of_sale, purchase, sale_mrp,
sale_stock, stock and stock_account . This method is not longer used since V11.
This commit is related to task ID 59417
Usecase to reproduce:
- Create a product A with a qty on hand 5.5
- Create a delivery order with an initial demand of 5.5
- Validate it with a qty equals to 5.95
The initial demand is updated to 5.951 then reduced to 5.95
and a backorder is created with an initial demand of 0.001.
That should not happen since I process extra quantities.
It python 5.95 - 5.5 = 0.4500000000000002 and the float_compare
use a round UP method thus it returns 0.451 and the following
flow is based on a wrong value.
In this case a float compare is used before the float round, so an
HALF-UP rounding should be okay since a very small quantity diff should
be filter by the compare.
Fixes#24401
This wizard allows the stock users to replenish a product using the
routes applied to this product. A specific route can also be applied
to bypass the default route.
This replaces the "request procurement" wizard from v10, lost during the
stock refactoing.
Task ID: 47938
related to #22041
Use case to reproduce:
- Create a picking containing 2 moves that have a quantity_done greater than reserved quantity
- Validate the picking with or without backorder
Traceback due to a record that do not exist anymore.
It happens due to 2 functionality that have a wrong behavior when used together:
- merge_move function that will try to merge moves with same characteristics inside a same picking.
- action_done functionality that will create an extra move if the quantity done for a move is greater
than reserved quantity. (the extra move is used in order to propagate changes)
With our usecase:
- MOVE A, reserved_qty: 10, qty_done: 20
- MOVE B, reserved_qty: 10, qty_done: 15
action_done on move A will create a new move thus we will have
- MOVE A, reserved_qty: 10, qty_done: 20
- A bis, reserved_qty: 10, qty_done: 0
- MOVE B, reserved_qty: 10, qty_done: 15
then merge move will not only merge move A and A bis but will also merge B
which result with inconsenstencies and traceback since system will try to
process move B after A
- MOVE A,A',B reserved_qty:30, qty_done:35 (the 5 extra qty is not propagated)
This commit adds a kwarg in action_confirm that is propagated to merge_move
this kwargs is a record set taht will limit the moves that can be used for the merge
in order to merge extra move in original move
opw-1825264
Use case to reproduce:
- Create a sale order with a stockable product.
- Confirm the sale order.
- Validate the pick.
- Validate the pack.
- Cancel the OUT.
- Run the stock scheduler.
-> Picking are created from pick and ship.
The scheduler should not try to create missing pickings
for broken move's chain. Since v11, it's not possible to create
a partial mto chain that means if a chain is broken it's due to
a manual action from a user and thus we won't automatically
repair what he cancelled on purpose. That's why we won't create
a new move out in this case.
It also don't make sense to recreate a new mto chain from a
cancelled picking. Thus we had a condition in domain in order to
only take moves that make sense.
Based on preliminary work from Florent de Labarre <florent.mirieu@gmail.com>
Closes#23441#23458
OPW-1820226
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
The user is able to specify a route on a SO line. The pull rules are
correctly used however the push rules are not apply.
This patch adds a check in order to apply possible push rules associated
to the route specified on the SO lines.
Closes#22141
Previously, it was only possible to make a return in
- the location the move was coming
- a return location that is child of the parent_location, actually
meaning a return location in the warehouse
This commit now allows making return in all return location, even one
located in another warehouses.
Rev[1] fixed a bug where the order inside of the recordset could trigger
side effects by merging move when creating the extra moves. However,
after the patch, `moves_todo` contained moves that should be backordered
(with no quantity done). This commit fixes this oversight.
[1] b95cabef0bFixes#22440
When confirming a quotation for an MTO product, the state of the
delivery order goes from draft to waiting another operation to waiting
while it should stays in waiting another operation.
If procurement_jit is enabled, confirming a sale order line will
unreserve and rereserve the pickings associated (see
`action_launch_procurement_rule` override). Unreserving a picking will
always set its state to "confirmed", which is wrong if it should be in
"waiting another operation". Not writing on state (which is a computed
field) and let the depends call _compute_state fixes the issue.
The unreserve/rereserve thing is probably useless and is a remain of the
previous stock implementation where it was not possible to complete the
reservation of a move without wiping all its current reservation.
Another commit will improve this part of the code.
opw-801588
Use case to reproduce:
- Go for a delivery order and use show detailed operations mode
- Have something reserved on a picking
- Manually delete the stock.move.line
-> The move state is not adapted to the new state of the stock move lines
It happens because the move state is not computed not
update on the move line unlink method.
This commit use the existing move function in order
to compute the state and add a test.
A part of test_stock_flow_74 is updated. Since procurement
refactoring make a move mto and confirm it will not work
since purchase or mrp are not install (Usererror). Also do an unreserve
on a draft move is not a real use case and should not pass
it in waiting since moves orig are never created.
We chose to erase the partner_id and ref field on a picking when its
content may refer to multile records. Note that the partner_id field was
already hidden in the view of internal picking.
When we have two moves of the same product and procurement method
different on both, we don't want to merge them, because if a mto and a
mts move are merged together, it is possible to wait for an incoming
that will nerver come as a part the merged move should be taken from
stock
When processing picking containing moves without
quantity done and without initial demand. These moves
were moving automatically to a new backorder.
It was also possible to validate picking without
quantity done for all moves.
This commit raise an error if the user try to valiate
a picking with all moves without quantity done and without
initial demand. Or cancel all these moves if the picking
is validate with correct moves.
The rationale for the need of a merge move mechanism is that, with the new default view,
having multiple stock move for the same products is confusing. The idea is that if a move
is confirmed in a picking already having a move with the same characteristics, we update
the existing move and unlink the new one. That’s why it’s done at the end of `_action_confirm`.
In some cases, merging moves is unwanted (backordered moves for examples). Therefore, we chose
to add a kwarg to `_action_confirm` in order do control the mechanism.
Suppose you have a product tracked by serial number. In your inventory,
you have two quants: -1 for serial1, +1 for serial2.
If you create a move for 1 product and try to run `action_assign`, it
didn't work before this patch because stock.move's
`_update_reserved_quantity` is guarded by a call to
an unstricted `_get_available_quantity` (unstricted meaning considering
all quants regardless of their lot_id/package_id/owner_id). This call
resulted in an available quantity of 0, thus the stock move could not be
reserved
To fix this issue, we patched `_get_available_quantity` so that it
rightly considers products of different lot_id as different products,
i.e. it returns an available quantity of +1 in the initial scenario. Of
course, we consider all quants of the same lot_id, i.e. if you have -1
for serial1 and +1 for serial2, the available quantity amounts to 0.
In another scenario, let's say we have only -1 serial1 in stock, if we
run `_get_available_quantity`, the method should return 0: nothing is
reservable. We continue this reasonment by returning 0 everytime the
available quantity is negative, tracked or not. This is probably what a
method named `_get_available_quantity` should have done since the
beginning.
There's only a single case where we need to know the quantity even if
it's negative: it's just after we move a quant to its destination
location. If this quant was tracked and resulted in a negative quant
(i.e. we moved something we didn't have), we try to compensate with an
untracked quant. In this special case, we do not want to ignore the
negative quants when calling `_get_available_quantity`. That's why we
introduce a new argument to this method. We could have added a new method
`_get_quantity` for clarity sake.
The function that checks if we need a back oder or not compares
the initial demand and the quantity processed on the picking.
When unit of measure are activated the initial demand (product_qty)
uses the uom of the product. However the quantity processed on the move
(quantity_done) uses the uom of the move.
This commit uses product_uom_qty instead of product_qty. Product_uom_qty
represents the initial demand transformed with the uom of the move.
It also add a small test with a back order that ensure the quantities
are correct.
It also repairs the test stock flow where in some case immediate transfer
return the back order wizard instead of processing the move. In these cases
we catch the back order wizard and run it.
Use case to reproduce the bug:
- Set multi location in settings
- Set warehouse's deliery method as pick/pack/ship
- Deliver a product to customer
- Process a return from customer to output.
- Create a return from output to pack ->
Unable to reserver product.
It happens because return moves where not linked together but have
the picking that created the return as origin.
Thus action_assign does not detect the return moves and can't
guess the real quantity available.
This commit add a behavior that will create links between
return move. It can be guess from parent move(the picking's move from which
the return is created) and its move dest/orig that have already
created other return. It also correct action assign because
the group by could retourn same line with return moves.
It add a test that check returns and links between them.
Arnold Moyaux