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>
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>
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>
Khushi Vakil