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>
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>
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
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
The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The 'like'/'ilike' operators automatically add the wildcard character
(`%`) at the beginning and at the end of the value. This commit fixes
the incorrect usage.
closesodoo/odoo#136007
Related: odoo/enterprise#47886
Signed-off-by: Raphael Collet <rco@odoo.com>
On the backorders, the consumed quantities are incorrect.
To reproduce the issue:
1. Create two products:
- C01: consumable
- P01: storable
2. Create a BoM
- Product: P01
- Type: Subcontracting
- Subcontractor: S
- Components: 1 x C01
3. Create and confirm a planned receipt:
- From: S
- 10 x P01
4. Set the done quantity (directly on the tree view) to 1
5. Validate + Backorder
6. On this first backorder, set the qty to 2
7. Validate + Backorder
8. Validate the second backorder
9. Inventory > Reporting > Moves History, filter on C01
Error: There are three SMs, and here are the done quantities: 1, 9
and 7. The second one is incorrect, it should be 2 (see step 6).
Since [1] the done quantity is always editable on the picking's
operations, but the feature is not implemented in subcontracting,
therefore the communication between the MO and the picking does not
work well. For instance, step 4: save the done quantity and open the
MO: nothing changed on it, its producing qty is still zero. Another
example: step 4, instead of setting the done quantity directly on
the picking, open the wizard (the MO), record 3 produced products and
close the wizard. The done quantity of the stock move is 3 but the
user can still edit it. However, if he tries to update the line,
nothing will change on MO side.
On top of these "little" bugs, it may lead to a more important one
as shown in the above use case. Step 5: at some point, we split the
MO to generate a backorder for 9 x P01:
https://github.com/odoo/odoo/blob/c47e4ac7cb5fdd690f40ab2e0f8d022ba565145e/addons/mrp_subcontracting/models/stock_picking.py#L72-L76
And, as shown, the flag `set_consumed_qty` is set to `True`. As
explained in the method description:
https://github.com/odoo/odoo/blob/a2574b45aef1ff6ff3a221b996d0bb0dda2a8c74/addons/mrp/models/mrp_production.py#L1602-L1603
So, because of this flag, the method will create a SML for C01 on
the backorder, with its done quantity set to the reserved one: 9.
However, back to the first block code: `move.move_line_ids` only
contains the SML created at step 4 (i.e., the SML of the inital
SM, with a done quantity equal to 1). As a result, in the for loop,
we only define the producing quantity of the initial MO.
This is a first issue: step 6, suppose the user rather opens the
detailed operations of the line: it displays the new MO, the
producing qty is 0 but the consumed quantity of the component is 9.
This is not perfect, but let's ignore this and continue with the
above steps. The user sets the done quantity to 2 and validates with
backorder. It runs the productions split again, we use the done
quantity as producing one on the MO, but we don't edit the consumed
quantities, hence the error.
For all these reasons, the safer solution is probably to prevent the
feature 'qty done always editable' in case of subcontracting.
[1] cacc677a08066bc23e1c89df36027599d05f2a08
OPW-3441197
closesodoo/odoo#135862
X-original-commit: 049f63fbc1ab09cf75824e5c22508ea091e5c4dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
The `mrp.production` method `_pre_button_mark_done` will now be public
so it can be called since the web client.
This change is done in order to know if trying to mark as done a
production will return a wizard or not, which is needed in the new MRP
Display view since there is a delay before a MO is actually marked as
done and we don't want to see the wizard poping up after this delay but
before !
The method `_set_qty_producing` public is also public now because it's
called in `_onchange_producing` but saddly, the onchanges don't happen
in the MES view, so this way we can manually call it when needed.
task-3231200
Part-of: odoo/odoo#127250
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Improve the returns process by adding the following improvements:
- Removal of the 'return' operations type. Returns of deliveries now
become receipts.
- Update of the `stock_picking_return` wizard by removing the onchange
on picking_id.
- Show returns in the sale portal, with a new 'return label' PDF report
- Enable returns for multi-step receipts on purchases
Community PR: https://github.com/odoo/odoo/pull/118568
Enterprise PR: https://github.com/odoo/enterprise/pull/39761closesodoo/odoo#118568
Task: 3081370
Related: odoo/upgrade#4660
Related: odoo/enterprise#39761
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit changes the process flow of stock pickings. A new picking will
always be created in immediate transfer mode and 'ready' state. From
their, it can be validated directly or 'reset to draft'. This second action
switch the immediate mode to planned mode and reset the state as draft.
From their the classical workflow is processed
confirm -> (assigned ->) validated
Task: 3256447
Part-of: odoo/odoo#117513
In this commit the resupply subcontractor source location is changed from
virtual production to WH/stock
Task id: 3263796
closesodoo/odoo#120727
X-original-commit: 13f078e4c27767b43740a80bf405e71e91348017
Signed-off-by: Tiffany Chang <tic@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, updating a purchase quantity of subcontracting
product will try to not merge the new and old move to keep the two chain
separated as much is possible and avoid side effects (receipt move,
subcontracting moves, resupply moves). Some were merged, some cancelled,
...
This had two issues:
First, not merging the quantity was not guarantied
as you can specify you don't want to merge them with others but it's not
possible for a stock move to say to any other move do not merge with me.
Second, by not merging the receipt moves, we duplicate every other
object on the chain. This pollute the database uselessly.
opw-3147446
closesodoo/odoo#114739
X-original-commit: 0b1bcfacb13c7de480f30015b91db11ed03f2dfe
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Apply propagation mechanism to Manufacture rules,
except the ones from the mto rule.
Also fix some _find_global_route having missed route's rename.
closesodoo/odoo#107952
Task: 2907698
Related: odoo/upgrade#4342
Related: odoo/enterprise#34963
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previously in https://github.com/odoo/odoo/pull/88644/commits/a57be884ee625ab2d67b65f0ece0b8e9b1620369
we restricted the subcontractor locations (property_stock_subcontractor)
to locations with the new setting `is_subcontracting_location=True`. The
purpose of this new setting is primilarily to support the
mrp_subcontracting dropshipping use case though, therefore we want to
keep the previous freedom of allowing users to choose any location as a
subcontracting_location. There are some routing and filtering
errors/confusion that can occur if a user selects a location that isn't
marked as `is_subcontracting_location` (or sets this value to false
after already assigning it to a subcontractor), but since this has not
been reported as an issue in the past, we expect users to properly
configure these fields accordingly.
Part of general bugfix task: 2985735
closesodoo/odoo#110200
X-original-commit: d86df2b9cef742b6cadd294f57a855634768d039
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
The problem is that when you archive a company and then install
subcontracting, you get a traceback.
Step to reproduce (in a multi-company environment):
-install 'stock'
-archive a company
-install 'mrp_subcontracting'
-->traceback
Explanation:
When installing the 'mrp_subcontracting', there's a search on all
(active) companies in order to add a subcontracting location for each
of them (this is is triggered by
'/odoo/addons/mrp_subcontracting/data/mrp_subcontracting_data.xml').
But there is still a warehouse linked to the archived company.
So when adding routes to all warehouses and looking for the
subcontracting location of the archived company, it is set to
False. Which is not intended and causes the traceback.
Solution:
Add '.with_context(active_test=False)' to the search for the companies
in '_create_missing_subcontracting_location(self)', so the missing
subcontracting location will be created for the archived companies too.
Discussion:
-The ability to archive companies is new to Odoo16 (implemented due to
the new pricing).
-Here I considered that we want to create a subcontracting location for
an archived company instead of taking action on the warehouse linked to
the archived company (like not considering it when creating routes).
I did this because a company can be unarchived and with this fix, it
will not cause issues.
-I think other problems similar to this one (in any app), should appear
in the future.
opw-3039495
closesodoo/odoo#107168
X-original-commit: 1dcdbe9e3cc21af50ed580c032b1927e21c3c24b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In large database, if you try to get all subcontrat quant you can crach postgres with a big query.
closesodoo/odoo#106543
X-original-commit: aa104980d483efef087198dc5bb70ec63a47ed7e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit allows the user to archive/unarchive subcontracting rules by
toggling warehouse settings `Dropship Subcontractors` and `Resupply Subcontractors`.
Additionally, if there is no warehouse with a setting enabled, the corresponding global
routes are archived as well.
Part-of: odoo/odoo#95770
This commit introduces a new pick type used when dropshipping subcontractors,
specifically when the PO resupply relies on the dropship mechanism
this is done by using it for the rules of the `Dropship subcontractor on order` route
Part-of: odoo/odoo#95770
Before this commit, to access the location subcontractors, you needed to search
everytime, the one2many will provide this as well as cache the result for future use.
Taskid: 2848013
Part-of: odoo/odoo#95770
Ease subcontractor stock tracking by using dedicated locations.
Simply declare location as a subcontracting one (rules are
automatically adapted) and set it on vendor.
closesodoo/odoo#88644
Task: 2720393
Related: odoo/upgrade#3755
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- create a subcontracted product (i.e. create subcontract BoM)
- create and confirm PO for subcontracted product (qty > 1)
- try to decrease PO qty for subcontracted product
Expected Result:
Since receipt is not yet validated, the qty in the receipt should
decrease (it will in the subcontract MO as well, but this doesn't matter
since no one should work directly with the MO)
Actual Result:
A validation error occurs saying the qty to produce must be non-negative
We allow neg demand qtys to be proprogated from SOs and POs since
https://github.com/odoo/odoo/pull/76752 . While we added in a check to
make sure MOs are not created when a neg qty change is proprogated, we
forgot to add a check for subcontracted created MOs, hence the
validation error (i.e. the neg qty change is trying to create a
subcontracted MO of a neg amount.)
Task: 2777571 (issue 2 of additional issues)
X-original-commit: 251f146b6ecb0e2d428089669199a6deb3a6c060
Part-of: odoo/odoo#97383
Fixes a few incorrect subcontracting UX behaviors:
- When subcontract BOM is flexible, the record burger should always show
so user can more easily record varying quantities
- When `show_operations=True` then `action_assign_serial` button in
Operations tab should only show if subcontract BOM is NOT strict AND
has no tracked components (instead of always showing regardless of BoM
consumption and its components)
- When a subcontract receipt is backordered, the Done moves should no
longer return `_action_record_components`.
- When 'show_operations=True' for receipts, we shouldn't display the
subcontracting component lines in the Detailed Operations tab
Task: 2777571
X-original-commit: e9b9fe541df984bba33c4f44d48e57820ea4968f
Part-of: odoo/odoo#97383
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Bug fixed where when the MRP subcontracting module was installed the merging of MO's would not open the MO form view.
Correctly displays the breadcrumbs as well.
Task: 2799674
Community PR: https://github.com/odoo/odoo/pull/88801
Part-of: odoo/odoo#88801
Usecase to reproduce:
- Install mrp_subcontracting
- Create a user with inventory access but not mrp access
- Validate a receipt for a product
Current behavior:
Access error on `mrp.production`
Expected behavior:
The receipt and the linked subcontracting order are validated
The stock user only receipt the products from the subcontractor so
he doesn't need to know the `mrp.production` behind that's why he
doesn't need access right. However he should be able to validate the
transfer since he receipts the goods. And it should update the quantity
on the subcontractor side by validating the subcontract order, so
we pick the sudo solution.
closesodoo/odoo#90301
X-original-commit: f1660b2254460abe10ce1d0a1fa7639d5c3e2b33
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Adapt db775ffd308638a390be52eba3ca11c9c2d1602d to subcontracting flow,
to avoid performance issues when receiving a large amount of SNs
closesodoo/odoo#85603
Task: 2777451
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When adding a landed cost and selecting Manufacturing Order, the name of the receipt of the subcontracted products is now shown as well as the MO name for subcontracting orders.
Task: 2667152
Community PR: https://github.com/odoo/odoo/pull/88199closesodoo/odoo#88199
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Split a manufacturing order in several parts
using the back order mechanism
Merge several manufacturing orders related to the same product/bom
by cancelling all of them and creating a new one
closesodoo/odoo#82427
Task: 2662566
Signed-off-by: Arnold Moyaux <arm@odoo.com>
In case of a MRP subcontracting, it is not possible to process the
delivery with several backorders.
To reproduce the issue:
1. Create two products P_compo, P_finished
- Both storable
- P_compo must have the route "Resupply Subcontractor on Order"
2. Update P_compo's quantity: 5
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: 5 x P_finished
5. Mark as Todo
6. Inventory > Resupply Subcontractor, find the delivery of P_compo for
P and process it
7. Back to T, set the done quantity to 1.25
8. Validate T (with backorder)
9. On the backorder BO1, set the done quantity to 1.0
10. Validate BO1 (with backorder)
11. Open the second backorder BO2 and validate it
Error: a Validation Error is displayed "You can not enter negative
quantities.", which doesn't make sense
The issue comes from the inner method `_get_available_move_lines` in
`_action_assign`. When validating a picking, at some point, we are here,
at the beginning of `/mrp_subcontracting._action_done`:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L36-L37
To understand what happens next, we need to note that, in this method,
the associated MO will be marked as done later (on line 76). Back to the
current line (L37), we are calling `super` which leads to the
problematic `_get_available_move_lines`. Suppose we are on step 10 (we
are validating the first backorder), we have
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1390-L1391
`move_orig_ids` contains two stock moves, each one associated to one MO.
However, as said above, the second MO is not yet marked as done, this
will be done later on in `/mrp_subcontracting._action_done`. Therefore,
`move_lines_in` is only defined with the first SM, from the first MO,
with a quantity of `1.25`
Further in `_get_available_move_lines`, we have:
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1403-L1405
`move.move_orig_ids.mapped('move_dest_ids') - move` gives two SM, and
here is the issue: the second one is already processed, so both are kept
in `move_lines_out_done` and the sum of their quantity is equal to
`1.25 + 1 = 2.25`
Therefore, at the end of the method, when computing the difference, it
gives a negative difference. This negative value will be used to create
a SML and later on, it will trigger the validation error.
Once the above issue is fixed, there is another "invisible" issue that
need to be fixed: when generating several backorders on the deliveries,
only the first one will trigger the creation of a new MO. Suppose we are
back in `/mrp_subcontracting._action_done` (still on step 10 in the
above case), in the first for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L39-L43
`move._get_subcontract_production()` returns the two MO (from the
initial picking and from the first backorder). However, since the first
one has already been processed, the if-condition is validated.
Therefore, this for-loop is done and the second MO is not processed (the
quantities are not recorded and its field
`subcontracting_has_been_recorded` is not defined to `True`). As a
result, still in `/mrp_subcontracting._action_done`, we are now in the
second for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L71-L72
`_subcontracting_filter_to_done` removes the two MOs because the first
one is done and the second one has not its field
`subcontracting_has_been_recorded` set to `True`. The condition in the
first for-loop is not accurate enough.
OPW-2731658
closesodoo/odoo#83658
X-original-commit: 1b740ae148acfc832b124122763817b08ea110ab
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@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
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>
Anh Thao Pham (pta)