[16.0][IMP] purchase_sale_stock_inter_company: make pickings link configurable

[ghost]

This changes implement a configuration in the intercompany processes to determine whether the automatic processing of incoming shipments applies or not. By default, it should be disabled to allow independent management of shipments.

[jaainavarro]

I have tested this feature in runbot. When you have the check "Link Purchase and Sale Pickings" activated, whenever you have intercompany transactions, these are linked. I have tried buying a product from My company (San Francisco) to My company (Chicago). When I create the purchase order on SF, a sale quotation is created on Chicago. When I create a backorder for the delivery, automatically this is translated to my purchase order in SF (moving to done the first receipt and creating a new partial reception with the remaining units)

Odoo.-.P00012.mp4

With the new feature, you can deactivate the check "Link Purchase and Sale Pickings" so that one move is independent from the other. This is useful if you want to have full trace of your receptions and you don´t want things confirming on its own. I have done the same process as before, but without the check.

Odoo.-.P00013.1.mp4

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[giarve]

Unfortunately because the module is auto_install this is needed for some business cases.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[giarve]

After some trial time, my solution wouldn't be company-wide. Specifically for distinguishing Dropship uses cases (where you might want automated validation) vs warehouse reception (where you want to receive manually as you want to track stock with proper reception dates and not when it is sent from the vendor, otherwise it fakes current on hand stock and reception date).

Might be better to add it in the stock.picking.type model to fetch it from there.

[xAdrianCif]

hi @pedrobaeza could we merge these changes? thanks!

[pedrobaeza]

@carlos-lopez-tecnativa can you check it?

[carlos-lopez-tecnativa]

I think this feature is already present in v17+ in a normalized way. Could you backport this feature from v17 instead of reworking it from scratch? You can take this PR as a starting point:
#856

The field name in v17 is different, but it is the same field name as in v14 because we forward-ported it during the migration to v17. Therefore, when thinking about the migration from v16 to v17, the best option is for this field to have the same name as in v14 and v17.

multi-company/purchase_sale_stock_inter_company/models/res_company.py

Lines 23 to 37 in 2a1b1d3

	sync_picking = fields.Boolean(
	string="Sync the receipt with the delivery",
	help="Sync the receipt from the destination company with the "
	"delivery from the source company",
	)
	sync_picking_failure_action = fields.Selection(
	SELECTION_SYNC_FAILURE_ACTIONS,
	string="On sync picking failure",
	default="raise",
	help="Pick action to perform on sync picking failure",
	)
	block_po_manual_picking_validation = fields.Boolean(
	string="Block manual validation of picking in the destination company",
	)
	notify_user_id = fields.Many2one("res.users", "User to Notify")

Is there any reason to use a different field name?

Suggested change

	link_purchase_sale_picking = fields.Boolean(
	sync_picking = fields.Boolean(