The mrp_production graph view group records by date_deadline. This
date is optionnal so the graph view could missed some records if the date
is empty.
This commit change it by a required one (date_planned_finished) in order
to display all productions
closesodoo/odoo#36939
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Give to a regular mrp user the same access rules than he has on
production orders.
closesodoo/odoo#36883
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, the product/product template computed mrp quantity
fields wasn't computed by active company but for all companies.
So, set `compute_sudo` on false for the different computed mrp quantity
fields of products and product templates to avoid to search with sudo
active and to search by company.
rev [0] was incomplete, the
possible_bom_product_template_attribute_value_ids field was not computed
in mobile because parent_product_tmpl_id was not sent to the server.
rev[1] broke the normal produce wizard
[0] 5d5644c721
[1] 916b49381bclosesodoo/odoo#36595
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When trying to update a BoM from an ECO, `default_product_tmpl_id` is set
in the context. This was mismatching whith the product template of any new
BoM lines writen on the new BoM. To fix this we simply add the field
`product_tmpl_id` in the view of the BoM lines with `force_save` set,
to prevent using the product template defined in the context.
closesodoo/odoo#36469
Taskid: BugsLogistics
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
— create a bom which uses 5.6 units of a product;
— make a production order;
— reserve the materials (all materials should be available);
— print the production order report.
Before this commit, a warning message in the report that says : 'All
components could not be reserved. Click on the "Check Availability
button" to try to reserve components'. This warning message is shown
despite the fact that all the components are reserved. This occurs
because of a rounding error.
Now, the warning message only when a component could not be reserved.
opw-2058921
closesodoo/odoo#36462
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
Let's consider two storable products P1 and P2 where P1 is tracked by serial number
- Create a BOM B for P1 where P2 is a component
- Create a serial numberv SN for P1 with no quantity
- Create a MO M1 for P1 and click on button "Produce"
- In the view MRP Product Produce, SN is selectable in the field lot_id
- Now change B and set a routing on it
- Create a new MO M2 for P1 and click on produce
- At least one WO has been created, click on the first one
Bug:
- SN is not selectable in the field final_lot_id
The domain set on the field final_lot_id:
"['|', '&', ('product_id', '=', product_id), ('product_id.tracking', '!=', 'serial'), ('use_next_on_work_order_id', '=', id)]"
didn't allow to chose SN.
With this fix, it's now possible to chose SN on the first WO created for M2
opw:2059745
closesodoo/odoo#36425
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The condition needs to be fined-tuned, so revert for now.
This reverts commit 40487aca5c.
closesodoo/odoo#36470
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a MO with a product with a normal bom B
- Save the MO
- Change the type of B to phantom
- Try to produce the MO
Bug:
It was impossible to cancel or confirm the MO.
It's not allowed to produce a MO with phantom bom.
opw:2061958
closesodoo/odoo#36329
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
It's due to MRP refactoring that confirm raw moves before finished
moves. It implies that in _assign picking, SFP with final product
will search a picking but the stock.move do not have a created_production_id
and it will be merged inside the intermediate SFP (it works before
because it was the intermediate SFP that was merged in the finished SFP).
_key_assign_picking is also added if multiple moves are confirmed w/
and w/h created_production_id, we won't merge them in the same picking.
closesodoo/odoo#36335
Signed-off-by: Christophe Simonis <chs@odoo.com>
Enable work orders, routings, and track components by lot numbers or serial.
Create an MO for a certain X quantity of finished products and plan work orders.
Only complete a partial amount Y of the overall X amount.
Specify the lots for the consumed tracked materials equal to the Y amount.
Then, return to the MO and click "Post Inventory".
An error is raised because the lot is missing.
This is because when processing workorders temporary lines
are created without lot/serial for tracked component products.
This is a limitation that require a task to be removed;
in the meantime we remove the button, in true bugfix fashion.
opw 2049806
closesodoo/odoo#35731
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
usecase to reproduce:
- Set the warehouse with manufacturing 3 steps
- Create a BoM with a Components that use a Sub BoM
- Set Both product MTO + Manufacture
- Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO. So the solution would be to
add a condition to _assign_picking and don't merge moves if they come
from different MO, at this point the field created_production_id would
fit. However this solution is not robust if a customer creates a
new rule that add a 4th steps to the production process.
opw-2055688
closesodoo/odoo#35915
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Andrea Grazioso (agr-odoo) <agr@odoo.com>
There was a first version of mrp_subcontracting at rev [1] and now
there's a second verion at rev [2]. As the second version sensibly
changed the flows and models AND we don't have the time to backport the
changes AND saas-12.3 will be released on the saas, we chose to remove
the module in saas-12.3 to not have to support both version once v13 is
released.
[1] d91db5bde6
[2] 9b6a5398dfclosesodoo/odoo#35898
Signed-off-by: Christophe Simonis <chs@odoo.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
Make sure unbuild have proper sequence for each companies.
The produce wizard and workorders company is the one of the production.
The BoM line company_id is the one of its bom_id.
Added some tests.
task-1985992
In this commit alignment in bom structure & cost report
display in proper manner.
task-id : 2059697
closesodoo/odoo#36225
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When we change quantity to produce in mrp, all component lines are
removed and new line with the updated amount to product are created.
The problem appears when we change the quantity to produce and directly
click on a component line, because we open the line that will be
deleted. So if we change the quantity for this component manually,
this suppressed line will be added with the new value. And the computed
line will be also be added. So the line for one component will be
present twice (one with computed value and one with manual entry value).
To avoid this problem, when we change the quantity to produce, we update
information of each line (instead of deleting and creating new one).
So if we click on a component line just after changing the quantity,
we open the updated line (and not de deleted one).