To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the route "Dropship Subcontractor on Order":
- Open the Buy rule:
- Propagation of Procurement Group: Leave Empty
3. Create three products P1, P2, P_comp:
- Storable
- With a vendor (V1, V2, V_comp)
- P_comp's routes:
- Dropship Subcontractor on Order
4. Create a BoM:
- Product: P1
- Type: Subcontracting
- Subcontractors: V1
- Components: 1 x P_comp
5. Repeat step 4 with P2 and V2
6. Create and confirm a PO:
- Vendor: V1
- Products: 1 x P1
7. Repeat step 6 with V2 and P2
8. Open the purchase orders list
Error: There is only one PO with V_comp. It contains 2 x P_comp and
the dropship address is P1. This is incorrect. There should be two
PO, one for P1 and another one for P2
When confirming the PO, a MO is created (subcontracted) and then the
system creates and processes a procurement for the component.
Because of the component's routes, it leads to the `_run_buy` method.
It will check whether a PO already exists or has to be created. To do
so, it creates a domain based on few criteria, such as the value of
`dest_address_id`:
https://github.com/odoo/odoo/blob/6d28c9c2e5ea3e9a3b8a872627a411bbfe2f2a59/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L17-L21
But here is the issue: `partner_id` is not defined.
OPW-3370648
closesodoo/odoo#128791
X-original-commit: 094e45d120c525d8b65bca7c0d10d10dbb6383cd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
With this commit:
========================
- Added a new field `forecasted_qty` in replenishment to display the
forecasted qty based on a selected warehouse in the wizard
- Changed the `route_ids`(m2m) field to `route_id`(m2o) so that
we can apply a specific route for the
replenishment instead of the product's default routes
- Reduced the width of all the fields
- Remove the time from the scheduled date and make the unit field not editable.
- Can see vendor information with info icon field when buy is selected
- Hide the Dropship route from the Route
TaskId : 2579425
closesodoo/odoo#96948
Related: odoo/upgrade#3796
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
account
1. We introduced a new Production Cost account that can be set on
locations with Production type. When products move into/out of a
production location. The account entry will be post on this account
instead of previous Stock in/out account.
2. On the accounting setting page, we can now set the default values for
all stock accounts. Users can also disable automatically accounting for
stock there.
Task-3046333
closesodoo/odoo#113973
Related: odoo/enterprise#37653
Signed-off-by: Tiffany Chang <tic@odoo.com>
Ease 'dropship' purchase orders for subcontractors.
At the moment, it is not possible to dropship a subcontractor
with a mix of products, some of which are part of a subcontracting BOM
and some of which are not.
This becomes possible, but it remains mandatory to choose between
- Dropship (for the 'customer' location)
- Dropship Subcontractor (for the 'subcontracting' location).
Due to the destination location, it is not possible to combine
the two streams in a single purchase order.
closesodoo/odoo#119404
Task: 3199595
X-original-commit: c7f49776c74303e277246a4b6302e8a87d6a7def
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
As a display line does not need to fulfill the dropship check, we skip those
and we do give the user a hint which lines are potentially not fulfilling
the check.
Reproduce:
- Create a purchases order with a picking type for dropshipping
- Add a different destination address (i.e. of another subcontractor to follow up the next manufacturing process)
- Add products with a defined BoM with type subcontractor and vendor
- Additionally add a section or a note
- Try to confirm the purchase order
Result:
- A user error will be triggered about a line which does not fit the current use case
Solution:
- as a section or a note should not be checked we do not trigger for those
- for other products which do not fit the use case we let the user know which lines are blocking
closesodoo/odoo#115044
X-original-commit: 5ba435d1ece208453fc73993b8018c68bb5f889d
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>
*:purchase_stock,stock_account
To reproduce the issue:
1. In Settings, enable 'Multi-Step Routes'
2. Create a product category PC:
- Method: FIFO
- Valuation: Auto
3. Create two products P_compo, P_finished
- Both:
- Type: Storable
- Category: PC
- With a positive cost
- P_finished:
- Vendors: a new vendor V
4. Create and confirm a SO with one order line:
- Product: P_finished
- Route: Dropship
5. Confirm the PO and process the dropship
6. Accounting > Accounting > Miscellaneous > Journal Items
Error: There are a lot of lines and most are incorrect
When marking the dropship SM as done, we check how we should
value it:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L244-L252
Here is one issue: `_is_dropshipped` returns `True`, which is
correct because the source is the subcontractor location and the
destination a customer:
https://github.com/odoo/odoo/blob/8276a9b51b7c5fc0ae6dd557ae88a9c31f1d1962/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L14-L20
However, `_is_out` will return `True` too. To get this value, we
check if the source and destination locations have to be valued:
https://github.com/odoo/odoo/blob/18450973eaf3ca048cdcd2046a8cba5f5c0f98b0/addons/stock_account/models/stock_move.py#L99-L100
Again, since the source location is the subcontractor one (which is
an internal one) and the destination location is the customer one,
we will consider that we have to value this SM. As a result, we will
apply `_create_out_svl` and `_create_dropshipped_svl` on the same SM
(this explains some incorrect AMLs are generated).
Then, there is another issue. In `_create_dropshipped_svl`, we
create an in-SVL and an out-SVL for P_finished. However, when
processing the MO, an in-SVL will also be generated for P_finished.
The issue comes from `_create_dropshipped_svl`: it creates an in-SVL
but the source location is not outside from the company, so it
should not create the incoming layer.
Finally, when creating the SVL in `_create_dropshipped_svl`, we use
the unit price of the SM to define the value of the SVL. This is an
issue: suppose the unit price of the POL is $10 and the costs of
P_compo is $1, the unit price of the SM is then $10 (and so does the
value of the SVL) but the actual value of the delivered P_finished
is $11. Howver, when calling `_action_done` on a SM, we first
process it and only then we will process the MO:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L33-L36
So, in `_create_dropshipped_svl`, we can't know the actual cost of
P_finished. This is the reason why we have to create a compensation
layer once the MO is processed (i.e. in the override from
`mrp_subcontracting_dropshipping`)
Similar issues will happen if we return the
dropshipped/subcontracted product.
OPW-3078499
closesodoo/odoo#110390
X-original-commit: 200aac56771fd1ef759f73b277a6808d96ee5f31
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect
To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
- Product: P_finished
- Type: Subcontracting
- Subcontractors: a subcontractor S
- Components: 1 x P_compo
3. Create and confirm a PO:
- Vendor: S
- Deliver To: Dropship
- Drop Ship Address: a partner P
- Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
- Update SO/PO quantities: True
- Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO
Error: The qty received is 2, it should be 0
There is currently no code to handle the return of a dropshipped product
OPW-3030895
closesodoo/odoo#105863
X-original-commit: 0a03678889d46dfc39922c0df965c06457f28d79
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When returning a dropshipped and subcontracted product to an internal
location, the received quantity of the PO line will be incorrect
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_Finished
3. Create a BoM:
- Product: P_finished
- Type: Subcontracting
- Subcontractors: a subcontractor S
- Components: 1 x P_compo
4. In Locations, edit WH/Stock:
- Return location: True
5. Create and confirm a PO:
- Vendor: S
- Deliver To: Dropship
- Drop Ship Address: a partner P
- Products: 1 x P_finished
6. Validate the receipt
7. Create a return with 1 x P_finished:
- Update SO/PO quantities: True
- Return Location: WH/Stock
8. Validate the return
9. Go back to the PO
Error: The qty received is 2, it should be 1 (it should not be 0 since
the product has been returned to an internal location)
In `/purchase_stock._compute_qty_received`, there is already a code to
anticipate such a situation (i.e., a user who returns a dropshipped
product to his stock location):
https://github.com/odoo/odoo/blob/bf3c398f0644f690c64815b2b6e298aed7bedd70/addons/purchase_stock/models/purchase.py#L300-L305
However, the methods `_is_dropshipped` and `_is_dropshipped_returned` do
not include the feature subcontracting + dropshipping. This is the
reason why, in `_compute_qty_received`, the above condition is not
respected and why we add the return stock move to the received qty.
OPW-3030895
X-original-commit: 5dffa88e788355efe7b9b9bccff75fdbd52713e9
Part-of: odoo/odoo#105863
A user can not buy a subcontracted product and directly deliver it
(dropship) to another subcontractor. Moreover, in such situation, the
received quantity is not correctly computed.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Storage Locations"
2. Create three products:
- P1:
- Storable
- With a vendor V1
- P2:
- Storable
- With a vendor V2
- P3:
- Consumable
3. Edit V1:
- Customer Location: Physical Locations/Subcontracting Location
4. Create two BoMs:
- Product: P1
- Type: Subcontracting
- Subcontractors: V1
- Components: 1 x P2
- Product: P2
- Type: Subcontracting
- Subcontractors: V2
- Components: 1 x P3
5. Create a PO:
- Vendor: V2
- Deliver To: Dropship
- Drop Ship Address: V1
- Products: 1 x P2
6. Confirm the PO
Error: a Validation Error is raised at `mrp.production` creation because
of a missing field (`picking_type_id`).
In some cases, when getting the values to create the MO, the basic
`_prepare_subcontract_mo_vals` does not return any `picking_type_id`.
That's the reason why an override has been added in
`/mrp_subcontracting_dropshipping` (see [1] for more details). Thanks to
this override, if the usage of the destination location is `customer`,
we know that we are in a "dropship" situation and we manually define the
`picking_type_id`:
https://github.com/odoo/odoo/blob/d73e70f22e47e81e59aff0c9f578aff260447256/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L15-L17
However, in the above case, the subcontracted stock move starts from a
subcontracted location and also goes to a subcontracted location
(because of step 3). As a result, the if-condition is not respected and
the `picking_type_id` is not defined.
Once this issue is solved, there is a second one: suppose the PO
confirmed. The user validates the transfer. New error: the received
quantity on the PO is not updated. This is because of an incorrect
condition in `/purchase_stock._compute_qty_received`:
https://github.com/odoo/odoo/blob/d0537e32e5aa4b0fe2ad674ab3ec7c42ae1a12f9/addons/purchase_stock/models/purchase.py#L306-L315
Added by [2] and modified by [3], this condition checks that:
- the destination location usage is `internal` (correct, this is a
subcontracting location)
- the source location usage is not `supplier` (correct, this is a
subcontracting location, so it is `internal`)
- the destination location is not part of the warehouse children (here
is the issue: the SM does not have any warehouse, so it gives a false
positive)
So, because of the incorrect third condition, the condition is
respected. And because `to_refund` is `False` (which is correct), we
don't do anything. That's the reason why the received quantity is not
updated.
[1] d73e70f22e47e81e59aff0c9f578aff260447256
[2] e6a1e240f1
[3] fd22fe221026e353aac7414348b029ae7e290b2f
OPW-2922546
closesodoo/odoo#102224
X-original-commit: a51b4158b964a11fa371a9eb8c877c9ec395f412
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The `is_subcontracting_location` setting is intended only for
complicated route/rule use cases therefore we make it visible
only in debug mode to prevent users from setting this value and
unintentionally creating a lot of new routes/rules unnecessary.
Additionally, it is expected that users who previously set these up
manually will not want their custom rules/routes changed but will still
need the existing behavior to continue, so we restore the previous check
for subcontracting locations set as sublocations of the primary company
subcontracting location.
Follow up to task: 2720393
Part-of: odoo/odoo#100219
This commit shows the user Dropship address field in the PO when subcontractor resupply is
done with dropshipping mechanism.
closesodoo/odoo#95770
Related: odoo/upgrade#3852
Signed-off-by: Tiffany Chang <tic@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
Confirming a PO with a customer as delivery address does not work
To reproduce the issue:
1. In Settings, enable "Multi-Locations"
2. Create two products P_finished, P_compo
- P_finished:
- Add a vendor V
3. Create a bill of materials:
- Product: P_finished
- Type: Subcontract
- Subcontractor: V
- Components: 1 x P_compo
4. Create a PO:
- Vendor: V
- Products: 1 x P_finished
- Deliver To: Dropship
- Drop Ship Address: a customer
5. Confirm the PO
Error: a validation error is displayed: "[...] a mandatory field is not
set. [...] Model: Production Order (mrp.production), Field: Operation
Type (picking_type_id)"
When confirming the PO, we extract some values of the subcontracted SM
to create a MO:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L105-L117
However, because the SM is not created from the SO, it does not have any
`sale_line_id`. And, because its a dropshipped one, neither the SM nor
its picking type has a defined warehouse. As a result, `_get_warehouse`
does not return anything and we can't define the `picking_type_id` of
the MO. This is the reason why the error will be triggered on its
creation.
OPW-2922546
closesodoo/odoo#99223
X-original-commit: 28a20daab6a7097ecd26bf66eeb80b2f5ad294a8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
When selling a kit with a dropshipped component, the delivered quantity
will be incorrect
To reproduce the issue:
1. Create 3 consumable products P01, P02, P_kit:
- P02:
- Add a seller S
- Enable the dropship route
2. Create a bill of materials:
- Product: P_kit
- Type: Kit
- Components:
- 1 x P01
- 1 x P02
3. Create and confirm a sale order SO with 1 x P_kit
4. Confirm the generated purchase order (with vendor S)
5. Process the two pickings of SO
6. Go back to SO
Error: The delivered quantity of P_kit is 0 instead of 1
When computing the delivered quantity, because the `dropship` flag is
not set, we don't reach the revelant code:
https://github.com/odoo/odoo/blob/3db136f19480b31ca3f60a77c0c7354161bedde0/addons/sale_mrp/models/sale_mrp.py#L37-L44
OPW-2870893
closesodoo/odoo#94364
X-original-commit: fff6edad8cfb45b9a622bceefa4b83f620d7fe86
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When using a sub-location of "Subcontracing Location" and a dropshipped
component, the purchase order doesn't have any dropship address.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Multi-Step Routes"
2. Create a new location L:
- Parent: Physical Locations/Subcontracting Location
- Type: Internal Location
3. In Rules, duplicate the rules of route "Dropship Subcontractor on
Order" and replace "Physical Locations/Subcontracting Location" with L
4. Create two products:
- P_finished:
- Type: Storable
- Vendor: V_subcontractor
- P_compo:
- Type: Consumable
- Vendor: V_compo
- Routes: Dropship Subcontractor on Order
5. Edit V_subcontractor:
- Subcontractor Location: L
6. Create a bill of materials:
- Product: P_finished
- Type: Subcontracting
- Subcontractor: V_subcontractor
- Components: 1 x P_compo
7. Create and confirm a purchase order:
- Vendor: V_subcontractor
- Products: 1 x P_finished
8. Open the purchase order linked with P_compo
Error: the Dropship Address is not defined
This address is defined thanks to the value of `partner_id`:
https://github.com/odoo/odoo/blob/aec7fcdb693729f432ae2341c00ef317b65fbcbc/addons/purchase_stock/models/stock_rule.py#L300
However, this key is missing
OPW-2721474
closesodoo/odoo#92249
X-original-commit: 587d8cd0ecb956a5c1b1a32a7abadea3019f848e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
On a SO, the delivered quantity of a dropshipped kit is incorrect in
case of a return
To reproduce the issue:
1. Activate Dropshipping
2. Create 3 products: KIT AB, A, B:
- All have the Dropship route and a supplier set
3. Create a BOM of type kit: KIT AB is composed of A & B
4. Create a SO for 1 unit of KIT AB, validate
5. Validate the created PO
6. Deliver the products
7. Create a return for these products
- Error: On the SO, the delivered quantity is 0 but the return is
not validated yet. This quantity should still be 1
8. Validate the return
- Error: On the SO, the delivered quantity is now 1, it should be 0
The 'all or nothing' policy should correctly consider the returns: all
moves (to customer) must be done and the returns must be delivered back
to the customer
OPW-2759250
closesodoo/odoo#87596
X-original-commit: f259d10db577bbf1b11fffd028e678b38d5f402d
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
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>
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
If all the product in a PO are for a subcontracting purpose,
set the PO delivery address to the subcontractor address.
Task: 2444742
Part-of: odoo/odoo#71732
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
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>
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>
Improve onboarding by removing the replenish on order route.
Companies that do MTO process could unarchive the route in
order to have a basic configuration.
closesodoo/odoo#55147
Task: 2245882
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Allow to do a dropshipping with a subcontractor.
If the product uses the routes drophipping and have
a subcontracting BoM. Then a PO for the subcontractors
will genrate a need in the subcontracting location for
the required components.
A module is needed because the picking_type_id for dropshipping
do not have a warehouse_id. The warehouse_id is needed in order to
know from which warehouse the subcontracting components should be
deliver.
Gorash