Suppose a tracked-by-usn and consumed product returns in the stock
thanks to a repair order. Using again this component in a new
manufacturing order will raise an error
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two products P_finished, P_compo
- Storable
- P_comp tracked by USN
3. Update the quantity of P_compo:
- WH/Stock: 1 x Lot01
4. Create a manufacturing order MO:
- Product: P_finished
- Components:
- 1 x P_compo
5. Confirm, Check availability and Mark MO as Done
- (Lot01 should be consumed)
6. Create a repair order RO:
- Product: P_finished
- Parts:
- Type: Remove
- Product: P_compo
- Lot: Lot01
- Destination Location: WH/Stock
7. Confirm RO, Start RO, End RO
- (There should be one Lot01 available in stock)
8. Repeat 4-5
Error: When checking the availability on the MO, Lot01 is correctly
reserved. However, when marking the second MO as done, a User Error is
displayed: "The serial number Lot01 used for component P_compo has
already been consumed" although this lot should be available
When checking the uniqueness of the lot, nothing includes the products
back in stock thanks to the repair orders.
OPW-2701668
closesodoo/odoo#82544
X-original-commit: 3d9355f90fa1dd9436f1745c515c89947ed04de0
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Unlinking a workorder which was in the middle of a chain of workorder created two subchains which both created a product when reaching their new respective ends.
The issue was solve by assuring that when we a link is remove from a workorder chain, their adjacent workorders are linked together using next_workorder_id
opw-2669514
closesodoo/odoo#82553
X-original-commit: a826608044f2a0b50c2ad9ed0228717f9ec66522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Step to reproduce:
- Inventory > Configuration > Operations Types > Manufacturing (or any other operation type with code 'mrp_operation')
- Change 'Type of Operation' to 'Receipt' (or any other but 'manufacturing')
- Uncheck box field 'Use Existing Lots/Serial Numbers'
- Change 'Type of Operation' back to 'Manufacturing'
- Set correct value for 'Default Source Location' (type Receipt changed the value to 'Vendor', need to fix it)
- Create a storable product with the route 'Manufacture' selected.
- Create a BoM for this product, with a component tracked by lot (Add quantity to component)
- Create a MO for the product > Confirm > Check Availability
Current Behaviour :
Quantity are reserved, but the lot_ids are not visible
The behaviour is due to the fact that hidden parameters still have effect when they should act as their default value. To ensure it's the case, they are set back to their original value when the user switch between configuration to avoid ending in a wrongful configuration.
Behaviour after PR :
Lot ids are shown no matter the hidden configuration of picking type
opw-2680370
closesodoo/odoo#82377
X-original-commit: 22bbf43eba0927bdf27218da16f8435b33756112
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Mass produce originally prohibited multiple lots components.
Later commit removed this limitation (among others).
This one displays a warning to make sure it is intentional.
task 2633369
closesodoo/odoo#77254
Related: odoo/enterprise#22797
Signed-off-by: Arnold Moyaux <arm@odoo.com>
There is 2 major issues with the production of multiple serials number
- Performance issue
- Duplicated code with classic backorder mechanism
The performance issues exist since backorders were create one by one
and `stock.move` and `stock.move.line` are always recomputed. They
are not created in batch neither.
_generate_backorders is removed and replace by _split_productions. The
functionality are the same. Technicaly it does the maximum in batch,
first it creates all the `mrp.production` then all the `stock.move`
and finaly, it splits the existing `stock.move.line` among the new
`stock.move`
It means that the reservation is not recompute anymore during a
backorder process and will remain the same than the splitted production
order.
Performance metrics (10 components):
| 2 | 10 100 1000
before | 0.47s | 2.84s | 32.25s | 580.53s
-----------------------------------------------
after | 0.13s | 0.36s | 2.60s | 35.17s
task 2633369
Part-of: odoo/odoo#77254
Fixes 2 issues:
Issue 1: wrong view shown when registering strict consumption
To reproduce:
- create tracked product to subcontract
- create subcontract BoM with no tracked components + strict consumption
- create receipt of subcontracted product (remember to select From =
subcontractor)
- click on `action_show_details` burger button in Operations
Expected result:
- Detailed Operations window with no move lines in it (i.e.
stock.view_stock_move_nosuggest_operations view)
Actual Result:
- Detailed Operations window with move lines w/ 0 Done
(i.e. stock.view_stock_move_operations view _ lines also do
not get filled in when using the `action_assign_serial_show_details`,
=> twice as many lines as needed end up in view)i
Similar issue can occur when using a non-strict BoM + tracked product.
Issue appears to be that conditional was incorrectly updated during
refactoring to allow non-strict BoMs also record components.
stock.view_stock_move_operations view should only appear when all
productions are recorded
Issue 2: Consumption warning wizard not showing correctly
To reproduce:
- same as Issue 1, except consume less than BoM amount
Expected result: Consumption Wizard
Actual Result: stock move view shown instead
Issue was due to 'form_view_ref' value in context of picking view,
therefore we force clear this value everytime we expect this wizard
to open.
Task: 2695173
X-original-commit: b9990a5dab8731a8f69fd07aa73a318fc9d4a808
Part-of: odoo/odoo#81649
This commit adds an index on picking_type_id for models stock.picking
and mrp.production.
Filtering on picking_type_id is often done via the Inventory Overview.
This should speed up the list render in case of many object.
Task : 2648449
closesodoo/odoo#80434
Related: odoo/upgrade#3068
Related: odoo/enterprise#22535
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Previously, when underconsumption occured, we split the move (in
post_inventory). And if backorder, the moves not done would be linked to
the new backorder MO (when backorder MO is created).
After 8883c06ada, we create backorder MOs
before _post_inventory, making it so the moves not done will not be
linked to the backorder MOs and reserved qtys are not released.
To fix, we set cancel_backorder to be true to cancel all the leftover
moves and release the reserved qty.
Task-2697611
closesodoo/odoo#80446
X-original-commit: cffb2b455d73f64d96f91b9e0301c346989eae63
Signed-off-by: Tiffany Chang <tic@odoo.com>
When cancelling a manufacturing order that does not include any
component, the associated moves won't be cancelled.
To reproduce the issue:
1. Create a storable product P
2. Create & Confirm a MO for 1 x P
3. Cancel the MO
4. Consult the form page of P
Error: The forecasted quantity of P is 1 instead of 0
The finished move associated to the MO hasn't been cancelled. Since [1],
we have the possibility to process MOs without any component, so the
cancellation process shouldn't be bypassed anymore.
[1] bf5e1debf9
OPW-2691422
closesodoo/odoo#80407
X-original-commit: 2adff866a598fc8fb872fb8127875fbb7cc7335c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Fixes 2 issues:
1 - odoo/odoo#61027 made mrp.routing.workcenter.company_id =
self.bom_id.company_id. This made it so the work center selection is
empty until a BoM is selected, which is confusing to users. To make it
less confusing, we switch the order since we expect users to fill in
the fields from top to bottom.
2 - odoo/odoo#65628 made it so the BoM can be changed. This made it so
it's possible to save the record and have the company of the BoM and
the work center not match. This can lead to a usererror when users try
to start the WO associated with the operation. Steps to reproduce:
- create a new operation from Configuration > Operations
- select a BoM from company 1 and a Work Center from company 1 + save
- edit and change BoM to a BoM from company 2 and DO NOT change the
Work Center
Expected result: save error
Actual result: Save will be allowed, but WO will throw an usererror
when you try to start it.
To fix this, we prevent the user from saving when the workcenter
company does not match the BoM's (if both have a company_id assigned).
closesodoo/odoo#80337
Task: 2682365
X-original-commit: f77c9560ad304940610d797018246a8f5d32f721
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
In multi steps configurations, the additional products of a MO could be
missing in the associated picking
To reproduce the issue:
(Use demo data)
1. In Settings, enable "Multi-Step Routes"
2. Update the current warehouse:
- Manufacture: 2 steps
3. Create a MO for product "Table Top"
4. Edit the MO:
- Add 1 x Screw in the components
5. Confirm the MO
6. Open the generated Picking
Error: The operations only contains one line for "Wood Panel". There
should be a second line for the "Screw"
When adding the new component, a new stock move is created but the
latter does not have any `group_id` defined. This is the reason why the
generated picking does not include this stock move.
OPW-2671995
closesodoo/odoo#79894
X-original-commit: 720f29fc6b7626ae734187242870a27065441ac2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
stock.orderpoint._post_process_scheduler confirms
productions after procurements have been run.
This was introduced to avoid conflict between
procurements, conflicts that can happen e.g. in
the purchase_mrp module.
However, currently action_confirm might
also be called on done or cancelled productions.
That can happen if there are already been lots
of procurements for the same product/orderpoint,
i.e. MO with the same values have been created multiple times.
To avoid this, add ('state', '=', 'draft' in the search_domain.
opw-2666960
closesodoo/odoo#79437
X-original-commit: 11c7b92f90804a4d73833e22c071e1665058fbdb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Current Behaviour :
When mass producing with SN, the default number of SN to generate is set to 0.
Behaviour after the PR :
When mass producing with SN, the default number of SN to generate is the number of item to produce.
opw-2680306
closesodoo/odoo#79431
X-original-commit: 38e5d002acc2e516987acc0afe38648473fff708
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
The component status of a MO is not correctly computed
To reproduce the issue:
(Use demo data)
1. Create and confirm a MO for 1 x [FURN_9666] Table
2. Unlock and edit the target of To Consume Qty:
- For [FURN_8522] Table Top: 0.1
- For [FURN_2333] Table Leg: 0.1
Error: The Component Status of the MO becomes "Available" while Table
Top and Table Leg are not available.
Due to the signature of `float_compare`:
https://github.com/odoo/odoo/blob/56f8c1c0487bf95325ca859e2f266d1beed28ad4/odoo/tools/float_utils.py#L127
`move.product_id.uom_id.rounding` is implicitly given to
`precision_digits`, which is incorrect.
OPW-2669931
closesodoo/odoo#79362
X-original-commit: c7077dedd63ad317517ad383855821e6570b963d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- install mrp_workorder
- Create a new work center which will work every day from 8:00-9:00
- Create a BOM with component and operation, which takes 24 minutes in your work center
- Create 4 MO for this bom
- Set manually scheduled date > 1 MO should have a different date than others, e.g:
- 3 MO → 01/dec/2021 08:00
- 1 MO → 02/dec/2021 08:00
- Plan the MO which has different date than others
The ```planned_end_date``` is not calculated correctly
Current behavior before PR:
MO_1 : 01/dec/2021 08:00 → 01/dec/2021 08:24
MO_2 : 01/dec/2021 08:24 → 01/dec/2021 08:48
MO_3 : 02/dec/2021 08:00 → 02/dec/2021 08:24
MO_4 : 02/dec/2021 08:24 → 02/dec/2021 08:24
Problem
The MO_4 should only last 20 minutes, while it lasts 23 hours and 48 minutes.
opw-2648065
closesodoo/odoo#79184
X-original-commit: b02cdbbe36ead262331fc74ec3039c8ded313d3d
Related: odoo/enterprise#21992
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
If a work center is used in any routing, a warning will be displayed when it will be archived
opw-2658596
closesodoo/odoo#79185
X-original-commit: a05f4e05b9f4df88948ac3dfc1522828b63bfb64
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce:
1. Create Manufacturing Order with quantity >1 of Serial Tracked product
2. Press Mark done. (One Product will be immediated produced with a new
SN auto-created)
3. Create Backorder
4. Press Mark done on the backorder
Expected Result:
Backorder will also be able to immediate produce and auto-create a new SN
Actual Result:
Usererror because env is still referring to original MO and tries to
produce the same SN again.
closesodoo/odoo#79151Fixes: odoo/odoo#78134
X-original-commit: 58cd10eb7277312d7d6c5e9da7b52dcbdb114734
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
"Material Availability" vs "Component Availability" label means
the same thing but it shouldn't.
- Rename these and add a help string for both fields.
- Change decoration to be green if the MO Readiness is
'ready'.
- The logic of `_compute_*_availability` doesn't take in account the
'ready' `(reservation_)state` to distinct clearly both fields
(`(reservation)_state` vs `*_availability`)
task-2668922
closesodoo/odoo#79033
X-original-commit: acc385137a6a59f3632d91a7fcabd5ab42e8bc7f
Signed-off-by: Tiffany Chang <tic@odoo.com>
The recomputation of stock move state is often done with already
the correct state (for instance in the case of move line deletion only
one of the deletion will change the state).
This commit check the move state before changing it only when it's
necessary.
Task: 2507143
X-original-commit: 80033446a091ff3ba98c58ba44ad665bfba30c98
Part-of: odoo/odoo#78547
Co-authored-by: Remy Voet <ryv@odoo.com>
Issue: When replacing a tracked part while doing a repair, we
are changing the tracking number, but when checking for uniqueness,
we don't take that change into consideration
Steps to reproduce :
1) Manufacture product A with SN "A1" out of product B with SN "B2"
2) Make Repair Order for "A1" to replace "B2" with Product B (SN "B1").
3) Create Manufacturing Order product A (A2), select product B with SN
"B2" as one of the components.
4) Mark as done
-> Bug : "The serial number <B2> used for component <B> has already
been consumed".
Why is that a bug:
When checking for uniqueness we should take into consideration the
parts being replaced
opw-2625687
closesodoo/odoo#78407
X-original-commit: 79c673f9d15185be540dd535d7ebe10c8f138bf1
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
- Set the Decimal Accuracy at 5 digits for Product UoM
- Create a product X
- Create a kit BOM for X with a component Y, and qty 0.08600
- Create a Sale Order for 10 product X, confirm and deliver all
Issue
- On the SO, quantity delevered is 9.00000 instead of 10.00000, same
issue occur with the same flow with a Purchase Order.
Cause
As the quantity per kit was rounded when calling _compute_qty,
the calcul of quantity ratio was not well computed.
Solution
Avoid rounding the quantity per kit, as the quantity ratio is rounded
a few steps after.
opw-2590126
closesodoo/odoo#78516
X-original-commit: 2a2b198ea6ce1d0553c606404e6db1117dc1c4a2
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
The generate serial number button uses the stock.lot.serial sequence by default
(default value for name of stock.production.lot)
Serial Mass Produce (and other parts) allow to generate serial numbers
starting from a user supplied initial value.
This fix makes the button generate the next serial number
according to the last generated.
task 2647238
closesodoo/odoo#78258
X-original-commit: b80259dff3aaafb9d11af9d936f5106bdf5ed781
Related: odoo/enterprise#21641
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Jean-François Aubert <ajf-odoo@users.noreply.github.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
In PR: #74540 the MO.date_planned_start default was updated to
round up to the next hour. It was later decided this would be too
confusing so this commit reverts it back to the original default of now
(i.e. without any hour rounding)
closesodoo/odoo#77956
X-original-commit: 44c66cce8e545afd7b38c7fc81425fa69023798e
Related: odoo/enterprise#21506
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
- update MO list status colors: draft = blue, in progress = yellow +
make the WO status colors match (waiting = blue, in progress = yellow)
and make draft MO lines all blue (to follow current design standard)
- cleanup Activity in tree view (no label in tree + "Next Activity" in
column selection dropdown)
- make units of analytic accounting for WO = hours
- make quantity for move_raw_ids products (i.e. components for MOs)
always have positive analytic_account_line.unit_amount (i.e. when
changing a done move's quantity + changing a quantity twice made this
value negative)
- make "Copy Operations" on BOM open the list view in "current" instead
of "new" due to lack of hook to prevent form view (i.e. open BoM in
current view) changing when clicking on lines in the new window's
operations (also ends up being a better UX anyways since being able to
view the operations form view is desired).
Task: 2648460
X-original-commit: 65a2d478197f5b856212225319500ca61b161809
Part-of: odoo/odoo#77897
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
Improve 'Component Availability' and 'Product Availability':
Add these fields in form and tree view (the performance issues
is addressed in next commits and these fields will be load lazily)
task-2579011
Part-of: odoo/odoo#77092
The `_compute_json_popover` of (`mrp.production`)
was slowing down the tree view of MO (because it loaded
every move due to `production.move_raw_ids` even if there
isn't `delay_alert_date`.
Make it more lazier: we gain a speed up
when the there aren't any delay_alert_date
(always when the setup is simple)
To read 150 MO (7500 moves behind):
Before: 0.099 ± 0.002 SQL sec, 0.224 ± 0.005 Python sec (37 SQL requests)
After: 0.060 ± 0.0008 SQL sec, 0.096 ± 0.002 Python sec (29 SQL requests)
Also, unify the code with `stock.picking`.
task-2579011
Part-of: odoo/odoo#77092
This commit removes the action_confirm from the run_manufacture to do it
only after all the orderpoints have been processed.
In case a production, created in run_manufacture, triggers procurements
for one of its component. And those procurements have the same
parameters than another one still not run because after the manufacture
one in the queue. This new procurement will replenish its quantity plus
the other procurement's one.
That means too much quantity will be replenished.
closesodoo/odoo#77026
X-original-commit: a7bb9f1ac392c00be5bdd133fc5c73b9803c8b4b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Issue: The button # To Process in mrp/views/stock_picking_views.xml
at line 33 uses the domain state confirmed, draft, planned, or progress
But the default filter, which is called "to do", show those 4 states +
to_close (in mrp/views/mrp_production_views.xml line 309)
Side-Note: Issue also present in 14.0, so starting the bug fix from
here. 12.0 doesn't seem to have a to_close state but the count and
filter domain also do not match
Steps to reproduce in 14.0
On Runbot, go to Inventory click on the "# to process" button on a
Manufacturing card.
- Choose any MO and create a work order. On this work order, click
"Start", then "Done".
- The MO is now in the "To Close" stage.
- Go back to Inventory Overview. The number to process has gone down by
one.
- Click on the "# to process" button, you will see that the "To Close"
MO appears in the list but is not counted by the button.
(written by dido)
For 13.0 I haven't been able to find steps to reproduce but the button
has not changed between the two versions
opw-2636447
closesodoo/odoo#76834
X-original-commit: 7f3b65bb42444ccb02bfb80931b52a94924fcdb0
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Byproduct moves with same cost_share can be merge but only if there is
no other move with different cost_share in the list of move. This commit
allow merge move with same cost_share in any cases.
closesodoo/odoo#76709
X-original-commit: 41bd26f6522cf9f4e11962399504030c36512c39
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Component move with same product are not merge at confirmation as it
could be multiple different production steps.
opw-2583848
closesodoo/odoo#76401
X-original-commit: 390fce62462962e9a0131a082317e2e60e34041a
Related: odoo/enterprise#20801
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Commit 04f3cac527 makes picking_type_id compute on stock_move_line to
get the picking type of either the picking or the manufacturing order.
Right after, commit dd53f5323f set picking_type_id related of the
picking one to be able to search on it. (in this later scope,
manufacturing part was not needed, hence the related instead of compute.
This commit mix the two idea by having a new search function on the
computed fields to filter stock move line depending on their picking
type.
X-original-commit: d535108f96d62f217dda7cbb676f9d60b7477f4f
Part-of: odoo/odoo#76294
no need to make rounding during computing qty_available
STEPS (see the test):
* create product with uom dozens
* create product with uom units
* create bom kit to convert one to another
* set qty on hand to 1 for product dozens
* check qty for product units
BEFORE: qty=11
AFTER: qty=12
---
opw-2632782
closesodoo/odoo#76242
X-original-commit: 26b28408d8970baa8cbf59ffaff90cab1e579410
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.
opw-2637321
closesodoo/odoo#76116
X-original-commit: 864d90a064f093bd6ba24d8464ee491a443a320e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Issue: When creating a manufacturing order and setting a scheduled date
when no workcenter is set, a traceback shows up
Steps to reproduce :
1) Install Manufacturing
2) Enable work centers
3) Create a manufacturing order, in the work order tab, add a new line
and set a Scheduled Start Date, confirm the date
-> Traceback
opw-2633940
closesodoo/odoo#76117
X-original-commit: ebf54c802664e6c2143785b950667c136944fcbf
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
In case a production order loses its procurement group. The backorder
generation process do not have access to the last backorder sequence
used. This commit set a default value to avoid any traceback.
The new backorder name will not be guaranteed exact related to the
production sequence but will be unique in any cases.
closesodoo/odoo#76091
X-original-commit: aae07e88a8166cf26a8c81bb8ee37d630fd6672c
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Since return moves are linked to their original move, it's easy to
manage reservation in those case. We just don't bypass the reservation
when it comes from a reservation outside our stock in order to manage
the computation on linked moves and reserve pieces that were not yet
return.
Also add a return picking type for 2 reasons:
- Allow to select existing lot.
- Display reserved move line for an incoming picking.
Note that this picking type is just a default configuration and could be
modify by the user without any issue.
closesodoo/odoo#64384
Related: odoo/enterprise#20605
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a product's has a kits bom, we consider it a kits product.
When a product is a kits product, we count its "on hand" and "forecast"
qty by caculating how many can be produced according to the bom.
We add status button to the show the qty on kit product form.
Task-2444000
COM PR odoo/odoo#75555
ENT PR odoo/enterprise#20440
UPG PR odoo/upgrade#2783
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When recieving a kits product, it will be decomponent in the picking. In
this commit, we add a column in the picking to show the info of the kits
in picking.
Task-2444000
COM PR odoo/odoo#75555
ENT PR odoo/enterprise#20440
UPG PR odoo/upgrade#2783
Allow to produce several serial numbers at once.
Only when BoM do not contain any component tracked by unique serial number
and lot ones are from 1 lot.
Also allow to copy/paste serial numbers.
This applies to manufacturing orders.
Task: 2444742
Part-of: odoo/odoo#71732
Adrien Widart