- 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
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
Stock moves show a detailed operations icon if the tracking, locations, or
consignment allow to be configured.
However it did so on a per move basis, only displaying it if the considered move
has some of these features.
This fix makes it that the "detailed operations" icon is always displayed if at
least one group of group_tracking_lot, group_stock_multi_locations, or
group_tracking_owner is active, or the move is tracked,
unless the move picking type already does show detailed operations.
opw 1893106closesodoo/odoo#28072
Usecase to reproduce:
- Archive a stockable product with quantity on hand
- Start an inventory with all products.
-> Archived product is displayed
It happens because the search is an SQL request that is build
and it thus does not benefits from the automatic search on active
objects.
This commit add an active search on quant for inventory lines.
Fixes#27302closesodoo/odoo#27384
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Steps to reproduce:
- Create a stockable product P with 2 quantity on hand
- Choose a delivery order in state 'done', unlock it and add a line with P
- Try to set 2 as done quantity and confirm the wizard
Bug:
A ZeroDivisionError(float division by zero) was raised.
opw:1886735
closesodoo/odoo#27547
Steps to reproduce the bug:
- Create a picking
- Create a line with product "A"
- Validate Picking
- Duplicate Picking
- Add a new line for product "A"
- Validate Picking
Bug:
A missing error was raised.
PS: The function _action_done on model 'stock.move' calls the function _action_confirm
where some stock.move records could be unlinked by function _merge_moves
But the recordset was not updated afetwards.
opw:1885053
closesodoo/odoo#27209
- Set the Outgoing shipping of your warehouse to pick + pack + ship
- Create a SO with a stockable product and validate it
- Set the qty done to 1 in the ship and validate it
- Cancel the pack
Bug:
It was impossible to cancel the pick.
opw:1887098
closesodoo/odoo#27193
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Purpose: improve understanding of partner and product models as well as their
daily use. This is done by improving tooltips and labels of some fields
according to business logic.
This commit is related to task ID 1880696 and closes PR #27133 .
Thanks to @xmo-odoo for its in-depth review.
The field barcode on picking type was introduced in stock_barcode module
(enterprise). We move it to the stock module to be a standard field like
the one on stock_location.
Task: 1872345
Purpose : during a transfer, if some move lines have different
destination locations and the user click on 'put in pack' button, an
warning is triggered. This message, saying : 'You cannot put in the same
pack move lines having different destination location', is replaced by a
wizard allowing the user to choose a unique destination location. This
location will be set as location_dest_id on all transfer's stock move
lines. After that, the wizard calls again the _put_in_pack() method
where all the logic remains the same.
Task : 1872345
`_action_done` could unlink a quant. This happens when moving a product from a
location to another one and makes null the quantity of this product in one of
theses locations. In this case, we unlink the quant because it is now useless
and could be confusing on reports based on quants.
The unwanted side effect is that unlinking a record will invalidate the cache. In
some pathologic cases, like making an inventory adjustment of 600 products
and reseting their quantity back to 0, the time of the operation is around 15
minutes. With this patch that tries to work carefully with the cache invalidation,
the same operations takes around 15 secondes.
This commit do not unlink quant anymore, instead it use a 'garbage
collector' on quants without quantity. The garbage collector is trigger
on the scheduler and when the user open the inventory view.
Defined as this, the label of the selection field were translated during code
import, when building the python model, not when a user access the field values
as it should (and is already the case thanks to the ORM).
Trying to translate a string when no user-context is available is not only
useless but may cause bug on services with multiple databases (e.g. a SaaS).
In a multi-worker environment, when the code is imported, the _ method will use
multiple scenarios to detect the language and get a cursor.
As we have no available cursor in the frame (method _get_cr from GettextAlias),
the fallback is made on the cursor of the request.
In a multi-worker environment, this could be a cursor linked to a database in
another language than English.
In such scenario, the selections would be translated in the language of the
other database instead of displaying it in English
opw-1881956
Christophe Simonis