Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

     SCENARIO

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 performedTransaction
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 VendorXK01
Link new Intercompany Logistic Vendor to new Finance Vendor before new PO can be issuedXK02
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 DataFB01, FB60
Create Purchase Info Records related to new Logistic VendorME11
Create Source ListME01
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 CustomerXD01
Link new financial Customer to new Intercompany logistic customer, before new SO can be issuedXD02
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

FB01, FB70

During the analysis phase, it is important to analyze the following aspects

Activity

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).

Labels in this area