Intercompany vendor master data – Business divisions management
The following document describes the usage of SAP Vendor Master data to manage the intercompany relationships between the several players within the same group.
The different companies, belonging to different divisions within the same group, to trade between them create each other as customers and / or vendors. naming convention and account settings are described with the goal of providing a possible approach for implementation / re-engineering of intercompany processes.
The following document reflects an implementation in the Pharma industry, but it is easily replicable in other industries.
The naming convention of the financial Customers and Vendors is used for the following reasons:
1) To identify the intercompany nature of the customer / vendor
2) To identify the country of the company
3) To identify the division of the customer / vendor
4) To report and consolidate the data of the division the customer / vendor belongs to
There can be 2 cases:
1) The supplier belongs to the same division of the company where the vendor is created (subject A supplies subject B – A and B belongs to the same division – B creates A as vendor)
The Vendor C026_63 belongs to the country C (C= Colombia or Switzerland – depending on the agreed naming convention – BE = Belgium, etc.) and to the division 63. The division is indicated by the code after the *_*. Both buyer and seller belong to the division “63”. Custom controls (user exit) can be set up in order to drive the respect of the correct naming convention).
2) The supplier belongs to a different division of the company where the vendor is created (subject A supplies subject B – And B belong to a different division – B creates A as vendor)
The Vendor C025_63_11 (of country C = Switzerland or Colombia, depending on the agreed naming convention) belongs to the division “63”, while the buyer, meaning the company where the vendor is created, belongs to the division “11”.
Depending on the role played in the business process (supplier or demander) the companies are created as Vendors and / or Customers in the companies they deal with.
For the following reasons, the same company is created as Vendor twice, once as “Logistic Vendor” and once as “Financial Vendor”:
1) All the logistic settings (Purchase Info Record / Source Lists) are referred to the logistic vendor so, in case of any change of the financial vendor, it is not necessary to recreate them;
2) maybe the trade route can change. using the business partner functions available at Purchase Organization level, it is possible to replace one or more of the master data involved as “Ordering address”, “Manufacturer” or “Payer” without touching the logistic settings.
The same subject is created twice. It is then advisable to use two different accounting groups, in order to manage both the different information needs (different layout of the master data, different mandatory / hidden fields to fill / display) and to clearly recognize and distinguish the role played.
To remind that the logistic vendor must not be created at company code level, since supposed to be used only for Purchase Order management. the financial vendor will be created at company code level since used for the finance document creation (Invoice receipt, credit memo)
Below an example:
1) Logistic vendor
The code of the vendor is CH108 – CH is the country of residence of the vendor, while 108 just a progressive number (or can be differently used according to what needed)
The account group is Intercompany Plant
The logistic vendor is created only at general and Purchase Organization level (not at company code level). This to allow creation of Purchase Order and avoid creation of financial documents
2) Financial Vendor
The financial vendor code is XXXX_63
The account group is Intercompany Finance
The financial vendor is created at company code level to be used for finance document creation in the Purchase Order process (invoice, credit memo)
To display the Vendor master Data run transaction XK03:
Fill “Vendor”, “Purchase Organization” and flag the box “Partner functions”.
About the Purchase Organization, the naming also helps to indicate this is an intercompany purchase organization (ICP1 / ICP2 = Inter Company Purchase Organization), different from the country Purchase Organization (XX01, where XX is the country).
In this case the choice has been to use the same logistic vendor (CH0108 – Account group Intercompany Plant) to play all the roles but the financial payer (PI – Invoice presented by), played by C026_63 (account group Intercompany Finance). This means when a Purchase Order (shortly PO) is created against the logistic vendor CH0108, automatically all the partner functions are populated within the partners tab. of the PO itself with the setting available in the CH0108 master data, as in the picture below:
All the logistic objects here required (Source list, Purchase Info record) are created with reference to the vendor CH0108.
Since Vendor C026_63 is used for the partner function PI – Invoice presented by, the IR (Invoice receipt) created for this PO will be directly addressed to this master data, meaning the financial document will use C026_63 as vendor.
Being C026_63 indicated in CH0108 master data as “Payer” will be defaulted as “PI” in the Purchase Order partner function tab. It is however possible to replace it with another one that will work as financial vendor for the specific PO case.
What indicated in the logistic vendor master data as partner function is just a default for the purchase order, so it can be updated directly there without “changing” the vendor master data.
It is important to remember the reconciliation account of the intercompany vendor must be appropriate;
In case of Vendor XXXX_DD (where DD is the division), the reconciliation account will be 410000 – Intercompany own sector, while in case of Vendor XXXX_DD_YY (where YY is a division different from DD), the reconciliation account will be 410100 – Intercompany other sector.
The Vendor partner functions are available in the table WYT3, as shown below:
It is important to remember that the partner functions here displayed under column “Funct” have different codes from those displayed in the user transactions:
For example, RS is actually PI (invoice presented by), as shown below: