- Create a SO with a stockable product, validate
- On the corresponding picking, change the partner
- Print the 'Picking Operations' or 'Delivery Slip'
The partner printed is the partner of the SO, not of the picking.
This was reported many times in the past, and is quite confusing. It
happens because the partner on the `stock.move` remains the partner set
on the SO.
We shouldn't change the reports, nor automatically propagate the change
since it might cause issues, e.g. in case on dropshipping or manual
creation of the picking.
Therefore, we add an action which allows to set the partner on the stock
move manually.
opw-1917851
closesodoo/odoo#29939
The commit a35df8d371 changes the odoo object
of "rules" from stock.location.path to stock.rule. The field on the first
object to store the destination location was location_dest_id but is location_id
in the second one.
This commit fix the variable name that refers to the destination location
opw : 1919655
closesodoo/odoo#29755
Usecase to reproduce:
- Set manufacture step to 2 or 3 steps
- Create a MO
- Go on the PC picking and validate some quantities w/h BO
Traceback because there is no documents to log the activity.
It happens because the function used in groupby and sorted
(in the method _log_less_quantities_than_expected) expect a picking.
The purpose of _log_less_quantities_than_expected is to generate
an activity on the next picking in order to notify that some quantities
will be missing due to the cancelation of the back order. In order
to find the following picking it uses the destination moves from the
current's picking moves.
Picking w/h BO Next Picking (activity to post)
| |
moves -----------> destination moves
However in the case of 'pick components' picking type(PC) the destination
moves are linked to a manufacturing order and not a picking. So it
_log_activity_get_documents return an empty parent since picking_id is
False.
In order to fix it, _log_activity_get_documents only add the tuple
(object where the activity should be log, responsible for the activity)
if the object is not False. It also add a hook in order to add
(mo_id, repsonsible) during _log_less_quantities_than_expected on top
of (picking_id, repsonsible) in order to log activity on MO directly
linked to PC.
This commit also add a missing precision_rounding in backorder
confirmation
opw-1908753
closesodoo/odoo#29385
Before this commit, we are getting error that product_uom must be
matched because when we're adding line to inventory after updating the
quantity, product_uom changes to Units.
After this commit, error will not be generated as the default value of
product_uom_id is removed.
Fixes#29305closesodoo/odoo#29371
Steps to reproduce the bug:
- Configure to use UoM
- Make an inventory adjustment for all product
- Select one product one the inventory line, and select the UoM
Bug:
All the UoMs were selectable but only the uoms in the same category of
the product are allowed.
opw:1911941
closesodoo/odoo#29238
Once we log an exception via next activity in a production, we search moves that have been updated uphill to write the useful information about the change. The issue is by default, the key 'move_orig_id' is searched while some moves could be linked with 'created_purchase_line_id' key.
This commit avoid mapping 'move_orig_id' on empty recordset and so avoid a traceback.
opw:1911399
closesodoo/odoo#29087
For a SO of 300 lines, when confirmed, it takes 195s to process stock
moves for the SO, which is an insane amount of time for any kind of
process in Odoo.
This happens because stock.move is a heavy model with lots of fields,
prefetching all these fields at once can hinder performance when
processing a lot of stock.moves.
To reduce the processing time, the prefetching is disabled in the
specific scenario of processing stock moves and pickings on SO
confirmation.
This patch increases the performance of SO validation (with stock
installed) by ~30%.
Pre-patch: 195s (300 SOL)
Post-patch: 135s (300 SOL)
closesodoo/odoo#28835
This field is a dependency of some computed fields, and has to be searched on
for triggering recomputations. Without the index, the creation of stock moves
becomes slower as the table grows.
closesodoo/odoo#28757
The field sale_id on model stock.picking is not defined in stock module.
So the rule was wrong when sale_stock was uninstalled.
opw:1912564
closesodoo/odoo#29145
commit c6b0d36622 introduced a wrong
domain. The readonly should be added if the show_operations is false
OR state is done AND is_locked is true.
close#28595
1. Product A - on stock 5 pcs.
2. SO - 7 pcs. of A
3. Generated picking has reserved 5 pcs.
4. Increase stock to 7 pcs. (Update qty on Hand)
5. Run procurement scheduler
6. Picking still has reserved 5 pcs.
The scheduler should take into account the moves partially available.
Fixes#27874
opw-1895622
closesodoo/odoo#28136
Usecase to reproduce:
- 6 units in stock
- reserve 3 units on a move
- reserve 3 units on another move
- validate a third move with 1 unit
It raise the error could not reserve more than you have in stock.
It happens because when free reservation stole reservation from
an exisiting move with too much quantity available, it continues the
loop instead of stopping.
This commit stop the loop once we have enough quantity taken.
opw-1895578
closesodoo/odoo#27935
Typically if you use an onchange method to retrieve values on the server
and convert them to write it will also try to write empty values like
[(6, 0, [])] and this will crash as it has also the length of 3 but no
dictionary but a list
closesodoo/odoo#27937
Martin Trigaux