Previous fix: https://github.com/odoo/odoo/pull/84631 missed the case
when raw_move_ids have already done move_orig_ids (i.e. when 2/3 step
MOs or subcontracting w/ resupply contractor). This made it so when
MOs are backordered, these moves would not be reserved even though they
were in the original MO.
This issue was fixed during a refactoring (reserved amounts are now
distributed to backordered MOs), but this commit will add a test to
prevent the issue from returning in the future.
Part of Task: 2777571
Original PR fix (pre-refactoring): odoo/odoo#91460closesodoo/odoo#97383
X-original-commit: a825d9ed715b369128c876174ca6ebfac72adbe5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
It now uses the new owl code, instead of the legacy list view, which
will be removed in the future.
closesodoo/odoo#96595
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
Currently the linked receipt (in case of subcontracting)
is visible in the tree view and search view of every MO.
However we want to limit the feature to landed cost scope
since it's only useful in that case and it adds noise otherwise.
We need a new module since we don't have any bridge between
subcontracting and landed costs
closesodoo/odoo#89399
Signed-off-by: Steve Van Essche <svs@odoo.com>
BoM Structure & Cost report has different errors:
- The product cost of a subcontractor included in a product doesn't
scale with the quantity of the product (Issue 1)
- The BoM cost of a product composed of a subcontractor doesn't include
the subcontractor price (Issue 2)
- The BoM cost of a component composed of a subcontractor doesn't scale
with the quantity for the subcontractor price (Issue 3)
Steps to reproduce:
1. Install mrp_subcontracting_purchase
2. Create a product 'TEST 1', in the Purchase tab specify 'Azure
Interior' as vendor with price 5$
3. Create a bill of material for the product 'TEST 1' with BoM type
'subcontracting', subcontractor 'Azure Interior' and product 'Bolt' as
component
4. Create another product 'TEST 2', in the Purchase tab specify 'Azure
Interior' as vendor with price 8$
5. Create a bill of material for the product 'TEST 2' with BoM type
'subcontracting', subcontractor 'Azure Interior' and product 'TEST 1'
as component
6. Go to the BoM Structure and Cost of product 'TEST 1'
7. The product BoM Cost doesn't include the subcontractor price (it
should be the sum of its components) (Issue 1)
8. Increase the quantity of the product by 1
9. The subcontractor's product cost doesn't change (it should increase
with the quantity) (Issue 2)
10. Go to the BoM Structure and Cost of product 'TEST 2'
11. Increase the quantity of the product by 1
12. The BoM Cost of component 'TEST 1' only counts the subcontractor
price once (it should be the sum of its components) (Issue 3)
Solution:
Scale the subcontractor product cost with the quantity, update the
BoM cost of a product with the subcontractor price (in `_get_bom`) and
scale the subcontractor price with the quantity (in `_get_price`)
opw-2844482
closesodoo/odoo#92095
X-original-commit: 4f3347c6925e10ec62a85bb01d7cdb65b1e13b15
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@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>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@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>
This task will:
- Clean the code (e.g. the production's moves are now created directly)
- Have the same behavior when creating object in the UI or directly in
backend
It's mainly on the `mrp.production` object and most of the computed
stored field are used as default value or act like an onchange on draft
production. Once the production order is validated, it's only modify
by direct write
Task-2709753
closesodoo/odoo#83576
Related: odoo/enterprise#24405
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Since bcf665a291, this helper has moved.
closesodoo/odoo#88559
X-original-commit: 2ac6357073d80fb07c7bd71cfd472d26ea1e5d83
Signed-off-by: Christophe Monniez (moc) <moc@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>
If a warehouse is set to a route like default 3-steps, updating the MO's
quantity to produce won't update the outgoing picking from
post-production to stock.
Since the quantity is now changed in the following pickings, no need to
put a warning in those pickings for the quantity change as their moves
quantity were automatically updated.
Task-2797359
closesodoo/odoo#86572
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>
Both mrp_subcontracting and a module in Enterprise both inherit
`mrp.mrp_production_form_view`. This was leading to a conflict where the
Enterprise view could overwrite the invisible=1 attribute added by
mrp_subcontracting, therefore we update the views to avoid this.
Part of Task: 2695173
ENT PR: odoo/enterprise#22637
X-original-commit: 6317c34808d381e54bae2431fec2de4b8503b447
Part-of: odoo/odoo#81649
Fixes 2 issues:
Issue 1: wrong view shown when registering strict consumption
To reproduce:
- create tracked product to subcontract
- create subcontract BoM with no tracked components + strict consumption
- create receipt of subcontracted product (remember to select From =
subcontractor)
- click on `action_show_details` burger button in Operations
Expected result:
- Detailed Operations window with no move lines in it (i.e.
stock.view_stock_move_nosuggest_operations view)
Actual Result:
- Detailed Operations window with move lines w/ 0 Done
(i.e. stock.view_stock_move_operations view _ lines also do
not get filled in when using the `action_assign_serial_show_details`,
=> twice as many lines as needed end up in view)i
Similar issue can occur when using a non-strict BoM + tracked product.
Issue appears to be that conditional was incorrectly updated during
refactoring to allow non-strict BoMs also record components.
stock.view_stock_move_operations view should only appear when all
productions are recorded
Issue 2: Consumption warning wizard not showing correctly
To reproduce:
- same as Issue 1, except consume less than BoM amount
Expected result: Consumption Wizard
Actual Result: stock move view shown instead
Issue was due to 'form_view_ref' value in context of picking view,
therefore we force clear this value everytime we expect this wizard
to open.
Task: 2695173
X-original-commit: b9990a5dab8731a8f69fd07aa73a318fc9d4a808
Part-of: odoo/odoo#81649
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
stdout:
stderr:
13:41:03.985365 git.c:344 trace: built-in: git cherry-pick 20858c2a8805d9ec08edb98b090badf6c73fc342
error: Cherry-picking is not possible because you have unmerged files.
hint: Fix them up in the work tree, and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: cherry-pick failed
----------
status:
closesodoo/odoo#79933
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Previous task: odoo/odoo#61287 improved warnings for when using a
duplicate SN, including an auto-update of the source location when
appropriate. Unfortunately the auto-update is too risky when registering
a subcontracting SN tracked components.
Instead, we no longer update the source location when in a
subcontracting situation and update the warning message to match the
expected flow to fix the issue.
closesodoo/odoo#79334
Task: 2669180
X-original-commit: a430c4d7d6e2a02ef9b3905b554a779fc1643bcf
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
In case you use products with variants or internal references, display_name is more specific than name.
closesodoo/odoo#79191
X-original-commit: c46328315a8db2f579329a8a44c23fd4769e7d44
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit fixes the 'You need to supply a Lot/Serial Number...' message
when validating a receipt with backorder for subcontracted tracked products.
closesodoo/odoo#79121
Task: 2604664
X-original-commit: 2ab8f5cc681d45323e540ca57f85168fd587cf02
Signed-off-by: Tiffany Chang <tic@odoo.com>
When validating a receipt, if the product is subcontracted and if the
picking is not fully done, it will be impossible to create a backorder
To reproduce the issue:
1. Create two products P_compo, P_finished
- Both storable
- Both tracked by lot
- P_compo must have the route "Resupply Subcontractor on Order"
2. Update P_compo's quantity: 4
3. Create a BoM:
- Product: P_finished
- BoM type: Subcontracting
- Subcontractors: a partner P
- Components: 1 x P_compo
4. In Inventory, create a planned transfer T:
- Operation Type: Receipt
- Receive From: P
- Operations: 4 x P_finished
5. Mark as Todo
6. Inventory > Delivery Orders, find the delivery of P_compo for P and
process it
7. Back to T, Record Components:
- Quantity: 3/4
- Set a Lot for P_finished
8. Validate T, Create Backorder
Error: a User Error is raised "You need to supply a Lot/Serial Number
for product: - P_finished"
Since P_finished is subcontracted, a related MO has been generated. On
step 7, when recording the used components, since all P_finished have
not been produced, a second MO is created for the last P_finished.
However, when validating T, both MOs are selected and validated. This is
an error since the user has not yet recorded the used components for the
last MO. The latter should not be validated.
OPW-2582538
closesodoo/odoo#78496
X-original-commit: 21068076b4a6b134f5f07c4c03de7c4eb37b4688
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
In the bom cost report template, a "tr" is missing and no parent_id for
the subcontructing part. This result in a leftover line each time you
fold the bom. Add them to the tamplate.
Task-2657280
X-original-commit: 6ae623dc2d5131e2b11969f1bc1f8dd6096a9005
Part-of: odoo/odoo#77945
Since return moves are linked to their original move, it's easy to
manage reservation in those case. We just don't bypass the reservation
when it comes from a reservation outside our stock in order to manage
the computation on linked moves and reserve pieces that were not yet
return.
Also add a return picking type for 2 reasons:
- Allow to select existing lot.
- Display reserved move line for an incoming picking.
Note that this picking type is just a default configuration and could be
modify by the user without any issue.
closesodoo/odoo#64384
Related: odoo/enterprise#20605
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Take in account the bom consumption of subcontracting BoM:
- In flexible and warning we can now record extra component
(even if there isn't tracked component).
- In the warning case, we get a warning issue in during the recording
of component if we consume more than expected
- In case of script consumption, we cannot record component expected
if some are tracked. In this case we can consume more than expected
only if the user is a mrp manager.
Also fix "Set quantities" Button for the subcontracting
task-2486811
closesodoo/odoo#75041
Related: odoo/enterprise#20350
Related: odoo/upgrade#2750
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The button "Set Quantity" have a different behavior
(it doesn't take in account tracked product) than
the immediate process which is confusing.
Now both flow share the same code and allow to avoid
the "Set Quantity" for the subcontracting with tracked component.
task-2486811
Part-of: odoo/odoo#75041
We cannot have byproduct in case of subcontracting,
raise a Error if we try (like operation). Also remove the
it from the subcontracted form (also clean empty space of it).
task-2486811
Part-of: odoo/odoo#75041
Tiffany Chang (tic)