In some flows, a planned_datetime_start/finished will contains
milliseconds. In these cases, we can detect overlaps/conflicts between
workorders but these conflicts can't be see in the web interface
(because datetime is truncate when it is display).
Then, change the conflicts computation to remove milliseconds
in search of conflicts.
task-2169447
closesodoo/odoo#43013
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Now, the fields date_planned_start and date_planned_finished is
required in views, because it was strongly related to the leave date_to, date_from
which are required.
- Change the name_get in case of single WO in MO and replace the dot
by a dash.
- Improve the WO form view to be more responsive when it is open from the
gantt view.
- Change name of a Operation in the demo data
task-2169447
- Before, the auto-planning of workorder autorize overlaps between then.
E.g. if a workorder (WO1) begin at Now + 30min with a duration of 60 minutes
and we try to plan a new workorder (WO2) Now, this one will be plan now
until Now + 120 min (30 min of WO2 + 60 min of WO1 + 30 min of WO2).
In our case we don't want this behavior by default,
because in real case, it is not efficient to work on job A during
30 min, after change to pass to a other job B, and rework on A after
the job B.
But in a other hand, we need to accept overlaps with no-working hours
intervals. Then, rewritte the _plan_workorders method to take
these features in account.
Also small fix about the planning has been done:
- Due to the strong link of date_planned(_...) between the MO and WO,
the replan of the late first WO was wrong.
If the MO is planned before now, then don't take in account
date_planned_start and try to plan WO as soon as possible.
- Also, fix error handling when the WO is planned before the
previous one.
task-2169447
- Create a new Product
- Add a BOM to this product
- Set the BOM to be a kit
- Add components to the BOM
- Create a PO for the components for a qty of 5
- Confirm the PO but don't transfer the products
- Check the phantom kits outgoing_qty and incoming_qty they will match
A Phantom Kit Products outgoing_qty and incoming_qty are identical
Closes#43447closesodoo/odoo#43584
X-original-commit: 4b2e235be6cab947ce2e0b3b17b54530f984ce72
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Show the Post Inventory button to manufacturing users,
also if they are not in debug mode.
task-1887035
closesodoo/odoo#43294
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Keep the same UOM than the MO.
opw-2169377
closesodoo/odoo#43407
X-original-commit: 942154b3140cb3fc92e8aeff0241149e701581a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In this commit,
-The behaviour of drag and drop is blocked when grouping the
operation type and warehouse on inventory dashboard.
closesodoo/odoo#43229
Task-id: 2167610
X-original-commit: 5e8bcd3a5bfff9a5dc740287605d4ff661a701f7
Related: odoo/enterprise#7689
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Previously when the BoM on a product do not have components but only
services. Then during scheduler a log was posted on the product explaining
that components are required.
However since this process is possible in another usecase it should be
possible with procurement. The only difference is that procurements
confirm records in order to propagate. In this case since there is
no components and services are not propagate with procurements, it's
not needed to confirm the MO.
closesodoo/odoo#43133
Task: 2170845
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.
Task-2043927
closesodoo/odoo#41056
Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When the scheduler runs, each orderpoint will check the forecast stock
for an infinite time. As example, if we plan a receipt of 10 products in
4 months and need to deliver 5 products next month, procurement will not
be launched since we have a forecasted quantity of 5.
In order to improve it, the orderpoint will compute the total lead days
from rules, suppliers/production delays, security days,...
Those lead days will be added to today in order to know at which date
the forecast stock should be checked and trigger the replenish document
for today in order to be delivered at the correct date.
Task: 1849912
Currently orderpoint run one request at a time. However it's not
efficient since compute are some private methods could be executed
one time in batch instead of record by record.
The strategy in order to improve it is:
- Still cut the orderpoints in batch of 1000 (usefull when using a new
cursor with intermediate commit)
- For each batch of 1000, create a list of procurement values and run
them in batch (commit a2a6b099a4 for more info)
- Each time a procurement exception is raised, catch the failing
orderpoint and rollback to the state before run. Remove the failing
order point from the current set and run it again.
- run method try to catch a maximum errors by continuing to process even it
finds error in order to stack them. It would avoid to run the same set
again and again each time an error is raised.
test_orderpoint_1 took 975s before this patch and 100s after.
Task: 1849912
Currently when a procurement fail it will raise a user error.
Some function as run in stock_rule catch the errors and merge
them in a single error.
Also since commit a2a6b099a4 procurements
are executed in batch and in some cases, we would like to have more
information about the error. For example in orderpoint we would like to
know which orderpoint is responssible for which error.
It would also be possible to return an object with the details but
procurements pass through a lot of different method that already have
their own return signature and a simple exception is easier to manage.
Task: 1849912
_log_downside_manufactured_quantity is an api.one method since it would
log the production info on the generated acitivty.
Since commit b499c3308c, an unlink will trigger an _action_cancel on
unlinked MO.
So unlink multiple MO will call _log_downside_manufactured_quantity
with multiple records and traceback.
closesodoo/odoo#42892
Task-id: 2168386
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Make sure `to_date` is not `False` before comparing.
opw-2165860
closesodoo/odoo#42855
X-original-commit: dbb478507791957e3329d68cfb68dd4f1fab4b70
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Remove color and capacity fields of mpr.workorder unused
and coming from commit : 2ddc35a530 .
closesodoo/odoo#42498
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
_get_unavailability_intervals didn't return the correct
dict (describe in the docstring). Then the override in
maintenance module was wrong.
task-2082261
closesodoo/odoo#42530
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create products A & B
- Create a BOM: 1 unit of A to produce 1 unit of B
- Create a Route which applies on products with the following Rule:
Action: Push To
Operation Type: YourCompany: Internal Transfers
Source Location: WH/Stock
Destination Location: WH/Stock/Shelf 1
Automatic Move: Automatic No Step Added
- Apply the route to A
- Create a MO for B, validate
- Create an Unbuild Order for the MO created, validate
The component (A) has a `stock.move` to WH/Stock/Shelf 1 but a
`stock.move.line` to WH/Stock.
This is because the `stock.move.line` is created when the quantity is
set in:
https://github.com/odoo/odoo/blob/98b1039705d5911946ed3b5180e4d114dc809ed4/addons/mrp/models/mrp_unbuild.py#L151
However, the `_run_push`, which only changes the `stock.move` location,
is called on `_action_confirm` during the call to `_action_done`:
https://github.com/odoo/odoo/blob/98b1039705d5911946ed3b5180e4d114dc809ed4/addons/mrp/models/mrp_unbuild.py#L152
The solution is to call `_action_confirm` before the creation of the
`stock.move.line`.
opw-2156132
closesodoo/odoo#42493
X-original-commit: ac0f43f704a988f11e4670e241380b76dc81f8fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Add two widgets in the `mrp.production` / `stock.picking` form view.
The widget is visible only if one of the stock move linked to the `mrp.production` / `stock.picking`
has the flag `delay_alert_date` set.
Task #1970595
Add scheduling information (icon) with popover to show info/warning/error
about the scheduling of workorder. Four extra pieces of information
is given (level change the color of the icon):
- Info level; If previous WO and pending state, show sheduling info of the previous WO
- Warning level; info if the WO is late
- Error level; if conflit with other WO (same workcenter in same time)
- Error level; if previous WO is planned after the current one
Also, add a button (in the popover) to replan correctly all WO of the MO of
the current WO (only if it is not in ready/progress and error(s) is detected).
It is done via a JSON data compute field ('json_popover') in the workorder and
the popover_widget of stock. It is allowing use to make computation in batch
and avoid to add lot of fields.
task-2082261
closesodoo/odoo#41950
Related: odoo/enterprise#7296
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In order to clarify the flow of work order in calendar and gantt view,
add the sequence number of WO by MO. This sequence is
compute during the call of the "name_get".
task-2082261
Change the order of the page of notebook to be
more pertinent for the manager point of view.
Also move workcenter and production (_id) fields
from the miscellaneous page into the main form.
task-2082261
When a manufacturing order was created through a stock rule, the `delay_alert`
feature was broken. Indeed, we should store on the order the `delay_alert` value
similar to what we do with the `propagate_date`, `propagate_date_minimum_delta`
and `propagate_cancel` fields.
We thus add the missing field and add the values in the multiple prepare methods.
We also the missing values for `propagate_date_minimum_delta` and `propagate_date`
in `_get_move_raw_values`.
task-2154781
closesodoo/odoo#42032
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`propagate_date` enables the automatic rescheduling which could lead to hard to
understand behavior if a manufacturing order is planned, i.e. if the work orders do
have their leaves booked in the workcenter calendar. We thus disable the
automatic rescheduling in this scenario.
task-2154781
Before this patch, writing on the `date_expected` field on the raw moves did not
update the `date_planned_start` (but writing on `date_planned_start` did write on
the raw AND finished moves `date_expected`).
This proved to be wrong: having the same `date_expected` on both raw and finished
moves did not make sense (the manufacturing order is not instantaneous). It also
makes difficult to make the rescheduling work: the rescheduling is done on the stock
moves and thus updates `date_expected` on the raw moves. If this information is not
transmitted to the manufacturing order, we won't be able to continue the rescheduling
on the finished moves (the idea is to update the raw moves which will update the
date_planned_start which will update the date_planned_finished which will update the
finished moves)
To have a more sane system, the `date_planned_start` and `date_planned_finished` are
computed (with an inverse) on the raw and finished moves `date_expected` (similar to
what's done on the picking model). There's a tweak though: as `run_manufacture`
creates first the order with a `date_planned_finished` and then confirm it (which will only
create the finished move at this moment), there's no place to write `date_planned_finished`.
The compute thus defaults on `date_deadline` which is stored and the finished moves
will be created later on with this value.
We implement the same logic `_onchange_date_planned_start` in `write` so that it doesn't
only rely on the onchange mechanism and the rescheduling can work when changing the
`date_expected` on a child mo for example.
task-1970595
Before this -
If we have follwing configuration -
Manufacturing -> Propagate Cancel -> True
Buy -> Propagate Cancel -> True
* BOM of a Car -
1) Component 1 -> Iron (MTO & Buy)
Now create a SO of product Car and confirm it.
It will create a MO (Car) and then PO (Iron).
Now if PO is cancelled, it will cancel its
move_dest_ids and on change of it MO will be
cancelled but delivery move will remain ongoing.
When action cancel is called on a move raw, it will
check if the production order is also cancelled.
If the MO is cancel, in this case cancel also its
move finished.
Task-2117832
closesodoo/odoo#42209
X-original-commit: 9522e51a3b290c91f23658a4fb781003ff1fd8d2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The inventory button was shown or hide depending of the product valuation.
As the valuation was previously stored on the stock moves and posting
split the stock moves. Fifo and Avco valuation was not well computed.
The migration to stock valuation layer fixed this behavior. This
commit shows the post inventory button as soon as there are some
finished move to be posted.
task : 54665
closesodoo/odoo#41781
X-original-commit: 5dfa3f817d3a9f47a863a587569a862a40c7d159
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The commit 75460e697a was introduced in
v12, when the workorder stored their consume data on stock.move.lines.
Their was an issue when posting intermediary inventory on productions
using workorder. As those 'dummy' stock.move.lines did not have their lot
field filled, an error at line validation was raised.
In v13, the workorders use workorder lines. The lots and quantity are
transfered on real stock move lines only at the end of the production.
Posting intermediary inventory did not failed anymore in case of partial
production
Task : 54665
X-original-commit: a41239b378a1cae394d18f43e991ec8bceeac826
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
steps to reproduce:
-install the manufacturing app
-install studio
-go to manufacturing > click on the studio icon (top right of the window)
> click views > activate the gantt view
you should see a traceback with the following error
"Invalid field 'progress' on model 'mrp.production'"
mrp_production does not have a progress field => removal of the
property "progress" in the view fixes the issue
opw-2144823
closesodoo/odoo#41197
X-original-commit: 31bf253110b9a77ec8d6185b66157cdbfe9e67f5
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
Previously, when grouped by state, user was able to drag
and drop kanban boxes to alter the state of an unbuild, a
purchase requistion or work order. However the state should
be readlonly and could only be modify via public methods on
those objects. Those methods do additional required stuff than
just modifying the state.
task-2087309
closesodoo/odoo#40759
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Use case:
Plan a production of 10 units on 2 workorders. Produce 4 units of lot1.
Record the production and produce the 6 next ones with the same lot1. On
the second workorder, the suggested quantity is 4 and not 10.
This issue is due to the fact that we fill the next workorder quantity
only at the first production batch and we don't check that the same lot
can be used again.
This commit call the mathod to update the quantity on the next workorder
if the first lot is produced again.
closesodoo/odoo#41189
Opw: 2127665
X-original-commit: e15fc6ac994edabc8907c13295c883cff9320d10
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create a picking type with specific default locations, for type
Manufacturing
- Go to Inventory, click on the 'To Process' button
- Create a MO
The default locations are not taken into account.
This is because the default picking type is not in the context.
opw-2128182
closesodoo/odoo#41049
X-original-commit: 6f7cbedd0ad252352209391501ba8971f7e90d00
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
-previously, in the mobile view, while accessing Manufacturing
orders from the dashboard in inventory, the default view was
set to tree. changed it to be kanban instead.
-Same in case user tries to access WO from dashboard when there
are none and user is redirected to MO.
Task-2127508
closesodoo/odoo#40857
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Updating the quantity to produce in a production order will recompute
each raw move's unit factor. The issue was this computation did not
take care of the previously product quantity. The unit factor was wrong
and so the next created workorder lines get the wrong quantity.
Example:
- 1 components for 1 finished product (unit_factor = 1)
- Create a production for 2 finished product -> quantity to consume = 2
- Produce 1 then change quantity to produce to 3 -> quantity to consume = 3
and quantity done = 1 but unit factor became 1.5
closesodoo/odoo#40990
X-original-commit: 79976600df45afc6150150734eef405fd41a70a3
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit disables quick create in calendar view for
`mrp.production`, because it uses name field for storing
`ir.sequence` and calendar quick create also uses `name` field to
create quick create record.
So in this case, even if user enters summary field, it will be replaced by
`ir.sequence`, thus quick create doesn't make sense here.
Task-2052536
If a component is used in a production with another unit of measure
than it's one, the created stock move line could not convert the quantity
correctly.
If there is enough quantity in stock, the created move line takes the
quant uom but the quantity in the production ones.
ex: consume 1 dozen, the quantity on the stock move line is 1 unit
This commit always uses the wo line's UoM and quantity to create the
stock move line.
closesodoo/odoo#39222
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue: open a done production. Unlock it. Add a new raw stock move.
This action will called _compute_order_finished_lot_ids on the new
stock_move. This method uses
move.raw_material_production_id.move_finished_ids.
raw_material_production_id is available but not move_finished_ids. The
reason is move_finished_id is not loaded by the web client in the
production form view.
This commit added the one2many (invisible) in the view in order to
get all the information in the compute method.
Rémy Voet (ryv)