When scrapping received products, the state of the move will be switched back
from 'assigned' to 'waiting' in method 'recalculate_move_state'. These moves
must be taken into account in 'do_prepare_partial', which is called when
clicking on 'Transfer'.
Note that this bug would only appear if:
- reception in 2 steps is set
- the products are received without scrapping in the first step
- on the second step, we first scrap, then transfer. If we transfer,
cancel, scrap and transfer, it works since the pack_operation_ids have been
calculated correctly during the first click on 'Transfer'.
opw-640415
The group_id of a picking is related to the group_id of the first stock.move
related to it. When a stock.move is added to a picking manually, the group_id
is normally not set. This can be an issue in a very specific case:
- In Settings / Sales, tick "Allow setting a different address for delivery and invoicing "
- Create a SO - Invoicing on delivery
- Customer: Agrolait; Delivery address: Thomas Passot
- Add a line: ice cream
- Confirm the SO
- In the DO, add a line , with an expected date higher than the one of the existing move
- Save
- Mark as todo
- Force reservation
- transfer - transfer
- Create invoice
=> See that two invoices are created, one for Agrolait, one for Thomas passot ( the DELIVERY address )
opw-639955
Make sure that appropriate fields are emptied when switching to in between inventory filters.
This prevents incoherent results due to hidden fields which were filled in a previous selection.
opw-634388
Fixes#6512
This reverts commit a1da6c2132.
This revision was a temporary patch to solve function fields
computation issues, solved thanks to the commit b7f1b9c01e
In the case of sets, several stock moves can have
the same procurement.
Therefore, appending procurements in the list `procurement_ids`
without checking if the procurement isn't already in the list
could lead to having several times the same
procurement in that list,
and could therefore lead to the check of the same procurement
over and over, leading to performances issues and the fact you cannot
call `write` on a list having several times the same id.
See models.py 3875
Using a set instead of a list solve this issue
opw-634393
Revert c06a96 "[FIX] stock: force recomputing transfer information on picking"
and unlink packoperations only when move lines are changed (fix opw 620636).
c06a96 introduced a regression as it prevents to plan moves (e.g. assigning lots
through the barcode interface) before the reception.
When creating a chained picking, the first move has no sequence, this is because
there is no sequence for stock.picking.internal.
Set the sequence before the chained move so that the sequences are in the right
order. opw 621261
The same holds for the inverse history_ids relationship. When an object is copied,
the many2many fields their links are copied.
When we copy a done move as is done in the return wizard to create the reverse, it copied also
the relationship with the quants. This is problematic as this field indicates the quants that
were transferred by the move and the new move will think it will have returned all the quants
even before it is done.
`product_qty` field is not recomputed at record creation.
Force field recomputation at any change
Removing the trigger on `product.product` should not be a problem as
product uom can't be changed once there are move lines.
opw:629650
When the theoretical_qty of the stock is calculated, we should only consider the location itself, not its children.
That way you can have correct inventory for e.g. iPads that are both in Stock and Stock/Shelf 1
The inventory should work with packs. If a pack is not indicated
in the inventory line, it means we correct the quantity for the product
that is not in a pack.
Also, when the lot is False, it should not behave as normal stock moves.
It should correct for the quantity that has no lot.
We try to reconcile the negative quants in the pack also.
When changing e.g. from 3-step to 2-step, we would like to deactivate a location,
but maybe the user still wants to use that location e.g. in a rule on the product, so do a check
if it is not used in some route not related to the warehouse.
In order to do that, we change the theoretical quantity into a functional stored field.
Therefore the on_change changes, but the old still work.
The UoM of the inventory line is also taken into account
[IMP] Manual selection, no theoretical qty compute on import, comments
If the date_done field of the model stock.picking is already filled in
it means the user do wanted to have this date of reception date
instead of the moment when the user clicked the receive button.
opw-627219
The tracking reference and other delivery references are not relevant to
duplicated pickings. Overwrite copy to remove carrier_tracking_ref, volume and
number_of_packages.
Add fallback on stock.picking.in and out to use copy method of stock.picking.
For partial delivery, the duplicated picking is the delivered order and
the existing picking is the backorder of the delivery (why so much hate?).
This means we have to switch the delivery info between the backorder and
the delivered picking.
Combo opw 615593 and 618802
When invoicing from dropshipping picking, choose the correct partner.
Also, change the partner on the picking to be the partner of the purchase.
Change the picking report to include the destination partner or the warehouse address on the right.
[IMP] Only put partner_id on move from purchase when really necessary
[FIX] Default value of partner on stock move should be False
The average price computation is now deduplicated and moved to
a separate function called in stock_move action_done.
This makes sure it is always called when a stock.move is
processed, even without going through the partial picking wizard.
Fixes#2991Closes#3949
OPW-615491
The same is done when extra moves are generated. It is going to check if the UoM of the operation is smaller if it has one.
Throw an error when a key can not be found in action_done because there were links on a move
that was not supposed to be done (e.g. 0.5 Dozen when Dozen is rounded at 1)
[IMP] Throw an error when a key can not be found because of UoMs/picking + extra float_compare
[IMP] Integrate remarks qdp
[FIX] Remaining qty should each time be in the default UoM of the product
Even with different UoM we want a consistent matching between moves and pack operations.
When calculating the remaining qty on move/pack operation we always start by converting the
qty on the move/operation to the default UoM and afterwards we subtract the links between them
which will also be in the default UoM of the product.
In order to create backorders / extra moves these quantities are used.
When a negative quant is created but the positive quant counterpart is reconciling
a negative quant that of course also has a positive counterpart, the latter should eventually
let its field propagated_from_id tell that it originated from the very first negative quant as the
second negative quant will have disappeared through reconciliation.
prodlot_id field may be required due to constraint `_check_tracking`.
When a stock.production.lot is deleted, the constraint on linked stock.move is
not checked. To avoid inconsistency, restrict the suppression.
To allow the modification of existing stock.move, remove the states attribute on
the field definition.
As removal of serial may impact the traceability, it makes sense on buisness
point of view to force the modification of previous stock.move, even if the
constraint would not have been violated.
The list of linked stock.move is present on the serial form view making
the operation easier.
Fixes#3560, lp:1176912
When a picking is confirmed, the generated account.move(.line) should take the
company, accounts, journals and period with the same company as the picking,
not the one of the current user.
This was problematic if a user in a company confirm a picking linked to
a purchase order done in another company.
For real time valuations, the generated accounting entries were mixing both
companies.
Fixes#3466
When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move.
This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed.
This avoids trying to update the stock.move with a uom at False. opw 616844
Implements the UoS TODO items on stock.picking.do_partial() to fix#1432.
Add a new method _compute_uos_qty() on product.product to computes
product's invoicing quantity in UoS from quantity in UoM.
The created invoice will use the product_uos of the stock.move, meaning keeping
the quantity specified on the partial picking and the unit of measure of the
original stock.move (e.g. recieving 1 dozen from a 12 unit picking should either
get uos=dozen, uos_qty=1 or uos=unit, uos_qty=12, not a mix of both)
Fixes#1432, opw 611479
Simplify the action_consume of the consumption lines after the corrections
by Kevin Wang. Also the UoMs are revised as the action_consume uses the default UoM
of the product.
We have to avoid circular boms where a child bom should not contain the product that
represents the parent bom, but it is possible for example to use another product of the parent bom in
the child bom.
As the consume line move has no procurement rule, its origin will have no description. So, when there is
none it will also check the description of the previous move (when passed to procurement for example) This way
the chained moves or purchase order for example will have the MO-number as origin and not nothing.
[IMP] Change assignation
[IMP] UoM changes continuation
[IMP] Make sure we can use 2 times the same product in a BoM
[IMP] Source document for consume lines to procurement
When setlast_tracking is called on a large number of moves in a picking
(e.g. when splitting moves in a picking), the time to complete grows
exponentially. The reason is that it loops over all the moves of
a picking, even if it keeps only the last tracking.
The method now uses a search() with a limit so it doesn't need to browse
all the moves.
Added test to check the behaviour of setlast_tracking
Fixes#2448
When a user tried to delete a done or canceled picking, the error messages used to display the key of the selection field ('done' or 'cancel') which was surprising in other languages than English. This patch takes the string value of the selection field, keeping the context to get the translated value (opw 613068)
Indeed using fromkeys with a list / dict as argument leads to the creation
of shared list / dict. This could create some ugly side effects when
used in loops. This commit fixes or cleans this kind of statement to avoid
unwanted side effects.
[IMP] Add purchase order origin on picking
[WIP] Picking type on move for location on routing
[IMP] Provide extra function for custom buttons on picking
[IMP] Action assign optim
[IMP] Push apply should take invoice_state into account. Propagation of cancel of stock moves should depend on procurement rule
Nicolas Martinelli
Christophe Simonis
Denis Ledoux
Goffin Simon
Martin Trigaux
rmu-odoo
Yannick Vaucher
Akash Balar
Rucha Dave
Josse Colpaert
Leonardo Pistone
Nicolas Piganeau
qdp-odoo
David Monjoie
Somesh Khare
Cedric Snauwaert
Julien Legros
Mohammad Alhashash
Martin Trigaux
Guewen Baconnier
Thibault Delavallée