Before this commit, if any workorder is stared to produce, qty
producing was 0. After this commit, if product tracking is none
then system will suggest the remaining qty of workorder to produce
when user is start it.
TaskId - 2480775
closesodoo/odoo#70207
X-original-commit: 5bbc234d43a415be18fcfa42dad33b1577644719
Related: odoo/enterprise#18086
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Considering the MO under consumption situation:
component A, to consume = 2, consumed = 1
Previous, after "mark as done", the MO will have two lines:
component A, to consume = 1, consumed = 1, state done
component A, to consume = 0, consumed = 0, state done
Now, after "mark as done", it will be consistent with picking:
component A, to consume = 1, consumed = 1, state "done"
component A, to consume = 1, consumed = 0, state "concel"
Task 2446915
PR #66583
ENT PR odoo/enterprise#16554
This commit is a revert of revert 561b3461a0
and 97ba860fd38c530d3f3678f676754862afad0f11.
Previously we split moves when no picking, now we consider it
unnecessary.
Task 2446915
COM PR #66583
ENT PR odoo/enterprise#16554
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Generic operations will be applied for every manufactured product passing
through the work center.
An operation linked to a bom will only be applied when the specific manufactured bom is produced
So on a BOM, every operations must be created for this specific BOM
The widget many2many is wrong because it will overwrite the generic operations
opw:2458974
closesodoo/odoo#66888
X-original-commit: a430c06ec6ec286a2d9ef55de6eebec60feeae3f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Go to an existing BOM B
- Edit B and try to add an existing operation O in operations tab
Bug:
It was impossible to add an existing operation
opw:2458974
closesodoo/odoo#66712
X-original-commit: ffab43fbf54b2f914b34c18da2391f3a18b3326c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Add and improve onchange warnings when a duplicate SN is used in
following cases: inventory, picking (any type), manufacturing, scrap,
and "Update Quantity" (i.e. directly edit quants from product form).
Improvement includes:
- include location where the existing SN is
- auto-correct source location when appropriate (e.g. trying to scrap a
SN in the wrong location)
The goal of this is to prevent but not restrict duplicate SNs so users
can have some flexibility (especially if a dupe SN occurs because of an
error such as doing pick-pack-ship out of order.)
closesodoo/odoo#61287
Task: 1924758
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replenishment is great to replace MTO but misses the direct link between SO and PO (smart buttons on both SO and PO to link to the corresponding PO and SO).
The info is actually there in the forecasted report but it is not accessible directly from the PO and in the case of the SO does not highlight the corresponding line of the SO.
This adds a graph icon in the PO, MO and receipt form to directly access the forecasted report (it already exists for SO and delivery).
The information linked to the SO/PO/MO/receipt/delivery is also sent to the forecasted report to highlight the corresponding line.
Note that in the case of the SO, the information needs to go first through the qty_at_date widget (which contains the link to the forecast report).
The graph icon for the PO, receipts and MO turns red when the forecasted quantity at expected date is negative. This is done using the new 'forecasted_issue' field.
closesodoo/odoo#62264
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When `qty_available` was being called
for a kit and its components at the same time,
e.g.:
- Kit product
- Product 1
- Product 2
The kit product available qty was always computed to `0.0`,
because when computing its component available quantity,
they were computed to `0.0` because they were marked
as `protected` by the ORM when calling the compute method
for these records at the first call.
When the `qty_available` compute method for the kit
then called recursively the `qty_available` compute
method for the component, as the component record
were marked as protected,
the ORM filled their value with the Falsy value `0.0`.
This issue occured particularly in the upgrade integrity unit test
which makes sure the available quantities of the products remain
unchanged after upgrade. This test computes the available
quantities for a bunch of products at the same time,
and its therefore likely a kit product gets its available
quantity computed as the same time than its components.
upg-3185
upg-4215
upg-4228
upg-5558
upg-5745
upg-5856
upg-6012
upg-6064
upg-6076
upg-6306
upg-6514
upg-6588
upg-6729
closesodoo/odoo#65758
X-original-commit: 8e152a567a6003dae4abb3b537b963eec4142d6d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
- make `bom_id` required. No sense to have a operation without BoM
- `company_id` of operation is now related
- Clean the multiple `allowed_operation_ids` into related
fields instead.
task-2373638
In order to have always a picking_type_id on a stock move (and
consistent with his parent model), make it compute store.
Then clean the call of picking_type_id without change the behavior
(/!\ `move.picking_id.picking_type_id != move.picking_type_id` because
of mrp). Fix some test where the location(_dest) was unset in moves.
Also:
- Clean the mess in the create of `stock.picking` about that
and add a onchange to keep location(_dest) consistent with moves.
- The move `description_picking` is set when the `picking_type_id`
change, not only at the create method.
task-2373638
Behavior prior to this commit:
- normally when editing the Scheduled Date on a MO, the date on the
related stock moves is updated. However this does not happen once the
MO is planned
- if the date is edited and the MO is planned, the MO is automatically
unplanned, but the date on the stock moves is not automatically updated
Behavior after this commit:
- when the date is updated on the MO and it is planned, the dates on the
stock moves will automatically update, so that the behavior is
consistent with how it would work if you clicked Unplan first then
updated the date.
Note:
- this commit is forward ported from 14.0. Only the unit test was
ported, as the behavior had already been modified to match the
expectation.
opw-2417108
closesodoo/odoo#64006
X-original-commit: 97f79960dbb3aa371378f576cfdce9670ca8ccce
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
Behavior prior to this commit:
- when the warehouse uses a 3-step manufacturing process, if I create a
Sales Order, the MO generated does not show the SO# as "Source", instead
it shows the MO#
Behavior after this commit:
- the MO source shows the SO# (similar to how it works when using the
2-step or the 1-step manufacturing process)
- the origins are assigned thus:
- Delivery Picking = SO name
- Post-prod Picking = SO name
- MO = SO name
- Pre-prod Picking = MO name
Note:
- there is no implementation change in this commit - we just ported the
test from the original commit in 13.0 (the behavior in 14.0 was already
OK)
opw-2380717
closesodoo/odoo#62512
X-original-commit: 0281dee6da75e68403772ebd368d57c1feb98c37
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add 2 warnings on Units of Measure and Decimal Accuracy.
Therefore, users are warned when their UOM/decimal changes can
cause inconsistencies in quants reservation.
Also, we want to prevent the issue at the root by ensuring that both the move
and the quant have the same reserved quantity.
The contrary can happen e.g. when a product is defined in Liters (rounding .001)
but used in an operation in ml (rounding .01, so e.g. 187.5ml).
The conversions between the 2 UOM can cause the differences of reservations.
In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom
is not more precise than the overall Decimal Accuracy. That way, if
the reserved quantity changes between UOM conversions, the move line created
is in the quant/product UOM, and we do not have move line's reserved quantity >
quantity in stock.
We do the same for _update_reserved_quantity (stock.move), when updating
a move line.
In _update_move_lines, because of UOM conversions, new_quantity_done
can differ from ml.product_uom_qty, which triggers the creation of an extra
move line, leading to reserved quantity > quantity in stock. To prevent
that, we compare the reserved quantities in the product UOM.
opw 2206902 (Example 1)
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
closesodoo/odoo#62279
X-original-commit: 478a42beb5876171afeab7df27fa69548edbf849
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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>
Pratima Gupta