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
Method action_produce does not support the case where the same product appears
on multiple lines. We do this to avoid major changes in a stable version.
opw-644093
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
BOM Lines are ordered by a sequence field,
the "handle" widget makes even possible the lines reordering.
The order was respected within the mrp.production
(in o2m products to consume and consumed products)
but not within the mrp.product.produce wizard
opw-629629
When comparing a float value to 0.0,
it can happen the float value is very near to 0.0,
but not exactly 0. This is the point to use float_compare,
```float_compare(qty, 0, self.pool['decimal.precision'].precision_get(cr, uid, 'Product Unit of Measure'))´´´
will compare qty to 0, with the product unit of measure precision (0.01 by default).
So, if qty is equal to 0.00001, this means the qty is regarded as equal to 0.0.
(float_compare will return 1).
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Upstream traceability on produced goods (serial number on finished product) was
broken due to wrong values in cache for production.move_lines2 after production.
Refresh the value of production after each action_consume to make such the state
of the cache is correct. opw 609450
Similar fix for manufactruing order not going in done state in some specific
configrations (e.g. some components being phantom BOM).
Again due to wrong cache state after consumption. opw 610515
Fixes#1296
The method test_if_product, used in the workflow to test that the mrp production is for a product (!= service), used to call the method _action_compute_lines in order to compute the production lines and determine from them the production type.
The thing is, the method _action_compute_lines, despite the fact it returns the lines of the production, actually creates the lines. So, just to test if the production was of product type, the productin lines were created, in database.
This rev. introduces a _prepare_lines method, which returns the computed production lines, without actually creating them in database, so the test_if_product method can test if the production is of product type without creating the production lines.
Therefore, production lines are now computed and created during the action_compute method, instead of computing them when the production was tested to get the production type.
Computing the lines before the action_compute has as side effect to not set the scheduled date of the work orders in module mrp_operations, at MO confirmation (as, on confirmation, the action_compute method is called only for productions for which the lines are not yet computed, and mrp_operations overide action_compute to set the scheduled date)
opw-620189
Pass group_id information when a manufacturing order is created from
a procurement to keep a better traceability and know the reason of stock.move
creation.
Fixes#4019
if the bom is phantom and has no line, we attempt to find a new bom with the default product uom
This is possible that we find the same bom that the current one
In such a case, we must not explode, to avoid recursion.
This rev. 7307227 ensured to not (re-)set the state 'confirmed' to exploded moves with a more advanced state (for instance, 'assigned')
Nevertheless, the location chaining is performed on the move confirmation, through the action_confirm method of the stock.move model. Besides, the resulting moves of the _action_explode method had the state 'confirmed' on creation, the 'confirmed' state wasn't set by the method 'action_confirm', meaning that the moves were confirmed without having the location chaining done. Allowing moves to go through the action_confirm method even if the state was 'confirmed' or further triggered the location chaining.
Preventing already confirmed moves to go through the action_confirm method prevented the location chaining, thus.
We now create the resulting moves with the 'draft' state, and then confirm them through the procurement workflow signal 'button_confirm'. Thus, the resulting moves are confirmed by going through the action_confirm method, writing the confirmed state and triggering the location chaining at the same time. We then write the 'assigned' state if necessary.
opw-617235
The field bom_id is required on a manufacturing order and deleting a mrp.bom would block the current mo.
Restrict the suppression for manufacturing order in progress.
Fixes#3417
This reverts commit 61a8971db5.
This rev. is from a 7.0 forward port b4d602fdd3379a0310ec0b9a56f9b88226
This is no longer needed in 8.0, with the new WMS
When validating a SO containing a `make to stock` + `manufacture` product
(with bom + orderpoint), we have the following stock moves:
* Product move
* Manufacturing order
Selling 1 such product would yield 2 as incoming quantity, an
inconsistency that this commit solves by setting the location_id of the
product move to the MO's location_dest_id (in the same fashion that
the create_pickings method does in an mts/buy case)
opw-616229
When consuming product, the main_production_move is set as the source of production (used for consumed_for parameter)
However the method action_consume now (since 661a204) returns the new moves (when spliting) instead of the original one. This means that the tracebility would fail.
[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
A previous refactoring brought a bom_line_ids field on the mrp.bom, thus
deprecating the _child_compute method. But the previous refactoring did
not go through all the views, breaking everything that relied on the
_child_compute (tree view, report). As the bom_line_ids refers to the
mrp.bom.line model (introduced by this previous refactoring, note:
_child_compute returned mrp.bom record) and that we can't make a treeview
showing different model, this patch introduce a function field _get_child_bom_lines
on the mrp.line model, allowing to go through the bom_line_ids of a mrp.bom.line
if this mrp.bom.line refers to a mrp.bom.
[IMP] Rename bom_line_ids to child_line_ids in mrp_bom_line to avoid confusion
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
[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
For instance, setting a BOM Phantom with:
Finished product: stockable, MTO Manufacture
Components: stockable, MTS, Buy. Inventory set to 1000
Stock moves of components are directly set to assigned once the procurement confirmed thanks to JIT
The stock moves should not be set back to confirmed after they have been assigned
Odoo Translation Bot
Martin Trigaux
Goffin Simon
Jay Patel
Christophe Simonis
Nicolas Martinelli
Denis Ledoux
Xavier Morel
sve-openerp
Valentin Chemiere
Olivier Dony
Daniel-CA
Lionel Sausin
Rifakat Haradwala
Loïc BELLIER
Josse Colpaert
vnsofthe
Aaron Bohy
Ravi Gohil
Akash Balar
Holger Brunn
Benoit Guillot
Raphael Collet
Christophe Matthieu
Julien Legros
kevin wang
Simon Lejeune
Alexandre Fayolle
Fabien Pinckaers
Florian Hatat