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.
The previous filters didn't take timezones into account, and
returned stringified naive datetime values in local browser
time. Those would then be interpreted by the server-side as
UTC date, and depending on the current timezone offset vs UTC,
yield partially incorrect results.
By returning directly a datetime.datetime object instead of
a stringified version (see previous commit 76881fb),
we can get the expected result regarless of the timezone.
Fixes#2972Closes#6229
opw-621282
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
When clicking on the Transfer button on a picking the packoperations should
always be recomputed.
If the pack operations are only computed the first time, the picking could be
modified (e.g. notice wrong quantity) and still display previous operations when
reloard the transfer button. opw 620636
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.
Only when the picking is partially available, the system will only show the amount of products available.
That way, when working with paper, the warehouse operator will only get what is available. This is the case
where we did not launch the bar code interface or the transfer wizard.
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
It makes no sense to allow inventories in supplier locations as it won't anyway
reduce the Inventory if we want to downsize the inventory. This makes
the Inventory act weird.
Ex:
1. Initial situation: 20 units of stock A at supplier's location
2. Makes an inventory stating there is in fact 0 qty of product A at that
location (in the hope to remove some quants).
3. Still 20 units in Suppliers location + 20 units in Inventory loss...
Managing specific suppliers destination is currently not supported.
Same issue with production locations.
Fixes#5052
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
Only admin was able to create product.putaway records. Gives all access
to warehouse manager.
If a putaway strategy was present on a location, a warehouse user was not able
to transfer goods as he had no access to the rule lines (no read to
stock.fixed.putaway.strat). Give read access. opw 619774
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
When creating a return picking, the default invoice state is 'To Be Invoiced' if
returned picking was invoiced. However if the invoice of the picking has not
been generated yet (state '2binvoiced'), the return should also be invoiced.
Fixes#4002
If a stock picking type was disabled, but had pickings in assigned or partially available state, the barcode interface main menu crashed
Because the stock picking type was not available in pickings_by_type array
If a wizard is launched from an embedded view list, only the record of the line from which the wizard was launched is reloaded after closing the wizard.
In this specific case, as new lines are added to the picking, we need to fully reload the stock picking
Fixes comparison with min_quantity orderpoint in scheduler - basic floating
point math issue in procurement scheduler when comparing current quantity
with orderpoint minimum quantity. In certain cases floating point comparison
could result in e.g 400.0 < 400.0 == True due to typical floating point
comparison issues, as Odoo doesn't use Decimal types where the issue
doesn't exist.
Fixes early exiting out of the loop cycle, in case qty is already near zero.
Fixes the new procurement creation check, to not do that if it's close
enough to zero already, to be considered a floating point math error, not
really non-zero.
These combined (or at least the last one) avoid each supply_method == buy
pending in draft PO's getting a zero quantity extra procurement order each
time the scheduler runs. Otherwise there could be hundreds of zero quantity
procurement orders pending, which makes the confirming of the PO take hours,
due to creating hundreds of stock moves for each order line.
Use float_compare helper to solve all these with floating point type for now,
instead of the more evasion possibility of converting to Decimal module.
Two potential bad comparisons remain, add FIXME notes for now until further
analysis.
Also: Float rounding on reste when comparing and on the procurement qty
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
[FIX] super of scheduler should have same params + use_new_cursor should be passed to procure orderpoint confirm
[IMP] Make sure the delivery works when doing phantom boms
[FIX] This should update the average price properly when having multiple moves with the same product
[FIX] Average price should take into account the quantities of all variants
[FIX] Make sure purchase picking type in other company works
[IMP] Views of quants and destination locations of moves
[IMP] Provide better purchase order picking type
[IMP] Possibly a better product uos handling in the sale order line
[FIX] Recreate of delivery order when sales order in shipping exception
[FIX] Delivery method should be passed to delivery order
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
Source and destination locations are required and not displayed in the form view.
Adding new items when recieving a picking can not be easily guessed as we can put different locations for each line, using default locations may not be the expected result.
Instead should modify the original picking or create new one.
Fixes#2074, opw 612768
Use group_production_lot for serial options, group_stock_packaging for packaging, use group_tracking_lot for pallet/parcel
Groups are removed completly from the view for stock.tracking as they render the view useless.
Always display weights on the product form
They really have nothing to do with the logistic units and we don't have another group to restrict them to.
Fixes#1443
[IMP] Recheck should be type object and procure_method read only when not in draft
[FIX] Inversion of moves in the correct way and assigning production_id
As the moves are split the other way, the original move needs to be done. Also the production_id for linking the
new to be produced moves and the production order must be written on those.
[IMP] Clean
Module description of procurement was deprecated (talking about mrp, ...) and in product_extended
it described things not implemented in the module.
In _bom_find, we passed a UoM which was not used in Saas-4 and it would not be logical that you
need to select a BoM that matches the UoM, so I removed it.
In the demo data, there was still a push rule which triggered a move from output to pack. The copy=False
is correct for production_id when you would have these push rules.
For the properties: we want to allow to take a bom which has no properties, but only when there is no other
BoM matching the properties we pass.
Update module descriptions
[IMP] production_id copy + no round
[IMP] _bom_find without uom, property correction
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
The stock_partial_move wizard removes the required attribute for the field picking_id on a stock.partial.move. This means that we could get moves without picking_id and the previous line was failing ('NoneType' object has no attribute 'currency_id'). opw 614531
Nicolas Martinelli
Goffin Simon
Denis Ledoux
Martin Trigaux
Olivier Dony
Nicolas Lempereur
david.beal@akretion.com
Christophe Simonis
Rucha Dave
rmu-odoo
Leonardo Pistone
Yannick Vaucher
Akash Balar
fka-odoo
Josse Colpaert
Nicolas Piganeau
Denis Michiels
David Monjoie
Antoine Huvelle
qdp-odoo
Xavier Morel
Somesh Khare
jir
Aaron Bohy
Gaurav Panchal
Commandant Custo
Cedric Snauwaert
Mart Raudsepp
Julien Legros
Loïc Bellier
Mohammad Alhashash
Edy Kendengis
Ravi Gohil
Ravi Gohil
Lionel Sausin (Numérigraphe)
qdp-odoo
Martin Trigaux
Guewen Baconnier