When clicking on the BOM state button from product.product, and clicking
on create afterward, it must open mrp.bom view with the product and product variant
already set(as with product.template).
opw:645045
If copy=True for production_id, a move created from a push rule will be added
in the list of Product Produced. Therefore, we must set manually the value of
production_id of the scrapped moves.
opw-643877
This is a performance revision.
Some stored functions field were recomputed uselessly.
In mrp, `hour_total` and `cycle_total` were recomputed
at each write on `mrp.production`, while they should be recomputed
only when there is a change on the `workcenter_lines` field,
or when there is a change in the `hour` or `cycle` field
of these `workcenter_lines`.
In stock, `min_date`, `max_date` and `priority` of
`stock.picking` were recomputed each time a new move
was added to the picking,
wether or not the 'expected_date' of this move
was between the `stock.picking` `min_date` and `max_date`,
and the priority not greater.
In stock, `product_qty` of `stock.move` was recomputed
at each write on the `stock.move`, while it should be
recomputed only when there is a change in `product_id`,
`product_uom` or `product_uom_qty`, as the computation
method only depends on these three fields.
In stock_account, the `invoice_state` of `stock.picking`
was recomputed each time a new `stock.move` was associated
to the picking, wether or not the `invoice_state` of the move
was already the same than the `invoice_state` of the picking.
opw-643560
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
When a MO is cancelled, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
Was removed at 5b479e6 as no longer used (and was a wrongly used there as dit not
check if a "normal" BoM has an higher sequence).
However for stablility reason, we do not remove methods in version 8.0 (if was
used in community).
Will be removed in master.
Manufacturing Orders can be created from procurements,
as SUPERUSER_ID, since the procurements can be processed
through the WH scheduler, which is always ran as SUPERUSER_ID
In such a case, the record rules are ignored, and a BOM
normally not accessible to a user thanks to the multi-company
record rule could be chosen as the BOM of the MO.
This revision forces to find a BOM from a specific company
in such a case.
opw-640120
Avoid ZeroDivisionError if a move is confirmed with quantity of 0 (when stored
in database where the rounding is done by the precision defined on product_qty
field.
Fixes#6439
-Test the function _bom_find to check that it searches the bom corresponding
to the properties passed or takes the bom with the smallest sequence.
For this commit: d357667df4279070b51af58cad55ef314688d69f
- Test the function _bom_explode to check that it only takes the lines with the
right properties.
For this commit: 6b6e71a3e0c86aa8a9b8c4f20eaa61b17c64ce7b
Now it's possible to put a property on a bom line.
For example, the bom for an apple pie and for an apricot pie can be made
in a single bom.
Three lines are necessary in the bom of the product "pie":
- First line with product " dough" without property
- Second line, with product "apple" with property "apple" if you want an apple pie
- Third line, with product "apricot" with property "apricot" if you want an apricot pie
The type of this bom pie must be "set" to allow the customer to assemblate
his favorite pie by himself.
Now to sell an apple pie, you must create a SO with the product "pie" and
the property "apple".
In that way, the delivery order consists of two lines:
- dough
- apple
The bom related to the product in a sale line order must be
filtered by the function _bom_find. If two boms can be applied
on a product, the bom with the smallest sequence is applied.
opw:632558
The action_confirm function losses the context when called by a workflow.
To have the right translation, the lang of the user must be written in the context.
opw:632873
Relax the constraint on BoM to allow to have two different lines with the same
product. As the error message says, the purpose of the constraint was to forbid
having the manufactured product as one of the components but had this side
effect.
Such scenario of the same product twice makes sense when using the date
attributes on the lines (e.g. changing quantities)
opw 621468
Actions button on the work order lines can change the state of the manufacturing
order. As for the product lines, reload the form after actions.
opw 625424
In BOM, when performing an advanced search
on "BOM Lines" contains "a name"
all lines were returned, whatever the lines content.
This was due to the simple fact no field 'name'
was set on the mrp.bom.line model.
We set "product_id" as _rec_name, it seems the more
logical choice.
opw-631335
It is very cumbersome to define routes which have 2 step in on production for certain products with
procurement rules (e.g. Stock > Raw Materials Location > Production), when the
products are MTS elsewhere. That is why we add the possibility, which might be elaborated in the future,
to define rules e.g. from Stock > Production, which you can put on the product / product categories. These
rules will only define the procure_method for now.
ORM will show lines in production.move_lines even if done (which the domain should avoid)
when processing the production (as they are probably still in cache). We explicitly skip those lines.
When producing more with lots in consumed and produced, we added the consumed_for link as
the lot tracking requires to have this link between the consumed and produced moves.
The extra move of the produced goods should also be confirmed and not created as confirmed immediately.
That way it can still apply the push rules. (Gabriel Demmerle)
In manufacturing bom lines, digits_compute is set
to the precision 'Product Unit of Measure'.
It should be the case as well in the produce wizard,
otherwise you won't be able to change the quantity
within this wizard to the according product quantity precision
opw-629657
Odoo Translation Bot
Martin Trigaux
Goffin Simon
Jay Patel
Nicolas Martinelli
Denis Ledoux
Xavier Morel
sve-openerp
Valentin Chemiere
Olivier Dony
Daniel-CA
Lionel Sausin
Christophe Simonis
Rifakat Haradwala
Loïc BELLIER
Josse Colpaert