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.
The owner was not correctly passed to the move lines, and indeed it was
written as a "to do". So we do it. We correctly indent all the
move_line_ids block and add a testcase.
Before, it was possible to have a move without move line / pack
operations and the `restrict_lot_id` was used in this case. Now, every
move has move lines / pack operations and this field was unused. Let's
remove it.
Consignment worked in backend but there was no
tools in front end in order to use it.
This commit update the views and add consignment in picking
and stock move lines
In the chat, there is an indication of when a message was sent, This indication gets updated as time passes. When the last one in the conversation is updated to an indication that takes more space (e.g. from 'now' to 'a minute ago'), the text below is pushed lower (as expected) but the chatter does not scroll down. As a result, we do not see new messages, unless manually scrolling down.
(PR #17469)
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.
A quant's company_id is now related to the company_id of its location.
We make it store so that filters can work with it. We remove the default
because the location's company_id has one, and it's possible that we
introduce quants in some non-internal locations (like intercompany
transit) that do not have a company_id set.
This feature is no longer wanted. The information is available somewhere
else:
- reception_count is a duplicate implementation of incoming_qty
- delivery_count is a duplicate implementation of outgoing_qty
As this field is defined directly in payment and is displayed on
acquirer form view let us display it in tree view also directly
in payment instead of website payment.
See commits for more informations. We consider the model as almost
OK, but were are aware that we are introducing all kinds of new
bugs and we'll do our best to fix them quickly :)
lifo_price.yml:
- change the cost method to fifo, as real price does not exist
anymore
- do not check the standard price, as it is not update on the
product in fifo
- correct calls to picking
- end the test by checking the value of the out move
- note: testing the lifo removal strategy has not effect here (we
could adapt the test to set lot on receipt and check that the
right lot was taken, but we didn't to that here)
* If the user tries to decrease the quantity of a sale order line below
the received quantity, we raise a warning telling him to create a
return first.
* As we do not propagate the decrase to the already created pickings, we
post a message in the chatter of these pickings informing the pickers
of the change.
The new implementation of stock moves the cost of products from quants to
moves. So we have implemented the FIFO and average cost method based on
those moves instead of using quants.
- When average price is choosed, a field average_price is set on the
product.
- The tests have been completed with an example of how fifo work with
negative stock.
As the use of real price method is really rare, because of the rigor
required on traceability for such method, we removed this functionnality.
- The tests purchase/test/fifo_price.yml have been adapted to use the
FIFO costing method instead of real price.
The old report stock history doesn't exist anymore, and is replaced by
the move view that contains all the cost information.
The methods `get_price_unit` have been moved from the stock to
stock_account.
The methods `_set_default_price_moves` and
`set_default_price_unit_from_product` have been removed from stock.
Explaination of FIFO and average:
- In action_done for an out move in average and fifo, the price_unit and
stock_value are updated.
- For FIFO, it will use the qty_remaining on the in moves to check from
which in moves to take the stock values for the out.
- In case of negative stock in FIFO, it puts also qty_remaining on OUTs.
- In the case of average, it will take the cumulated value of the last
move and divide it by the quantity in stock.
This commit is pretty much a 'work in progress':
- Edit 'done' moves when the costing method is FIFO doesn't trigger the
replay the FIFO stack.
- The landed_costs feature doesn't work.
This commit adapt purchase to be able to edit purchase line ordered quantity
and propagate it to the related picking after the request for quotation
validation.
These are the supported use case
- When you increase the quantity on a purchase line, an extra move (and
an extra picking if they are all done or canceled) is created with the
difference between old and new value and the push rules are applied on
it.
- When you decrease the quantity of a purchase line, different behaviors
can occurs:
* If you plan to decrese the ordered quantity under the received
quantity, you get a user error saying tht you have to make some
return before.
* Else the moves not done or cancelled are decreased by starting with
move having no procurement_id. The decrease is not propagated
through push or pull rules.
* If you decreased the quantity under the invoiced quantity, a next
activity is created to remind you to do a refund.
We adapted the views to the new stock model, and differenciate two
different views:
- The first one is more adapted for simple operations, or when no
suggestion of location, lot, pack is needed. We have a line with
the initial demand of each product and you can complete the lot
numer, location, etc in the detailed window of a move.
- The second one is more adapted for pick and barcode operations, all
each line is fully detailed with the system reservation, you can see
the lot, location, etc you must scan in the list view.
You can choose the view you want to use in the picking type settings by
check the box 'Show Operations'
The big change is that we have now a many2many between the move and a
one2many between a move and its pack.operation (note: this model is
renamed as stock.move.line in a further commit).
Due to these changes, `action_done` had to be rewritten intierely, as it
depended and stock.pack.operation.lot and stock.move.operation.link,
that are now removed. This method was laregly inspired by the one in the
mrp module, and a further commit will make MRP uses all the core of
stock.
Due to the previous commit that refactored the stock.quant
implementation, the new concept is that the `product_qty` that will
always be in the uom of the quant (`product_qty` is a computed field in
the same style as the one of stock.move).
This commit also implements the logic that a manager is able to edit
done stock.pack.operation.
The stock.move has now a "partially_available" state (it was previously
a flag). The "split_from" field is removed now that we have a many2many
between moves (a sibling move is always a move that was splitted, or
with the backorder_id field).
The done quantity of a stock move is computed across the done quantity
of the move lines. There is an inverse method that allows user to fill
the done quantity directly on a stock move.
The reserve quantity of stock move is computed accross the
`product_qty` of the linked pack operations.
`do_unreserve` will simply unlink the associated pack operation.
Unlinking a pack operation will unreserve.
`force_assign` will mark the move as available, in order to allow the
user to create pack operations (none are created because nothing was
reserved).
`action_assign` is rewritten and splitted in two parts: if the move has
a parent (mto) or not (mts). In the mto, we'll check the available move
lines and only reserve accordingly. In the mts, we'll reserve directly
on the quants.
`action_cancel` has changd a lot: in case of a delivery, the first step
does not anymore propagate cancellation to following moves and SO. As a
result it does not propagate in the other side in case of MTO or production.
It does not delete them if we delete the related sale order for example. In
order to correct this next activities will be added in the future. Technically
action cancel on move is based on procurment rule, this commit will set
the propagate field to false on the rule if the picking_type is 'pick'
or if we are in one step delivery.
We use this commit to reimplement `action_assign` (wiped by the new
quant implentation). A move is reserved if its move lines exist, so we
introduce a one2many between stock.move and stock.pack.operation (note:
a further commit renamed this model into stock.move.line)
We use this commit to implement `action_done` (wiped by the removal of the
models making the link between stock.move and stock.pack.operations). We
can use the one2many to the pack operations.
blabla manymany au lieu de one2many
blabla mto mts
Remove get_ancestors, as orig_ids will be used instead
validation
when we are creating some packe operation with lot name, the
pack_operation are unlink and a new picking is craeted.
This is caused the function _create_lot_for_picking that unlink pack
operation having no quantity reserved instead of ones having no quantity
done.
To fix this we changed product_qty to qty_done and move the code from
action_done of picking to action_done of move
fixup! [IMP] Merge_moves functionality + many2many procurement and original moves instead of one2many
fixup! [REF] stock: basics of new model and stock.move reservation
edit reserved move line
This is the 1st commit message:
[REM] stock: stock.pack.operation.lot, stock.move.operation.link
These models will become useless once a one2many will be made between
stock.move and stock.pack.operation.
The `action_done` method on stock move has been wiped, as it depended
completely on the removed models.
Joint work with Josse Colpaert <jco@odoo.com>, amoyaux <arm@odoo.com>
and Pierre Masereel <pim@odoo.com>
The main idea of this new implementation is that stock.quant is now a
cache of the quantity per location/lot/pack/owner key. We removed every
identity per record, such as `history_ids` or `inventory_value` so that
we can now avoid the linear creation of stock.quant records and are able
to work with only one record per key.
The algorithms to retrieve the quantity per key are made to work with
multiple records, this way we can implement strategies to workaround
postgres locks if concurrent transactions try to work on the same quant
row.
Quants will not be linked to moves anymore, this is in order to be able
to edit stock moves more easily/freely. We removed the links with this
commit and wipe out the `action_assign` on stock move. This will be
implemented in a followup commit, once the relations between stock.move,
stock.pack.operation and stock.quant are clarified.
This commit seems to have unecessary diff, but it was done in order to
run tests on the new implementation.
We adapt the views by removing the fields not present anymore in the
model. This include the complete removal of the inventory valuation
view, as the implementation of stock valuation will be refactored and
moved on stock.move in a following revision.
We wipe out `action_cancel`, `recalculate_move_state`,
`move_quants_by_lot_v10` and `quants_unreserve`.
* `get_removal_strategy` moved from `stock.move` to `stock.quant`
Stock quant model:
* qty renamed to quantity
* history_ids: because the quants are not moved
* inventory_value: implementation moved to stock.move
* packaging_type_id: doesn't seem to be used (in filters?)
* propagated_from_id: because we do not split forced quants
* reservation_id: because the reservation are not linked to
the stock.move.line
We remove the `lot_ids` computed field, as it depended on the link
between stock moves and quants and could be replaced by a related
to the move lines once the new relation between stock.move,
stock.pack.operation and stock.quant is clarified in a further commit.
Furthermore, the field was not displayed to the user.
Simon Lejeune