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
Same issue as odoo/odoo#71068 but for subcontracting rather than a MO.
Steps to reproduce:
- create a subcontracted product w/tracked component
- create receipt with subcontracted product (don't forget to set
"Receive From" = subcontractor
- fill in Detailed Operations with tracked component lot/sn, but Done=0
- Try to record production
Expected Result: Subcontract production is done + window closes
Actual Result: nonsensical "The quantity to produce must be positive"
validation error
Discovered during task: 2695173
closesodoo/odoo#81649
X-original-commit: 646789811c1f874160318badfe8105d84057b8bd
Related: odoo/enterprise#22998
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Both mrp_subcontracting and a module in Enterprise both inherit
`mrp.mrp_production_form_view`. This was leading to a conflict where the
Enterprise view could overwrite the invisible=1 attribute added by
mrp_subcontracting, therefore we update the views to avoid this.
Part of Task: 2695173
ENT PR: odoo/enterprise#22637
X-original-commit: 6317c34808d381e54bae2431fec2de4b8503b447
Part-of: odoo/odoo#81649
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 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
stdout:
stderr:
13:41:03.985365 git.c:344 trace: built-in: git cherry-pick 20858c2a8805d9ec08edb98b090badf6c73fc342
error: Cherry-picking is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: cherry-pick failed
----------
status:
closesodoo/odoo#79933
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previous task: odoo/odoo#61287 improved warnings for when using a
duplicate SN, including an auto-update of the source location when
appropriate. Unfortunately the auto-update is too risky when registering
a subcontracting SN tracked components.
Instead, we no longer update the source location when in a
subcontracting situation and update the warning message to match the
expected flow to fix the issue.
closesodoo/odoo#79334
Task: 2669180
X-original-commit: a430c4d7d6e2a02ef9b3905b554a779fc1643bcf
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
In case you use products with variants or internal references, display_name is more specific than name.
closesodoo/odoo#79191
X-original-commit: c46328315a8db2f579329a8a44c23fd4769e7d44
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit fixes the 'You need to supply a Lot/Serial Number...' message
when validating a receipt with backorder for subcontracted tracked products.
closesodoo/odoo#79121
Task: 2604664
X-original-commit: 2ab8f5cc681d45323e540ca57f85168fd587cf02
Signed-off-by: Tiffany Chang <tic@odoo.com>
When validating a receipt, if the product is subcontracted and if the
picking is not fully done, it will be impossible to create a backorder
To reproduce the issue:
1. Create two products P_compo, P_finished
- Both storable
- Both tracked by lot
- P_compo must have the route "Resupply Subcontractor on Order"
2. Update P_compo's quantity: 4
3. Create a BoM:
- Product: P_finished
- BoM type: Subcontracting
- Subcontractors: a partner P
- Components: 1 x P_compo
4. In Inventory, create a planned transfer T:
- Operation Type: Receipt
- Receive From: P
- Operations: 4 x P_finished
5. Mark as Todo
6. Inventory > Delivery Orders, find the delivery of P_compo for P and
process it
7. Back to T, Record Components:
- Quantity: 3/4
- Set a Lot for P_finished
8. Validate T, Create Backorder
Error: a User Error is raised "You need to supply a Lot/Serial Number
for product: - P_finished"
Since P_finished is subcontracted, a related MO has been generated. On
step 7, when recording the used components, since all P_finished have
not been produced, a second MO is created for the last P_finished.
However, when validating T, both MOs are selected and validated. This is
an error since the user has not yet recorded the used components for the
last MO. The latter should not be validated.
OPW-2582538
closesodoo/odoo#78496
X-original-commit: 21068076b4a6b134f5f07c4c03de7c4eb37b4688
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In the bom cost report template, a "tr" is missing and no parent_id for
the subcontructing part. This result in a leftover line each time you
fold the bom. Add them to the tamplate.
Task-2657280
X-original-commit: 6ae623dc2d5131e2b11969f1bc1f8dd6096a9005
Part-of: odoo/odoo#77945
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>
Take in account the bom consumption of subcontracting BoM:
- In flexible and warning we can now record extra component
(even if there isn't tracked component).
- In the warning case, we get a warning issue in during the recording
of component if we consume more than expected
- In case of script consumption, we cannot record component expected
if some are tracked. In this case we can consume more than expected
only if the user is a mrp manager.
Also fix "Set quantities" Button for the subcontracting
task-2486811
closesodoo/odoo#75041
Related: odoo/enterprise#20350
Related: odoo/upgrade#2750
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The button "Set Quantity" have a different behavior
(it doesn't take in account tracked product) than
the immediate process which is confusing.
Now both flow share the same code and allow to avoid
the "Set Quantity" for the subcontracting with tracked component.
task-2486811
Part-of: odoo/odoo#75041
We cannot have byproduct in case of subcontracting,
raise a Error if we try (like operation). Also remove the
it from the subcontracted form (also clean empty space of it).
task-2486811
Part-of: odoo/odoo#75041
- The "BoM Structure & Cost" takes now in account
the subcontracting cost.
The subcontracting cost depends of the best supplier info in product
and subcontractor register in the BoM.
- Also add this subcontracting cost (to the cost field) when we click on
"Compute Price from BoM" in the product view.
task-2486811
Part-of: odoo/odoo#75041
Add a operation type (`stock.picking.type`) for
the subcontracting resupply in order to distinct
easily the a simple delivery and a resupply to a subcontractor.
task-2486811
Part-of: odoo/odoo#75041
Added 'Dropship Subcontractor on Order' route to simplify user interaction
and stay tuned with 'Resupply Subcontractor on Order'.
Task: 2444742
Part-of: odoo/odoo#71732
In subcontracting, there wasn't a way to make
the subcontracting resupply delivery plan before
the subcontracting receipt.
Now the hidden subcontracted MO, take in account
(in his planning) the `produce_delay` (in days) of
the product which is automatically plan the
subcontracting resupply delivery correctly.
task-2486811
closesodoo/odoo#75072
X-original-commit: 829369d3ca0530f1aad0599fbb1598810a928cc3
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
When setting a Bill or Material to subcontracting, the "Operations" tab
is hidden. But it still effect eg. BoM Structure & Cost report.
With this changeset, we get an error when we save a subcontracting BoM
that has operations.
opw-2513637
closesodoo/odoo#74441
X-original-commit: 41c7bd1461a5346a030ab194b5f7fafa87a4c45a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, for a subcontracted product with reserved available
tracked components, if at least one component is recorded but not all,
the "Record components" button isn't available anymore.
How to reproduce:
- Create a product and create a subcontracting BOM for this product;
- Add a tracked component for this product;
- Add some qty. for the tracked component in the subcontracting loc.;
- Create a receipt for the subcontracted product (for demand qty. more
than 1) with the subcontractor as partner and confirm it:
=> The "Record components" button should be visible.
- Record a part of the demand qty. then click on "Continue", then on
"Discard":
=> The "Record components" button is now hidden.
It's because the button is hidden if all the MO are done or to close
(they are) and if all the tracked move lines have a SN/LN (they have as
they are reserved).
task-2604728
closesodoo/odoo#73991
X-original-commit: 392bc27c0ef0bc238a7eac98497b293622f0fe1d
Related: odoo/enterprise#19756
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit:
There is no separator between "Subcontractors" and "Archived" in the filters of
'contacts' module, So on clicking on both filters thus executes a "OR" search,
which is incorrect.
After this commit:
We have added a separator so that the search becomes
"Subcontractors" AND "Archived"
Task-id:2524695
closesodoo/odoo#70464
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce the bug:
- Let's consider a consumable product P with a subcontracted BOM B
- Let's consider that B is subcontracted by a partner S and B has a storable component C
- C has the route Resupply Subcontractor on Order and has a partner SUP as supplier
- Create a purchase order PO with 1 P to S and confirm PO
- A delivery order DO1 is created with C to S
- Change the ordered quantity on PO and set 2 instead of 1
Bug:
DO1 was canceled and a new delivery order DO2 was created with only 1 C instead of 2
It happens due to merge move, when updating the PO line a new rule is
trigger and create the object in this order:
- Move Sub-Stock(finished) -> Subcontract Order -> Move Stock-Sub(comp)
Then the action_confirm is trigger and will run _merge_move
on object from left to right order. But when the move Sub-Stock is
merged, everything is write in the first move and the new move is
unlink. It result by canceling all the following object (so the new
subcontractor and the Move Stock-Sub). It was not an issue for the
subcontracting since the write of stock.move is overridden in order
to update the order quantity when the move quantity is updated.
However in this case the rule are not triggered in order to create
the moves that ressuply the subcontractor.
In order to avoid this mess, this PR prevent the merge in case of a
subcontracting move.
opw-2419222
closesodoo/odoo#69553
X-original-commit: c6447e724b9df3c25c5a5306fc902dfc5dcd6bb8
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Co-authored-by: simongoffin <sig@odoo.com>
Some usage of `_bom_find` are performance bottleneck (one request by
product). By example, when the mrp is installed, search products
with fields compute by `_compute_quantities` (e.g. 'Negative forecasted
quantity'). it is due to the override of `_compute_quantities`
in mrp which will make (in the worst case) a `_bom_find` for each
product in the DB.
To avoid this situation the `_bom_find` method become batched
which can handle several products in once. The signature of the method
has changed and uniformize in all module.
Example performance Gain:
------------------------
In a DB with 7000 products (type 'product'), 500 locations, 1800 BoM,
9000 Stock moves, etc. Search in the tree view with filter "Negative
forecasted quantity":
Before: 10879 (nb SQL request) 12.67 +- 0.11 sec (Total RPC Time)
After: 159 (nb SQL request) 1.82 +- 0.03 sec (Total RPC Time)
task-2439019
Issue:
In case of MTO on the component tracked by serial of the subcontracted
MO, if the picking generated by the MTO is complete
before record component on the subcontracted picking, when we
record the component, move lines is duplicated, one for the
reservation (due to the MTO chained move) and a other only with the
quantity done. Then it is painful to register component.
Fixes:
Don't the call of `_set_qty_producing()` when we click on
'Record Component', the user should it self applied the `qty_producing`.
closesodoo/odoo#68151
X-original-commit: e61ae06572db8aa5d1c3ecea754d3be6719eb55b
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Previously, when we find out subcontracted productions of moves, we get
all production_id from the origin moves of the moves. When user use
multple steps manufacturing, moves may also have their move_orig_ids.
In this case, we will consider its production_id as subcontracted
production.
To fix, we filered the moves, consider only move that is_subcontract is
true.
closesodoo/odoo#67101
X-original-commit: 60d799059d60befc976fd0fe5e2c0afec5d3f83b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Yuchen Huang <yhu-odoo@users.noreply.github.com>
The unlink fail in __init__.py uninstall hook is managed, however
when it fail, the error is catch but the cursor is not rollback and
do not accept additional transaction. That result in a traceback at
uninstall.
opw-2453939
closesodoo/odoo#66309
X-original-commit: 66d9dce9b6e6e65000ba0b62efcb153f2d3eec15
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Step to reproduce:
- Create a subcontracting BoM by partner A,
for a tracked product B (by serial or lots)
- Create a incoming transfer coming from A and mark as todo.
- Fill the move with move lines with lot + quantity.
- It is impossible to validate the transfer, "You need to supply lot..."
Also at the creation of the picking a warning popover indicate that
the previous operation (the hidden MO) is set after the transfer.
These issues comes from the refactor of mrp for v14 and the part of
subcontracting wasn't complete obviously.
Fixes done:
- Rewrite the code of the `_action_done` for subcontracting. It is for
the case of tracked finished product without any tracked component,
there wasn't any code to manage that. Now manage it by backorder MO
feature. Fix the main bug
- Set finished_date_planned before the transfer to avoid the alert
popover.
- Avoid to write activity in channel about the hidden MO in case of
cancelling.
- Fix `action_record_components` to manage multiple subcontracting
products with tracked component.
- Remove the `priority` field from the wizard MO (in case of tracked
product. Also the wizard is not really a wizard, just a weird hybrid
MO form)
PR: odoo/odoo#61606
task-2357115
closesodoo/odoo#62109
X-original-commit: 1a34e46eaca14aec981dd0f162e8014c7cb0abea
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Steps to reproduce:
- Create a product P with route 'Resupply subcontractor on an order'
- Let's consider a BOM for P with type 'Subcontracting'
- Create a PO with subcontractor set on that product and process with Qty > 1,
- Validate a receipt with partial Qty and no backorder
Bug:
An error was raised because no production_id was set when trying to create a mrp.product.produce
When function _action_done is called with cancel_backorder = True, the function _action_cancel is called on the new_move
with no backorder and it called the function _action_cancel defined on model stock.move in module mrp_subcontracting
This function called _action_cancel on the mrp.production record MP
And finally this function called action_cancel on model stock.move on all finish_moves and raw_moves of MP
This line unlink MP of finish_moves and raw_moves
move.move_dest_ids.write({'move_orig_ids': [(3, move.id, 0)]})
That's why production_id was not set
PS: In this way, we don't cancel a MO when it is still used by other moves.
opw:2322278
closesodoo/odoo#57346
X-original-commit: e4d22d390c8aa8edf757e36704a9e04b2b89f115
Signed-off-by: Simon Goffin (sig) <sig@openerp.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>
- 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
JF Aubert