I wanted to add a screenshot for clarity.

Hi @baris.halici 

I am not sure if it is possible to disconnect the purchase order from the customer order.

This is an intersite/intercompany process, right?

Why do you wan to disconnect it?

Hi @Link, 

An invoice for CO has been created/printed on the DENER Site. Later, the PO on the DENSE site was cancelled. Change request cannot be sent from PO since CO is billed.

It will be easier to match these records if I can disconnect them.

Once you cancel an intersite connected order, it actually creates a mess that is not easy to undo.  The rule is to always do the change management from the originating order.  If that is a PO-CO, then all the work should start from the PO.  If the chain is CO-PO-CO, then it should start from the first CO.  Starting a change or cancelling things in the middle or the end then creates a problem with any further updates or matching.  

I get pretty severe with users who don’t follow the established path, often the mess can take more than half an hour to clean up.  It can occasionally require additional orders to fill in the missing items or to clear up inventory or to allow the PO to finish or whatever.  The amount of cleanup really depends on the status of real physical inventory and financial position.  There isn’t a quick easy fix like unpegging when something has been delivered or cancelled as it looks like the situation you have.

Hi @ShawnBerk,

Thanks for your answer. I agree with what you said.
From this I understand that we cannot unpeg the connection between the two companies.

I would like to describe the scenario where I could not find a solution.
X source company.
Y is the target company.
I created a five rows PO in company X. And I sent the message.
CO occurred for the same five rows in company Y.
I delivered the first row in company Y. And I billed.
I canceled the first row in company X. I submitted the change request.
The change request could not be sent because the first line in company Y has been billed. And I got error.

I think the two rows need to be disconnected/unpeg before I can fix this problem. Of course this is just a thought.
What do you think could be the solution?

Regards

Barış

Hi,

from my point of view when you delivered and created the invoice in Site X then you have to book the PO receipt in site X. You can’t unpeg the objects.

The site X must then create a supplier return to the site Y (even though maybe the goods are still in the warehouse of site Y, because they have not been physically delivered yet).

Site Y receives the returned parts via an RMA (even though maybe they are still in the warehouse of site Y, because they have not been physically delivered) and creates a credit note for the customer in Site X.

Then the process is fine.

BR,

Martin

I delivered the first row in company Y. And I billed.
I canceled the first row in company X. I submitted the change request.
The change request could not be sent because the first line in company Y has been billed. And I got error.

There is no solution to this scenario because it isn’t a valid condition.  If the delivery was completed in Company Y, the same row should never be cancelled in Company X AFTER the delivery.  That creates an impossible condition that can’t be fixed using either of those orders.  If it was necessary to cancel the line in Company X, it has to be done before the same row in Company Y has made it to the Picked status, let alone Delivered, else there will be errors on the Send Change Order operation.

As @Martin Falkenau has explained, it now can only be fixed by doing other transactions.

As for me, I can’t understand the initial scenario that would require the operations. If it were me, I wouldn’t cancel the PO line.  I would receive the PO line, complete all of the transactions in Company X as normal, then if the item wasn’t needed, go through the return process to send it back to Company Y.  That makes for a much cleaner matching scenario.  Unpegging isn’t going to fix any of the issues you are describing.

Hi @ShawnBerk , @Martin Falkenau , @Link ,

Thanks for the replies. These answers are enough for me.

Regards

Barış