When a picking is returned, the scheduled date stay unchanged. This date can be
in the past if the return is made at least one day after the transfer. This commit
set the return day as scheduled date
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
In case of changing the quantity on hand of two variants of the same product,
the two inventory adjustment created will have the same name (the name of the
product.template).
Show the name of variant instead.
Closes#23696
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.
Before the patch, validating a picking where one of its move do not
have any quantity done nor quantity reserved resulted in the complete
validation of the said move. This doesn't make sense and does not do
what the help in the wizard indicate (process only *reserved* quantities).
We also use this patch to clarify what the tests on this workflow is
doing (test_immediate_validate_*). We completely replace the 3 as it was
testing the `force_assign` mechanism, which methods are still present in
v11 but unused. Instead this test is now testing the failing flow this
commit is fixing.
We thus adapt the `process` method of the immediate transfer to only
process the move lines (move line = reservation). We also fix a case
where nothing is reserved and nothing is done. In this case, the
backorder wizard should not opens but instead an UserError telling the
user to either cancel or process something. The testcase for this flow
is test_immediate_validate_7.
With these changes, the test `test_04_create_picking_update_saleorderline`
was failing because one of the items in the so lines was a stockable
product without stock. So before this patch, everything was processed,
now there's a backorder wizard. We complete the patch and duplicate it
with enough products in stock, so that the backorder wizard is not
needed.
opw-815056
opw-808126
The purpose of this commit is to create a generic method in order to
log an activity on following documents or on upstream documents in order
to avoid code duplication.
In order to use it, you have to:
- create a static method in order to generate the string
for the note (it will use an arguement with the format
{'dest_object': ['orig_obejct', (new_qty, old_qty)]}
- 'DOWN' to notify following document. In this case you
have to specify a groupby/sorted method.
- 'UP' to notify upstream document. In this case you have
to specify a specific method call
'_get_upstream_documents_and_responsibles' on the object to
ride up.
Log_activity's operating mode:
destination objects = self.stream_field(passed as arguments)
'DOWN' group destination objects by document on which we want
to log the activity and a responsible to assign.
For each pair (document, responsible) generate a specific note
with only the information relative to object that belong to the current
document. Once the note is returned, it logs the activity on the
document and assign the reponsible.
'UP' instead of sort and group runs the method
'_get_upstream_documents_and_responsibles'. For example on moves
this method is called recursively on all moves orig that are not done or
cancel until it can't find a valid one at this moment it returns its picking.
Then generate the note and log the activity the same way than 'DOWN'.
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.
Usecase to reproduce:
- Create a new unit of measure "Pack of 6" of UoM Categ = units
- Create a new product: Coca cola can, sell in unit, purchase in packs
- Create a PO, buy 1 pack of this product
- Receive the pack from the delivery order
- On the picking you just received, click on return
-> If you validate the wizard by clicking on "return", you get 6 packs, so you multiply by 6 the amounts of what you send as the system changed the quantity but not the Uom
It happens because the system compute the quanity to returns in terms of quant uom but when creating the return move it copies the origin move uom.
This commit uses the quant uom on the return move and also adds the uom in the view in order to be less confusing for the end user.
opw-800566
When choosing inventory at specific date the default value
is the start time of the server instead of the current time.
When using fields.Datetime.now as default value, will set the function
as default and future object will need to evaluate the funcion each time an
object without default is created. fields.Datetime.now() will evaluate the
function once at the server start and use the retun value as default value
for future objects.
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.
The purpose of this commit is to allow future modules that need
immediate transfer and back order function on multiples picking
to do it.
This commit does not modify the behavior of single picking processing
Kind of switches the behavior for inventory and valuation report,
meaning allows the user to see the quantity at date and disallow him to
see the valuation at date.
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
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
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).
In previous versions, readonly used to prevent sending the values
of the fields to the server. However, it was not working properly
for fields which have their own sub-arch in the view, as the value
used to be sent regardless of the readonly value.
In the new views, the readonly modifier is never overlooked, which
created a bug in the stock_picking_return wizard which was not
able to return products received from a po anymore. Basically the
value of the product_id field was not sent so the create crashed.
This commit introduces a new "force_save" modifier which is used
to express that we want to save the value of the field even though
it is readonly from a user interface point of view.
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.
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>
Benjamin Stiens