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
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)
The onchange_product_id method used to only change the description if the stock.move is not saved yet. That does not make much sense.
opw 607347, bug lp:1314700
Users don't care for the backorder picking precisely because they can't process it, whereas they may have to do some more things on the picking they processed: invoice it, print delivery orders or transportation stickers..
Refresh the browse record after changing the name to avoid the need to rebrowse.
Fixes#1372
The user_id is already set by the prepare_invoice method, which is called before the prepare_invoice_group (the user_id is already set, thus)
Besides, _prepare_invoice is overriden in sale_stock, to set the picking sale order salesman as user_id, and, without this correct, grouping invoicse by partner re-set the user_id to uid, which is wrong.
When creating a grouped invoice, the invoice_vals value is used to create the invoice line.
The value was not reset for grouped invoice and we reused the values of previous line.
Before, all moves issued from a same purchase order were put in the same chained picking, and, therefore, the moves were all treated with the same behavior (manually, automaticaly, ...)
bzr revid: dle@openerp.com-20140415160331-kzgib87qabvpc86p
This assumption is incorrect in OpenERP v7. The WMS
design in OpenERP 7 and previous versions only permits
tracking production lots (aka serial numbers) on
incoming moves, outgoing moves and production moves.
You can specify production lots on internal moves too,
but the system will also generate internal moves for
many reasons, and nothing guarantees that they will
have the right lots assigned.
This is a design decision, and this means that we
must never enforce the availability of specific
production lots.
This features will be available in OpenERP 8 through
the use of an extra concept called "Quants", that
will make this kind of tracking possible.
bzr revid: odo@openerp.com-20131112153925-1s2b8f2eo568wpxh
This can create inconsistencies in the warehouse inventory
in case delivery orders are not customer-specific, e.g.
when using the POS.
When there is no destination customer we can still use
the default Customers locations.
bzr revid: odo@openerp.com-20131107105302-hf8lublc1x3qc87h
It is a common need to set a higher decimal precision
for `Product Price` (i.e. the product cost field) for
high volume / low value items. This may typically
require up to 4-6 decimals for e.g. EUR/USD-based
companies where the currency has 2 decimals.
In that case the product cost should be stored with
full precision without applying the currency rounding.
The appropriate currency rounding will be applied
anyway as soon as a transaction actually uses that
product cost (typically in a SO/PO)
bzr revid: odo@openerp.com-20131104173232-84g115x6ykxoc1rh
While processing a picking we must keep track of
previously processed lines as they modify the
stock on hand but are not yet included in the
`qty_available` function.
Negative stock on hand is handled as if
the stock was zero as far as the average
price computation is concerned.
bzr revid: odo@openerp.com-20131104171245-z1lgsplyu4cdz9gc
Many2one fields resolve to strings when used
as `self` within the @context or @filter_domain
attributes of a search field, because they
must be able to support partial matches,
e.g. search for "Sto" to match "Stock".
In many case the code was not prepared to accept
string for the magic context values, so the
magic fields now caused crashes.
The widget="selection" attribute was dropped
during the search view cleanup for 7.0,
without noticing this unfortunate side-effect,
at revision:
addons 7.0 revno 7142 revid:qdp-launchpad@openerp.com-20120731150358-jqd3eoz06imzlx01
lp bug: https://launchpad.net/bugs/1192484 fixed
bzr revid: odo@openerp.com-20131004105218-edvb5ewduqar3x88
This will only display newly posted messages, not already existing.
To do so apply the following SQL command:
UPDATE mail_message SET model = 'stock.picking' WHERE model = 'stock.picking.in' OR model = 'stock.picking.out';
lp bug: https://launchpad.net/bugs/1197169 fixed
bzr revid: mat@openerp.com-20130828151434-5nu7o0ybguh86w6f
Martin Trigaux
Mohammad Alhashash
Guewen Baconnier
Martin Trigaux
Rifakat Husen
Lionel Sausin (Numérigraphe)
Denis Ledoux
Hardik Ansodariya
Anaël Closson
Yannick Vaucher
Denis Ledoux
Olivier Dony
Christophe Simonis
Dhruti Shastri (OpenERP)