[19.0][FIX] purchase_sale_stock_inter_company - fix "A lot/serial number is required for product..." when sync creating a lot-less stock.move.line for lot_valuated product - #1040
Open
cuongnmtm wants to merge 56 commits into
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.
…the origin company to the destination company The synchronization is done only when the picking is in the "Done" state because, before that, the lots are not yet synchronized.
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.
… purchase reception if it is a dropshipping To avoid adding an explicit dependency, check the picking type code when it is a dropship.
Create two dedicated functions to determine when it is an intercompany reception or an intercompany delivery, and use the same logic in multiple places. We used the locations to cover the dropshipping case and deliveries/receptions in multiples steps, and the respective many2one field to know if it is a purchase or sale intercompany transaction. We do not use the partner because a picking can be created manually using this contact, but the specific fields for intercompany transactions are the many2one fields.
…companies After this PR odoo/odoo#146458, Odoo allows shared lots between companies. This commit ensures that lots can be shared by clearing the company field if it is filled.
…cking_batch is installed - Force recomputation of the picking state based on the field intercompany_sale_order_id, which is set after the picking is created. - Add the stock.group_stock_user group to the user to ensure proper access rights.
…t locations between companies Currently, intercompany transactions are handled as follows: Sale order: from Stock to Customer Purchase order: from Vendors to Stock When using Dropshipping, the moves are: Sale order: from Stock to Customer Purchase order: from Vendors to Customer However, when using a product tracked by serial number, an error occurs because the same product cannot exist in the same location with the same lot, the lot is effectively entered twice into the customer location. To avoid this constraint, the movement of locations is now performed as follows: Standard flow: Sale order: from Stock to Intercompany Location Purchase order: from Intercompany Location to Stock With Dropshipping: Sale order: from Stock to Intercompany Location Purchase order: from Intercompany Location to Customer
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: multi-company-18.0/multi-company-18.0-purchase_sale_stock_inter_company Translate-URL: https://translation.odoo-community.org/projects/multi-company-18-0/multi-company-18-0-purchase_sale_stock_inter_company/
Currently translated at 100.0% (28 of 28 strings) Translation: multi-company-18.0/multi-company-18.0-purchase_sale_stock_inter_company Translate-URL: https://translation.odoo-community.org/projects/multi-company-18-0/multi-company-18-0-purchase_sale_stock_inter_company/it/
Currently translated at 100.0% (28 of 28 strings) Translation: multi-company-18.0/multi-company-18.0-purchase_sale_stock_inter_company Translate-URL: https://translation.odoo-community.org/projects/multi-company-18-0/multi-company-18-0-purchase_sale_stock_inter_company/it/
… move When the counterpart PO already has a done move, the sync copies it with `move_line_ids: False`. As the copy lands in a done picking, `stock.move.create` forces it to `done` and `stock_account` values its move lines from within their `create()`. Those lines are created without a lot, so on a `lot_valuated` product the valuation raises "A lot/serial number is required for product ...". This test reproduces that flow: a first delivery makes the receipt done, and a second delivery from the backorder then goes through the copy branch. It also checks the received quantity per lot and `qty_received`, so a lot cannot be received twice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… move When the counterpart PO already has a done move, the sync copies it with `move_line_ids: False`. That copy lands in a done picking, so `stock.move.create` forces it to `done` and `stock_account` values its move lines from within their `create()`. The lines were created without a lot, which makes `stock.move._set_value` raise "A lot/serial number is required for product ..." on a `lot_valuated` product -- a control that came with the new inventory valuation, in its current form since odoo/odoo d06959e3732286127795e4ee7fc3b2d4012312e5. Assigning the lot afterwards is too late, so the lines are now created with their lot from the start, mirrored from the delivery. A line whose quantity another line already covers ends up zeroed by the existing cleanup; it is harmless, as it carries neither quantity nor value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
OCA-git-bot
added
series:19.0
mod:purchase_sale_stock_inter_company
1 task done
|
this is the right PR migration? |
Contributor
Author
I believe you found the MIG PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The control is introduced here https://github.com/odoo/odoo/blame/d06959e3732286127795e4ee7fc3b2d4012312e5/addons/stock_account/models/stock_move.py#L309