In a warehouse, mostly most of the products have no lot. It stays
important however to avoid having old products in stock, certainly if
we can distinguish them by pack or location.
As now in stable, in_date is not put on the quant for non-tracked products,
databases might mix quants with and without in_date of the same product.
We should see those without in_date as the oldest.
That is why we need to be able to apply a ASC NULLS FIRST (ASC is NULLS LAST by default) for FIFO
or DESC NULLS LAST for LIFO.
In order to do that, we copied the code from the _search method of the ORM to
be able to do this special order as the orm itself is restrictive as it
supposes the order itself has no spaces.
We adapted and added some tests to check it handles the combination of NULL/NOT NULL well.
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.
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.
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.
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.
To increase or decrease the reserved or available quantity,
`stock.quant` exposes two methods: _increase_xxx_quantity and
_decrease_xxx_quantity. This could be confusing and could lead to
unexpected result when overriding one or the other.
We remove the _decrease_xxx_quantity method and rename
_increase_xxx_quantity by _update_xxx_quantity, as it supports a signed
float anyway.
Christophe Simonis