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
It is not possible to work directly on the operation tab
when the detailed operation tab is available. On detailed
operations page it is now impossible to add a new move line
when the picking is done and locked.
This commit add some condition in the view and add a check
in the move line creation. If the move line has a picking but
no move then we create it (mark as done directly)
The code made the assumption that everything brought by in chained move
is available on the quants. This is not always true, for example when x
products are brought by a move in the chain, the user can make an
inventory adjustment that reduce the quantity available. Thus, we
implement a fallback in case the quantity brought by is not available:
do not reserve more than what's really available. If the user make
available some products with the same characteristics (lot/owner/pack)
in the location, they will be used by a new call to _action_assign.
Indeed, the reserved quants are not discernable. This is not an issue in
reality, as the user cannot discern the products himself if they share
the same characteristics.
When undoing the original move line, make sure to handle the packages
correctly (in the destination location, undo the result package, not the
source one.
Previously editing a done move line only update
the quants to the right location. However the stock.scrap
related object has not its qty updated.
This commit modify the write of stock move line in order
to also modify the stock scrap object to the correct quantity
This implements a warning when the user tries to do any of the
following operations on a product that is not in stock:
- Scrapping
- Unbuilding
- Repairing
The warning displays the current stock of the product in question per
location which can be helpful in case the user selected the wrong
location.
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.
When running action_assign on a mts move bypassing the reservation,
we always created a new stock move line with the quantity of the move.
This proved to be too naive when running recheck availability.
Exemple: Let’s say I have a reserved move of quantity 5.
If I edit the initial demand to 7 and click on recheck availability,
I end up with a move line of 5 and a move line of 7. We adadapt the
code in a similar way that what’s done in _update_reserved_quantity,
by looking for a candidate move line and only increasing the reserved
quantity by what still needs to be reserved.
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.
When we validate stock move having move lines with quanity done equal to
'0', these move lines are unreserved and in MRP, it creates move lines
with product_qty = 0 and qty_done = 0 which is not wanted
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
When the picking type doesn't have use_create_lots or
use_existing_lots the products should end up in one
stock.move.line. The user will then be able to validate the picking
without specifying serial/lot numbers.
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.
This method is used to set `qty_available`, `virtual_available`,
`incoming_qty` and `outgoing_qty`.
We change the depends because only looking on stock.move is enough (all
changes on quants are made through stock moves, and we de not support to
edit directly quants anyway).
This method will call `_get_domain_locations` and we make sure that,
when the `company_owned` key is present in the context, we also return
domains to find products that are in a location that belongs to the
current user's company. This is done in order to include transit
location.
Also, remove the comment from tde. As these fields are displayed in
view, only using the context could alter the behavior.
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.
When validating a stock picking there were 2 different cases:
(1) If all qty are equal to 0 it will display a wizard asking
if the user want to set the quantity done to the reserved quantity
for all moves. If the user accept it will automatically perform the
moves after setting the quantity done.
(2) If the user set a quantity on a move, it will check if there is
a need for a back order. If yes it will display a wizard asking if
a back order is needed or not.
However the check if a back order was needed or not was never perform
in case 1. If the quantity reserved was lower than the initial demand
a back order was automatically created.
This commit add the step 2 in the procedure of step 1 (after setting the
quantity done).
The quantity reserved for move was never modified once the move
is done. It is a nonsense to have a reserved quantity for a done
move.
This commit add a constraint that ensure the quantity of
move line to be 0 if it is in state done. Also it add a write
on move_line's 'action_done' function that set the reserved quantity
to 0 for all move line processed.
It does not introduce any change on the stock move itself since the
reserved quantity is the sum of all its move lines's reserved quantity.
The purpose of this is to help stock manager in their quants analysis.
An overview of quants can be accessed via inventory menu and for specific
lot/SN via the locate button.
This commit add quants in every location (only internal location previously)
The purpose is to introduce a double entry for quant (add quants to a destination
location will always remove quant from a source location).
Quants in customers/suppliers location are shared between all customers/suppliers.
In order to know the amount of product that come from a specific customer/supplier
the tracability report should be used.
A bug happens in stock move's action_assign method. It tries to get
the quantity done and the reserved quantity from the parent move and
sibling move in order to guess the available quantty.
With uom activatred, the quantity done is not always the same than the quant
quantity and the quantity done on stock move/stock move lines has to be
converted in order to know the real quantity available/
This commit change the quantity done in action assign to the
associate product uom.
Set the `in_date` field to now when creating a tracked quant.
Set the correct `in_date` field when moving a quant (this is done by
adding a kw argument to `_update_available_quantity` and adapting the
code that moves quant in stock.move.line).
If quants from the same lot go together in the same location, we merge
them and keep the older date (as the user will have no way to tell the
difference anyway).
We add multiple test cases:
- `in_date` are only set on tracked quants
- FIFO and LIFO are correctly applied
- keep the oldest `in_date` when merging quants
- editing a done move line or creating one in a done picking is
correctly working
Joint work with sle-odoo.
If we have multiple quants returned when we want to decrease the
reservation of a move line, the min function will always return the
quantity passed in argument because 'reserved_quantity' is always a
positive number and quantity a negative one. This can lead to negative
reserved quantity on a quant, if the quantity to reserve on the first
quant is lower than the absolute value of the quantity to decrease.
To fix this, we correctly separate the behaviors for decrease and
increase.
We add a test that show the, now fixed, bug.
When we decrease the reserved quantity, the argument 'strict' must be
set to 'True', else we might unreserve quants of another move line.
This behavior has been lost in rev: https://github.com/odoo/odoo/commit/9bb696e13abcbf95c9552fab60b1dfb997afaa59
We introduce a test to show where an issue happened without this
patch: have tracked and untracked quants for the same product in stock,
reserve them and edit the untracked move line in order to set a lot to
it. The first step will be to unreserve the move line without lot, and
if we do not pass a Strict kw, stock.quant's `_gather` will return
quants with lot and unreserve on them. Everything is now inconsistent
and lead to issues upon validation.
Before this commit, `action_done` on stock.move.line was intended to
receive the recordset of the move lines of a single move where the move
lines having a null `qty_done` were already unlinked.
This part of code was in stock.picking's `button_validate` and not
copied in mrp, and weird things happened when mrp tried to run
`action_done` on a stock.move.line with a `qty_done` of 0.
We move this check directly in `action_done`, as well as the check on
the picking type that was done in stock.move's `action_done`.
We also adapts rev[0] that was not working anymore since the new stock,
and add some tests.
[0] e79eaecc46
When a picking is available, any added stock move should directly be in
the available state. This is done thanks to a key in context put in the
one2many (stock.move) field on the picking view and an override of
stock.move's default_get. Sadly, an extension of the picking view in
stock_account redefined the context attributes, and the new context did
not have the special key we need. As all the context keys present in
stock_account are present in stock, we remove the extension. And we add
a simple test in stock.
When we validate a SO with an MTO product, then an RFQ and a delivery
picking are created. The status of the delivery picking is in state
'confirmed', but should be 'waiting' as the delivery waits for a
specific delivery input.
The problem is caused by the unreserve method, which is called in the
'procurement_jit' module. This method only checks that a move has
ancestors to determine if the move should be in waiting or in confirmed,
which is not the case for our delivery move because the RFQ has not been
validated yet so there is not ancestors yet.
To fix this issue, we check the 'procure_method' of the move, and if it
is in 'make_to_order' we put it in 'waiting' instead of 'confirmed'.
We also fixed the function recalculate_move_state that could cause the
same problem.
When updating the quantity on hand in a location without quant but
where one of its sublocations has onee, it will increase the available
quantity in the sub location instead of the defined location.
This happens because _gather method in quant search on child_of location
in any case.
This commit change the domain by using '=' on the locations if `strict` is
passed as True in _gather, or 'child_of' if it is set as False. It also
removes the strict argument on _update_avaible_quantity since it does
not make sense to change the quantity on an undefined quant. And it was
never used in our code for good reasons.
A previous revision[0] forbid to scrap consumables. The rationale at the
time was that, since consumables do not have quant, scrapping them does
not make sense. It appears that people use this feature on consumable
for traceability reason, so we bring back the old behavior.
A slight change was done in stock_scrap.py: if the product is a
consumable, do not raise the error if the quantity to scrap is not
available in stock for obvious reasons.
Also, a leftover todo in the code indicate that we should unreserve the
any move having reserved the scrapped product. This is actually already
done, since this mechanism is in the move line `action_done` and a scrap
uses a classical stock move and stock move lines.
We introduce some test to prove that it is possible to scrap a stockable
product and the quant are impacted, to scrap a consumable product and
the stock is not impacted and to scrap something that was reseved by a
move and that the move changes its state.
[0] 86f08c091e
When creating a new line in a picking, the initial demand should be 0.
When editing a move line and changning the product, the initial demand
should not be reset to 1.
The rationale is that when creating a picking by hand, most users do
want to skip the reservationm and, by forcing the initial demand at 1,
we force the user to enter to encode two times what he's doing.
Simon Lejeune