Intercompany trade route exit
The trade route is the flow of goods going from one object (the supplier) to another (the buyer).
In the multinational groups this is a frequent scenario: a plant supplies one or more companies in the same or different countries, with goods to be sold or used as component of another production line.
The two subjects, buyer and supplier, create each other as customer and / or vendor depending on the role played in the business trade (if they sell or buy).
Mostly, as I/C customers / vendors, a specific naming convention and data setting will be used in order to address correctly the postings and the final data consolidation.
Let’s imagine, as example, that a company in France, by one plant, supplies several countries (example: Italy, Colombia, Malaysia and Pakistan), and that the group headquarter decides to replace this supplier with another one, always part of the group, based in Netherlands, as per below picture:
Before the replacement of France with Netherlands, the French company has all of the four countries companies created as customers, while the four countries have the French company created as Vendor.
Before Day 1, when the supplying process will start from Netherlands, Italy, Colombia, Malaysia and Pakistan need to create Netherlands company as Vendor, and Netherlands the four supplied countries as customers. Of course if not all the players stay in the same SAP environment, the task will be performed in its own system / client (that can also be outside SAP).
The activities to be performed for the trade exit are the following:
|Activity – tasks to be performed||Transaction|
|Create the new Financial Vendor Master Data – the reconciliation account has to be coherent with the nature of the supplier (“Payables Intercompany own sector” or “Payables Intercompany other sector”||FK01,FK01|
|Create new Logistic Vendor||XK01|
|Link new Intercompany Logistic Vendor to new Finance Vendor before new PO can be issued||XK02|
|Migrate existing purchase orders to new vendors (if the PO doesn’t have already linked documents)||ME21N|
|Migrate open items to New Financial Vendor Master Data||FB01, FB60|
|Create Purchase Info Records related to new Logistic Vendor||ME11|
|Create Source List||ME01|
|Create new Financial Customer Master Data – the reconciliation account has to be coherent with the nature of the supplier (“Payables Intercompany Own Sector” or “Payables Intercompany Other Sector”)||FD01, XD01|
|Create New Intercompany Logistic Customer||XD01|
|Link new financial Customer to new Intercompany logistic customer, before new SO can be issued||XD02|
|Migrate existing Sales Orders to new Customers (if the SO doesn’t have already linked documents)||VA01|
|Migrate Open Items to new Financial Customer Master Data||
During the analysis phase, it is important to analyze the following aspects
Identify how many vendors / customers master data are used about the same supplier / customer.
It is possible, although not desirable, that the same Vendor / Customer has been created with more than one code for several reasons: previous carve out projects, errors, business split, etc. It is important to consider all the possible data to be migrated to the new master data
Identify the Purchase Orders and Sales Orders already with linked posted documents
Since the PO / SO is already shipped / in transit / to be invoiced, it is not recommendable to modify it, in order to not cause trouble / mismatch between thepaper documents used for shipping the goods and what is in the system. In this case it is better to complete the purchasing / sales process using the old master data, and then reclassify the financial document on the new vendor / customer.
|Identify the open items (AP / AR) to be reclassified|
Check if the master data (customers / vendors) are used in any (automatic) settings (IDOC, interfaces, validations, substitutions, etc.)
If so, it is recommendable the interfaces / IDOC / validations / substitutions with the new master data to be sure that the automatic work flow works properly, or the validation is correctly triggered, etc.
In case of Carve out / Sale of a division by a group, it is possible that temporary some companies run on the system of the previous owner, waiting to be migrated to the buyer’s system.
In this case maybe only part of the list of activities before mentioned has to be performed (only the Vendor or Customer part). In this case it can also make sense to not “touch” the logistic side (logistic Customer / Vendor, purchase info record, source list), and just create a new financial customer / vendor to be used to update the Sales Orders / Purchase Orders (in the “Payer” partner function) and migrate the financial open items.
This solution is based on the update of the partner functions within the SO / PO, as shown in the picture below for the PO:
In this case the Logistic Vendor (C03841) has not been changed / replaced with a new logistic vendor, and so no new Purchase Info records and Source Lists have been created. But a new financial Vendor (GK38_G2_11) has been created for the same subject and used to address the financial invoices (IR) to the correct vendor / reconciliation account. This choice has been motivated by the next migration of the divested division to the buyers platform. Changing all the logistic settings just for a short period of time during which the business keeps on running on the seller’s platform was not worth. The buyer accepted to have discrepancy between the logistic vendor name (the old hub – France, in the example) and the financial vendor name (the new hub – Netherlands, in the example).