This commit adapts commits d4abaafa4757ace22010be49bb1f7ce1c4fbfc0d and
7a78839ca6cf45ddec7adb59051da132e0ebceb4
The commits above try to split the origin moves during a split
(backorder). The issues was the split move lost its correct origin move
and the backorder move had all the origin moves linked to it.
HOW TO REPRODUCE:
- Create product FNS (storable)
- Create subcontracted BoM for FNS
- On Operation type 'Receipt', set Show Detailed Operations = True and
Pre-fill Detailed Operations = True
- Create PO for 10 units of FNS -> Confirm
- Go to Receipt > Detailed operation > Set quantity = 1 > Validate (with
backorder)
- Repeat step above on the created backorder
OR
- Create storable product FNS tracked by serial number
- Create subcontracting BoM, with strict consumption
- Create PO for 10 units of FNS -> Confirm
- Open detailed operation, add 2 lines with SN, confirm, Validate &
create backorder
- Redo the same step with backorder receipt
OPW-3838250 OPW-3812937
closesodoo/odoo#163553
X-original-commit: db78c0bdd4a50e094f8867b58b651e06a8822a8a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Some people want to manage the subcontractor stock the same way than a
classic stock. It will then impact the on hand value but it's the
behavior they want.
I keep the constraint on internal location since it will impact
valuation.
closesodoo/odoo#163262
X-original-commit: be8e1da9d9dc3b82479b1560c9d5e780c8ecb36b
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
- Install mrp and purchase
- Go to "Inventory / Configuration / Settings"
- Activate "Storage Locations"
- Go to "Inventory / Configuration / Warehouse Management / Operations Types"
- Edit "Receipts" type by activating "Show Detailed Operations"
- Go to "Manufactoring / Configuration / Settings"
- Activate "Subcontracting"
- Create product: (e.g. Product XYZ)
* Product Type: Storable Product
- Create a BoM for Product XYZ:
* BoM Type: Subcontracting
* Subcontractors: [any] (e.g. Azure Interior)
- Create a PO:
* Vendor: Azure Interior
* Products: 2 x Product XYZ
- Confirm the PO
- Open the picking from PO via the Receipt smart button
- In "Operations" tab, set done to 1
- On the picking form, change the destination location (e.g. WH/Stock/Shelf1)
- Save
- In "Detailed Operations" tab, a line should have appeared
- Select the same destination location on that line (i.e. WH/Stock/Shelf1)
- Validate the picking and create a backorder for the remaining quantity to produce
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ (Search Product: XYZ - Group by: Location)
=> The "On Hand Quantity" for Product XYZ is as followed:
* Virtual Locations/Production: -1.00 (correct)
* WH/Stock/Shelf1: 1.00 (correct)
- Open the backorder picking from PO via the Receipt smart button
- Record the production of the remaining unit
- Validate the picking
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ
Issue:
The "On Hand Quantity" for Product XYZ is as followed:
* Partners/Vendors: -1.00 (incorrect, it should be empty)
* Physical Locations/Subcontracting Location: 1.00 (incorrect, it should be 0.00)
* Virtual Locations/Production: -2.00 (correct)
* WH/Stock/Shelf1: 2.00 (correct)
Cause:
When the PO is confirmed, the stock picking and the stock move are created, they both
have the same source and destination locations.
However, in an overridden method from "mrp_subcontracting" module, a check is performed
on the move to determine if it is a subcontract.
If it is the case, its source location is set to the subcontractor location and so, the
source location of the picking and the move is not the same anymore.
When the destination location is changed on the picking, an onchange is triggering an
update of the destination location AND the source location of the move to the values
coming from the picking, erasing the subcontractor location set on the move.
The issue only happens for the backorder, because the source location update is not
propagated to the stock move lines.
In the case of the original picking, the move lines were already created with the
subcontractor location as source location.
But when the backorder is created, the move lines are created with the values coming
from a move without the subcontractor location.
Solution:
Do not propagate "location_id" from the picking to the subcontracting moves.
opw-3777379
closesodoo/odoo#161011
X-original-commit: e0f7577da1a42512d2fdc5ee316f27a1ce040522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
A subcontracting BoM sometimes shows negative values in Overview, if
components are available in subcontractor's location.
closesodoo/odoo#144702
Task: 3607854
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current Behavior:
Traceback when printing the BOM overview.
Expected behavior:
Generates a PDF of the BOM overview even if the information displayed
is entirely relevant.
Steps to reproduce:
Inventory > Configuration > Products > Attributes
Create an attribute with Variants Creation Mode set to "Dynamically".
Create a new product with this single attribute and multiple values.
Create a BOM for this product with BOM Type set to "Subcontracting".
Print the BOM overview.
Cause of the issue:
Creating such a product generates a 'product.template' that is not
associated to any variant and hence does not correspond to any
'product.product'. As a result the function_get_bom_data made can not
apply the method _select_seller properly in that case.
Notes:
- There is no error if a variant was manually created for that product.
- If the Variants Creation Mode set to "Dynamically" a variant is still
automatically created to be associated to the product tempalte so
that the erro does not rise.
Fix:
As the _select_seller method is only defined for product.product
and not for product.template, we can not not apply it here.
Furhtermore, since the additional informations provided by the
override of the method get_bom_data in the the BOM overview will
not be relevant without the existence of a variant, we skip this part of
the code when the argument of _select_seller is not valid.
opw-3698050
closesodoo/odoo#156346
X-original-commit: b983026f004d4958d2a47a0dac9b1b54e24ab04c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
Before this commit when duplicating a warehouse, its operation types (picking.type)
wouldn't get copied. This commit ensures that new picking.types are created for
the duplicate warehouse.
[Reproduce]
- run odoo 17 with -i stock,mrp_subcontracting
- in Inventory/Configuration/Warehouses Duplicate a Warehouse
- Bug: in Inventory/Configuration/OperationTypes picking types aren't duplicated
opw-3674614
closesodoo/odoo#151769
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The free to produce quantity was calculated based on the available stock in the warehouse in addition to the subcontracting location. For this reason, `free_to_manufacture_qty` variable was introduced. If it is a non-subcontracting BoM, it will be equal to the free quantity available in warehouse stock. Otherwise, it will contain only the stock in the subcontracting location.
task-3632211
Part-of: odoo/odoo#145889
In BoM overview report, the free quantity and the on hand quantity only reflected the available stock in subcontracting location. After this commit, selected warehouse stock is also included in the calculation.
task-3632211
Part-of: odoo/odoo#145889
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
Current behavior:
Confirming a Purchase Order with more than 50 lines takes
too much time to be processed. In the case of the client
they had PO with more than 200 lines which makes it
impossible for them to confirm them.
Step to reproduce:
- Install mrp and mrp_subcontracting
- Create PO with more than 50 order lines or more
- Try to confirm it
- Take a long time or timeout
Benchmark (made in 16):
| No. of PO lines | Before | After |
|-----------------|:-------:|:------:|
| 9 | 1s30 | 1s30 |
| 91 | 1min | 16s |
| 273 | 4min | 50s |
| 405 | 4min30s | 1min6s |
Fix:
Batch more actions and records to reduce the number of
queries generated by the ORM.
opw-3625892
closesodoo/odoo#149830
X-original-commit: 7d9d7917948df966ada2055dcfead0cabaaf0651
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit corrects commit 7a78839ca6cf45ddec7adb59051da132e0ebceb4
that split the move_orig_ids for new stock moves created in backorder.
The issue is this should only happens in case of subcontracting, not for
every backorders
closesodoo/odoo#151179
X-original-commit: 79f85cba46df610372c740f971182cac8c0498c0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Method _is_purchase_return had a complex check intended to detect
subcontract return move. This Check would incorrectly pass for
subcontract move when the destination location (input) does not belong
to the customer warehouse.
To fix this issue, we can check the field StockMove.is_subcontract,
however this field is only available if mrp_subcontracting is installed.
Furthermore, the check itself make no sens in purchase_stock if the
module mrp_subcontracting is not install Hence, we can move this check
to mrp_subcontracting_purchase.
With Purchase & Mrp Subcontracting installed:
- Create Component C, consumable
- Create Product P, storable, Set Vendor V under Purchase Tab
- Create BOM for P, subcontracted with Vendor V, and C as component
- In the Warehouse, set 2 steps reception
- Set Input parent location to 'Physical Location'
- Create PO to vendor V, product P, confirm, receive Product
=> Received Qty for P in PO show 0
OPW-3216011
X-original-commit: bf666d33af4ac32563e159cb6e79483d6f37b3d6
Part-of: odoo/odoo#147344
Steps to Reproduce:
- install service apps and website
- install website related bridge modules
- install quality and related mrp_subcontracting bridge module
- click on website , click on My account
- click on project ,or timesheet,or tasks,or tickets
Issue:
- after clicking,we will notice that breadcrumb indicates 'title' twice
Cause:
- this is because,in mrp_subcontracting , the title for productions is given
without checking the page_name , so that will affect all the titles.
Solution:
- if we gave condition to check the page name for production this issue is
solved.
task-3607053
closesodoo/odoo#144477
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. Create a subcontracted product P
2. Create and confirm a planned transfer with 10 x P
3. Set the done quantity to 8
4. Set the done quantity to 7
5. Open the detailed operation (i.e., the MO)
Error: The producing quantity of the MO is 1, it should be 3
When setting a smaller done quantity than the demand (step 8), we
update the expected quantity of the related MO, we set its producing
quantity, and we create a backorder.
When decreasing the done quantity, we update/cancel the related
productions. But here is the issue: in the above case, we simply
decrease the expected quantity of the backorder, so we just lose the
cancelled quantity, the user "can't" produce this quantity anymore.
In such situation (when decreasing the done quantity), we should
consider the last production (i.e., the last backorder) as the WIP one.
So, we should update/cancel the other productions and increase the
expected quantity of this last backorder, so the user can produce it
again.
OPW-3557632
closesodoo/odoo#142513
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
To reproduce the issue:
1. Create a subcontracted product P
2. Create and confirm a planned transfer with 10 x P
3. Set the done quantity to 15
Error: The demand becomes 15
When setting the done quantity, we sometimes have to update the
demande (see [1]), but it should only happen with immediate transfer.
[1] 005b51fe019dfe3f7df25aefaca04a77bd5250aa
OPW-3557632
Part-of: odoo/odoo#142513
This reverts commit a32778d2b24af2774057f5428c53291653ddc6d3, as it was
a temporary fix in wait of the larger one included in this PR.
Task-3383596
Part-of: odoo/odoo#142513
Steps to reproduce:
- Create a subcontracted BoM for a product
- Create a planned reception for this product, with a demand of 10, mark
it as todo.
- Click on the moves details and in the 'Subcontract' wizard, set the
quantity to 5 and click 'Continue'.
- Now set the quantity to 2 and click 'Record Production'.
- Close the wizard without recording the last quantity.
- Validate the picking (there should be only 7 out of 10 quantity done),
and don't generate backorders.
- When checking the related Subcontracted MO (Inventory Overview ->
Filters -> Archived -> Subcontracting), all 3 MO related to this
reception were cancelled.
Issue:
When checking for the still active_productions, it wasn't taking into
account that there could be multiple still-active productions (like when
a production is recorded in multiple times like here). This messes up
with the 'in' condition, cancelling productions that shouldn't be.
Task-3383596
Part-of: odoo/odoo#142513
Steps to reproduce:
- Manufacturing -> Configuration -> Settings -> Enable Subcontracting
- Proudcts -> Bill of Material
- Create a 'subcontracting' BoM for tracked (serial) product A from
supplier S
- Inventory -> Overview -> Receipts -> New planned transfer
- Set S as 'Receive from', A as product with qty 2 and hit save
- Open move details and record both serials.
- Now open the move details again and change one of the two move lines
lot_id to a new one and validate.
Issue:
Updating the subcontracted move's move.line `lot_id` won't change the
subcontracted MO. Which means that the link is lost between the picking
and the productions, breaking the chain in traceability.
When updating to a valid `lot_id`, now checks if there's a related
production that match the old `lot_id` to keep consistency.
Task-3383596
Part-of: odoo/odoo#142513
Steps to reproduce:
- Manufacturing -> Configuration -> Settings -> Enable subcontracting
- Products -> Bill of Material
- Create a 'subcontracting' BoM for product A from supplier S
- Inventory -> Overview -> Receipts -> New planned transfer
- Set S as 'Receive from', A as product, 10 for demand and hit save
- Set 5 in the move's `quantity_done`
- Open the move details and try to record the qty, it's still possible
to record all 10 finished quantity
- If set to full quantity and saved, the move quantity will now be 15.
Issue:
In the case of a subcontracted move, only modifying the move's
`quantity_done` doesn't do much, as recording the components will add
the new `qty_producing` to the existing move's `quantity_done`, leading
to incorrect amounts if both are used.
The proposed solution here is to emulate what's done in the form when
updating the `quantity_done` of a subcontracted move. This is true also
for the generation of lot/serial numbers for the finished products, as
it would be done from quickly validating a MO through the form view.
The checks for lot/serial of component and finished products were moved
in the picking `_action_done()` rather than on the wizard itself.
This allows to set consumption of tracked components without giving a
lot, but still requires them to be set at final validation. The lots can
be assigned through the 'Register components for subcontracted product'
button.
By doing this both methods could be used correctly.
Task-3383596
Part-of: odoo/odoo#142513
Steps to reproduce:
- Manufacturing -> Configuration -> Settings -> Enable subcontracting
- Products -> Bill of Material
- Create a 'subcontracting' BoM for product A from supplier S
- Inventory -> Overview -> Receipts -> New immediate transfer
- Set S as 'Receive from' and A as product and hit save.
Issue:
A warning appears next to the scheduled date saying the preceding
operation (the subcontracted MO) is scheduled from one hour later than
this picking. This only happens for immediate transfers.
When picking's `_set_scheduled_date()` is called, this ultimately leads
setting the subcontracted MO's date planned/finished to that same date.
But since the `date_planned_finished` is implicitely readonly, its value
is recomputed right after it was set, as it depends on
`date_planned_start`, which was updated at the same time.
Also, in case of subcontracted MO, the `date_planned_finished`, the
start and finished date are usually the same, so there's no need to add
the default 1 hour between the two dates. It's done at the creation for
subcontracted MO, but any update would recompute the date to start + 1
hour and raise an useless warning on the subcontracted picking.
Task-3383596
Part-of: odoo/odoo#142513
For subcontracting, we need to consider both vendor lead time and
manufacturing lead time, and DTPMO (Days To Prepare MO) on the BOM.
Subcontracting delay =
max(Vendor lead time, Manufacturing lead time + DTPMO) + Days to Purchase + Purchase security lead time
Same thing applied to Bom overview, except:
1. Availability state will be computed based on the delay time of it's
components. DTPMO on the bom won't be take into account.
2. Lead time will use the DTPMO on the BOM. DTPMO will be added to
the lead time when it's a manufacturing bom or when it's a
subcontracting bom with Manufacturing Lead Time + DTPMO > Vendor Lead Time
Task-3081481
Part-of: odoo/odoo#137810
*: mrp_subcontracting, project, test_website, web, web_editor,
website_slides
This commit removes jQueryUI autocomplete that was the last usage of
jQueryUI.
No longer usage of these features inside the codebase
task-3439226
Part-of: odoo/odoo#139209
There is a button in the header to register subcontracting process
(when needed). And there is an additional button in the view with
the purpose to correct data later after the encoding. However we
can't set button with optional="hide". We rename it with an edit
icon
Part-of: odoo/odoo#140307
Odoo Translation Bot