[17.0][MIG] purchase_sale_stock_inter_company: Migration to version 17.0#856
Conversation
Update v14 latest changes and test cases
…product_qty in stock.move.line
Currently translated at 100.0% (10 of 10 strings) Translation: multi-company-16.0/multi-company-16.0-purchase_sale_stock_inter_company Translate-URL: https://translation.odoo-community.org/projects/multi-company-16-0/multi-company-16-0-purchase_sale_stock_inter_company/es/
Currently translated at 90.0% (9 of 10 strings) Translation: multi-company-16.0/multi-company-16.0-purchase_sale_stock_inter_company Translate-URL: https://translation.odoo-community.org/projects/multi-company-16-0/multi-company-16-0-purchase_sale_stock_inter_company/it/
Currently translated at 100.0% (10 of 10 strings) Translation: multi-company-16.0/multi-company-16.0-purchase_sale_stock_inter_company Translate-URL: https://translation.odoo-community.org/projects/multi-company-16-0/multi-company-16-0-purchase_sale_stock_inter_company/it/
…ation logic for inheritance in purchase_sale_stock_inter_company_mrp
…roducts Imagine you have a customization that enables the split of a stock move into several moves (distributed in several pickings). Thus, we need to handle this case.
Previously an intercompany picking with tracked products would simply throw an error. With this fix, the method searches for a lot in the destination company that matches the one in the source company (same name and same product). A new lot is created by duplicating the original, if none is found.
This commit fixes a bug that occurred when the intercompany PO/SO and therefore the pickings had multiple lines of the same product. In that case, the quantities done would not be synced correctly, but rather the larger quantity would be applied to all destination moves. The receiving company would receive more product than was ordered in the PO.
…can have more than one record
… intercompany transfer
…company_ids will be empty and the picking will not sync. Use sale_id.partner_id instead.
When an incomplete sale order is delivered and "No backorder" is chosen, SO moves split in two while PO stays the same. Aggregating writes per each PO move makes sure qty does not get overwritten. Usually second qty is zero so the destination move becomes quantity zero and the picking was even cancelled.
A number of things can go wrong in trying to confirm the PO picking when the SO picking is confirmed. Instead of raising an error and thereby blocking the confirm of the SO picking, provide an option by which the exception can be caught. The SO picking will still be confirmed, but an activity will be posted for someone to deal with the PO picking manually.
Before this commit, if the company selling had setup 2- or 3-step deliveries on its warehouse, 2 or 3 receipts would be created on the PO side. When synchronizing, we only need to consider the final outgoing picking, and not the intermediate pickings.
|
/ocabot migration purchase_sale_stock_inter_company |
|
|
||
| @api.model | ||
| def _get_fields_to_sync_intercompany(self): | ||
| return {"qty_done", "lot_id"} |
There was a problem hiding this comment.
What about package_id and dest_package_id?
There was a problem hiding this comment.
I think this is out of scope for this module. These fields are many2one, so it's necessary to implement the logic to search or create the corresponding records in the other company. This is not supported in any version. Please confirm if I should add this support here or after the migration process.
There was a problem hiding this comment.
I think the same happens with lot_id. Not sure if stock.quant.package can have company_id empty, so you can assign it directly. If not, just put the comment in the roadmap.
There was a problem hiding this comment.
According to this code, the company_id is computed based on the stock.quant:
https://github.com/odoo/odoo/blob/e07ff7fab04a3536187b8ab0facbd17236754fae/addons/stock/models/stock_quant.py#L1489-L1494
and in turn, it is related to the location:
https://github.com/odoo/odoo/blob/e07ff7fab04a3536187b8ab0facbd17236754fae/addons/stock/models/stock_quant.py#L58
So, internal locations always have a company set (it can be empty, but normally it has a company).
I added this to the roadmap.
There was a problem hiding this comment.
@carlos-lopez-tecnativa FYI, It seems stock_intercompany_bidirectional in 16.0 is managing packages...
There was a problem hiding this comment.
@carlos-lopez-tecnativa FYI, It seems stock_intercompany_bidirectional in 16.0 is managing packages...
I tested this module, but I think it’s not working as expected.
I created a new picking and set the package:
When I validate the picking in C1, the package is lost (more specifically, it is transferred to the picking in C2), but in C1 I don't see the package anymore. I'm not sure if it's completely correct.
Have you tested this module?
There was a problem hiding this comment.
I must admit I didn't test it and didn't look at the code either... Just read the description while looking for a solution to manage lots in inter-company pickings.
carlos-lopez-tecnativa
force-pushed
the
17.0-mig-purchase_sale_stock_inter_company
branch
3 times, most recently
from
1511e38 to
ca62f3d
Compare
purchase_sale_stock_inter_company/tests/test_inter_company_purchase_sale_stock.py
Outdated
Show resolved
Hide resolved
|
This is amazing work, thanks @carlos-lopez-tecnativa I gathered every PR for versions 14.0, 15.0 and 16.0 and a lot are already there. Only some questions and remarks :
That's all ! |
Just changing these fields to make it easier to test the module. Technically a bug in "stock" module's demo data. Contact Jeff Lawson is also the "address" of warehouse "Chicago 1". The fields property_stock_customer and supplier are set to "Inter-warehouse transit" on Jeff Lawson for company San Francisco and not for company Chicago as it should be. Since there are no routes set for location "Inter-warehouse transit", creating an inter-company PO from Chicago to SF fails; when the inter-company SO is automatically created, with delivery address towards the Chicago Warehouse i.e. Jeff Lawson, the creation of the SO's picking fails as there is no route available.
…r test - Function _approve_po: allow passing purchase_to_approve - Function _create_purchase_order: allow passing products
carlos-lopez-tecnativa
force-pushed
the
17.0-mig-purchase_sale_stock_inter_company
branch
from
ca62f3d to
8ff490b
Compare
According to this comment, the PR does not affect the tests, so I cherry-picked the commit. Thanks!
As for whether we should include In version 14.0, So this feature (and related commits like this one) was not cherry-picked. If you understand this change and believe it must be included, please provide more context. Additionally, the test test_sync_picking_different_product_multiple_lines in the referenced PR does not include any assertion. It only creates data, so from my point of view, this test is incomplete.
This was originally included, but I later adapted it during the “Finish migration to version 17.0” commit, since it’s no longer applicable. In V14, the logic was handled in button_validate, but in V17, it now resides in action_done, and in this case, it's handled via 
The function Could you please update PR #844 to reference this PR and verify if it's OK? |
OK, sorry, I searched for However, I think that we have an issue here to detect pickings that should trigger synchronization.
You're right, I searched for
I'll do that and let you know, but I can already approve this PR. Thanks again ! |
|
This PR has the |
|
/ocabot merge nobump |
|
What a great day to merge this nice PR. Let's do it! |
|
Congratulations, your PR was merged at 4e95605. Thanks a lot for contributing to OCA. ❤️ |
20 participants
Supersedes #605
TT54931
@Tecnativa @pedrobaeza @cuongnmtm @pomazanbohdan @metaminux @JordiMForgeFlow could you please review this?