Current behavior before PR:
It is possible to create a BOM that has a BOM line that reference the
same product as the BOM itself. This is undesirable as when we create a
manufacturing order for this product we will have an error.
It is a regression bug that was introduced in commit
575353e251a0cce3bbff759edaeb56b5718beb11 between v12 and v13.
Behavior after PR is merged:
When saving a BOM it will validate that no product line references the
same product, or the same product variant, as the BOM itself. Note that
it is allowed to have a BOM for a product variant that references
another variant of the same product.
opw-2347941
closesodoo/odoo#59633
X-original-commit: 917e4c67b4aa14ca71ec6cba4bc6d20a86459f42
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit makes sure we do not try to update the quantity on a
finished stock move (during record production or confirming the produce
wizard) if there is no finished move available.
Closes#57227closesodoo/odoo#59430
X-original-commit: 141df3b398aee2bac10e3ce94e15bb4bd14d17af
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit does 3 things:
1. When 'action_confirm' is triggered in a manufacturing order, any
'move_raw_ids' (components) that are unable to be fully reserved
when `action_assign` is triggered will be checked for an automatic
reordering rule (RR). If a rule exists it will be auto-triggered.
This includes subcontractor manufacturing orders. Relevant test
updated to match this.
2. When a MO is completed, auto check if there are corresponding
confirmed stock moves that can be populated by the completed products
and trigger their 'action_assign' to reserve the completed products.
3. If a new move line is added to an already confirmed MO, then do same
auto-RR check/trigger. (note will occur for pickings without extra
code since `stock_picking.action_confirm` is triggered again in this
case.)
This reuses similar logic as odoo/odoo#52433 from task 2244230.
Originally this was done in the `action_assign`, but has been moved to
`action_confirm` so as to imitate the now archived MTO process with RR.
Overlapping logic has been moved into stock_move for easier reusability.
Note that this now means editing existing moves' `product_uom_qty` (i.e.
Demand) will not have a flow to auto-trigger their RR.
Subcontracting test updated to match + new mrp test added for this new
feature.
closesodoo/odoo#57334
Task: 2322496
X-original-commit: 2688cd1bae489b1dec8862f4de727ac20514844c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In case of manufacturing a product tracked by serial number,
there is no reason to be able to make it with a different UoM of
the product (which lead to rouding issue).
Then when we confirm the MO in this case, the UoM and quantity
will be converted to product UoM.
PR #56000closesodoo/odoo#57333
X-original-commit: f0da27e7eb474e6db4cd999306c420804aaa6f9b
Related: odoo/enterprise#13059
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
Allow to add serial numbers as tags on the move in production order and
stock picking. The purpose is to earn time for database with
only tracking installed.
Also when only create_lots is checked on picking type. New lots
could select existing lot and an onchange trigger a warning if
it's used.
closesodoo/odoo#55883
Task: 2280985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
Updating the quantity to produce on a production order will recompute
the expected production duration. This can be counter productive on
prototyping production when no BoM are given. The default expected batch
duration is set to 60 minutes. Setting the actual production time then
updating the quantity to produce will naively change the duration to
60 x the new quantity.
This commit compute the duration pro rata in case of 'no BoM' production
and recompute everything in case of BoM production.
Task : 2278147
Before this commit, only the moves raw were copied on production
duplication. As the finished move is created normally in an onchange,
this means a production order duplicated have not any move finished.
Task : 2278147
Changing the Bom on a production order will erase all the raw moves to
recreate the new ones. This commit make sure the finished product are
erased as well.
Before this commit, if the product was changed with the BoM. The first
finished product became a byproduct for the second one.
Task : 2278147
In a scenario parent mo <-> child mo, delaying the production start on
the child mo will delay the parent start but not the parent's workorders
This commit will replan the workorders each time a planned production is
delayed.
Task : 2278147
This commit introduce the immediate production mechanism. As it works on
stock.picking, marking a (some) production(s) as done without consuming
anything will pop a wizard allowing the user to transfer all the reserve
component quantities as done quantities.
Task : 2278147
Improve onboarding by removing the replenish on order route.
Companies that do MTO process could unarchive the route in
order to have a basic configuration.
closesodoo/odoo#55147
Task: 2245882
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Adding additional product to a production but consuming 0 on it will
trigger the consumption warning wizard while no difference with the bom
are occurring. This commit do not trigger the consumption issue in that
case.
Task : 2278147
closesodoo/odoo#54561
Related: odoo/enterprise#11885
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Bunch of last minute fixes including:
- serial handling in tablet view
- expected durations and backorders
- button unplan unlinks the leave but the computed aren't recomputed
then we need to manually set the date_planned_start/finished
then we need to not propagate them on the related document
(move/production) because they are required
- operation company_id wrongly set
task-2241471
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
- The Scheduled Date can't be change if the MO have some planned WO.
(WO defines the scheduled date of the MO)
- Now the Scheduled Date 'date_planned_start' is set by default
with the deadline date if there is or now if there isn't (same than before).
- For MO, 'plan_date_finished' is now invisible. But keep the field
because it is used to set the date_expected of finished moves.
- Change the plan behaviour: Plan depending of the scheduled date if
this one is bigger than now, else try to plan as soon as possible.
task-2241471
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- create product comp1
- create product finished1
- created bom: 1 comp1 for 1 finished1
- activate PBM
- 100 units of comp1 in stock
- create an MO for 5
- on the pbm, deliver 3 and no backorder
- on the mo, check availability, produce 3
- on the pbm, unlock, change delivered qty from 3 to 5
On the mo, the raw move is reserved to 5 units but the 3 units
used in the first produce are removed.
It happens because editing the quantity or initial on a move
will try to reserve the next moves. In order to reserved,
_do_unreserve will destroy the stock.move.line and _action_assign
(call just after) will recreate them in order to regenerate the
reservation. In the process the qty_done on the stock.move.line will
be loss. We want to avoid this behavior in mrp so we call
_decrease_reserved_quantity from mrp that will keep stock.move.line
with quantity done.
opw-2206472
closesodoo/odoo#47617
X-original-commit: c6cf5841015c87163f8ea16dd75232e5cb855df6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Commit c883ed1087 let the possibility to
add additional stock moves in a confirmed production. The issue is those
move don't get the production group and their procure method is set
(and never changed) to make_to_stock.
This commit call adjust_procure_method before confirming additional
moves.
closesodoo/odoo#45660
X-original-commit: 96cc10fa79a120172b3cde88d50ba2fda5e75ab5
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Let's say we have a chain of move
wh1 - intercomp transit -> intercomp transit - wh2
The second move will be reserved according to what the first move
brought since they are chained. This behavior resulted in rev[0] which
tries to work around the ir.rule limiting the access of stock.move and
stock.move.line records in multi-company environment.
This patch wasn't perfect since, if the first move brought a lot, the
second move will reserve this lot and it will result in another access
error since the lot will still have the company of the first move.
We fix this by implementing the following logic: receiving from another
company should behave the same as receiving from the supplier, no
reservation is applied. We fix this by marking the inter company transit
as `_should_bypass_reservation` and we break the move chain if the
pull/push rule create an intercompany chain.
[0] 6ff34073153767d449804669f31e26c04de0a670
closesodoo/odoo#45601
Task: 2160847
X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Set the following product configuration:
Storable finished product with a flexible BOM made of storable
components in manufacture + MTO:
Component choice 1 Quantity = 0
with BOM made of component 1, quantity 1 with purchase mto route
Component choice 2 Quantity = 0
with BOM made of component 2, quantity 1 with purchase mto route
Create a MO for finished product, set the "to consume" quantity of
"Component choice 1" to 1, and try to mark it as to do. The following
issue is raised: The quantity to produce must be positive!
This is because a procurement with 0 quantity will be solved in a MO
producing 0 quantity. We fix this issue by ignoring procurements with 0
quantities.
Also, this MO without initial demand is not considered assigned. We fix
this issue by considering 0 move as assigned.
task-2159374
closesodoo/odoo#45552
X-original-commit: dffb3a1f2762d6e1517eb9b7d225521f99d874d5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usecase to reproduce:
- Create a product MTO manufacture with a BoM
- Set produce delay as 1 day.
- Create a SO for the product and validate
The production order is created but with a duration of 1h.
It's due to commit 8944674d6d
It will use the moves finished date in order to determine the MO
finished date. However before this commit during _run_manufacture
the MO was created with a fix finished date and the move finished
date_expected was created with this date as date_expected.
Now the MO is created with the finished date, the inverse does
nothing since the finished moves do not exist yet.
In order to fix it, generate move_finished_ids use the product/company
manufacture delay. A first patch tried to rewrite date_planned_finished
after action_confirm. However it triggers the propagate date on
following moves.
closesodoo/odoo#44532
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit let the manufacturing user to add new components or update
the quantity to consume of existing ones in a manufacturing order even if
the state confirmed. The BoM should be in flexible consumption.
In case of reserved quantity, updating the quantity on a raw move will
unreserve it entirely. We apply the same logic than the stock.picking one
Task : 2121714
This commit adds the possibility to choose in which operation a new product
will be consumed. New product can be added to the production once the
manufacturing order is in state draft.
Before this commit, the new product was consumed
automatically in the last workorder.
Task: 2121714
In this commit:
- On done MO's form, add an Unbuild button, it would open a
wizard with the form view of an unbuild, and some pre-filled fields
such as MO, product, BOM, quantity and total quantity finished which
can be edited.
- In the unbuild order, improve the on_change of mo_id:
if the selected product is tracked by serial number,
set quantity to 1 by default and readonly
- Also clean the testcase of unbuild order.
task-2144636
closesodoo/odoo#43719
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: Ankita Raval <anr@odoo.com>
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>
- 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
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>
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>
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>
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>
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>
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>
_action_done() creates extra stock move when quantity_done is superior
to initial demand. This extra move should be, after confirmation, either
merge into the original stock_move, either stay extra but the move lines
still linked to the first one should be shared accordingly to the quantity
done. The fix 561b3461a0 adapted the code
for MRP to split the move lines but neither those cases are applied in
MRP because the extra move has no picking_id field.
condition :
```if merge_into_self and extra_move.picking_id:```
will therefore be false as well as
```if not merge_into_self:```
To be sure the two extra move management cases are complementary, this
Commit keeps make sure the conditions are mutualy exclusive.
closesodoo/odoo#40230
Opw: 2087864
X-original-commit: 4e8ac38a6d67bcd5040af0b580bfa43da7841548
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Planning the workorders depends on the quantity to produce of those workorder
This will create as much as production batch needed regarding the workcenter
capacity.
This method is good except in case of product tracked by serial number. In that
case the quantity to produce on the workorders is force to 1 regardless of
the quantity to produce on the production
closesodoo/odoo#40226
X-original-commit: 3c4133ddac256c63802a99461db49cc9bd9fa1d6
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Some tests (test_00_workorder_process, ...) are executed several times, only
because we extend a test class to retrieve the setUp (or setUpClass) instead
of creating a common class.
This could lead to issues, (like for test_00_workorder_process) depending on the
installed modules.
Nicolas Galler