1.1 Introduction
Along with vendors and materials, the customer master is one of the key master data objects to be loaded as part of a SAP migration. The customer data will be very important to your client's business and, as a result, you need to make sure that you get the data correct in this area. This white paper will look at some of the different aspects of the customer master and some of the main issues that arise when trying to migrate data into an SAP system.
1.2 Assumptions
The best approach to loading customer master into SAP is via LSMW using either the standard load program RFBIDE00 or the customer master IDOC or BAPI.
2 Discussion Points
2.1 Address Data
One of the main attributes of the customer is the address data. This is important for delivering goods to the correct place, billing the correct company, etc. As part of migration, the address data is often found to be inconsistent in the legacy system through years of maintenance by different users. A migration is a good time to review and improve such data. This is known as "data cleansing". It is normally best practice for the cleansing to occur in the legacy database prior to the migration so that the migration is a clean and transparent as possible. Examples of inconsistencies might be:
- The Address city may be "Kiev" in some addresses, in others, "Kv" - Some telephone numbers may have brackets around the area code, others may not - Some addresses may be missing a postal code which isn't mandatory in the legacy system but which may be in SAP
As data cleansing often involves heavy user interaction, it's often beneficial to look at ways in which the migration team can help, eg. using an ABAP routine within the LSMW to format the telephone numbers correctly. Another option might be to use a middleware system such as DataStage or Informatica, but this will be discussed in a separate paper. The best method for loading customer master data is by using the LSMW tool with the standard program RFBIDE00 which creates a BDC session to be processed.
Some extended address data (held in table ADRC) is not found in the standard structures for this program but this is easily solved by creating a simple recording which can populate up the missing fields. Another LSMW option is to use the BAPI which creates customer master IDOCs in the DEBMAS structure. This option is also flexible and benefits from being based on SAP standard programs, but the IDOC processing is less transparent than the BDC and it is rather slow when processing large volumes of data. Also note that even though many of the address fields for customer master are length 40 (or more in later versions) you should not use more than 35 as many SAP standard programs only look at the first 35.
2.2 Legacy Customer Number
Often when migrating customer master from a legacy system to SAP, there will be an legacy customer ID. In a simple migration you may be able to bring this legacy number into SAP as the main SAP number (KNA1-KUNNR) but this is often not possible due to number range clashes, or not desirable as it will not fit into the range determined for future customers.
In this case it is customary to store the old number in another field on the customer master for the following reasons:
1. The users may like to have the security of knowing that the legacy ID is not completely erased. They can search for their customers based on their legacy IDs while they get used to the new system.
2. It is useful to have the legacy number stored as part of an initial load of customers so that when subsequent update loads take place (e.g. adding extra data using a recording or updating the partner functions), these update programs will have a way of identifying the SAP customers.
3. Apart from update loads, there are also other dependent objects such as pricing conditions, sales orders and open AR items where your source file will normally reference the old legacy IDs. SAP has provided a field called "Previous Account Number" (KNB1-ALTKN) stored at the company code level. This is where you would commonly store the legacy number. This works even on multi-country projects where the same customer may exist in different legacy systems, because the field is at company code level.
If it is not sufficient due to multiple legacy customers in the same company code pointing to one customer, you may need to consider other options such create a custom table or using multi-value characteristics in customer classification. The person responsible for building the LSMW load program should also create a routine which enables other loads to find the new SAP customer for a given ID by interrogating the chosen field.
2.3 Partner Types Be aware of the SD configuration surrounding customers, specifically the Account Group settings. How many Account Groups are to be configured in the new system and how many account groups need to be loaded as part of the migration? The fewer the better for load simplicity. A sold to party will have one Account Group, a ship to party will have another account group. The customer master screens can be configured differently depending on the account group. For instance a bill to party customer will not have a sales organisation screen and a ship to will not have any finance data.
You need to cater for these differences in your LSMW field population. Sometimes, it is possible to simplify the process. For example, it is possible to create all the customers with one account group - Sold To and when it comes to loading the sales orders, if the delivery address is different from the sold to address then you can reflect that difference in the delivery address of the sales order. If you are loading partner relationships, this is normally done in a second step after the creation of the main data. You may need to work some partners into your initial load if they have been configured as mandatory.
2.4 Multiple Company Codes and Sales Areas
A simple migration will contain just one company code and one sales area per customer. But sometimes (especially in multi-country rollouts), there are multiple company codes and sales organisations. If this is the case, then best practice will involve careful examination of the source structure. Data normalisation dictates that it is best in this situation to separate input files depending on the data. So you would have one file for the basic data (KNA1), one file for the company code data (KNB1) and one for the sales organisation data (KNVV).
For example:
2.4.1 Basic File ID Name Street City Country FR12 Acme Ltd 9 Roman Road London UK
2.4.2 Company Code File ID Company Code Account Assignment Group Sort Key FR12 GB01 A1 001 FR12 GB02 A5 005
2.4.3 Sales Organisation File ID Sales Org Dist Channel Division Sales Office FR12 GBX7 01 01 AB1 FR12 GBX6 01 01 AC3
You would assign these files to the different segments in the target structures of the standard program input within the LSMW. Note that the Sales Area could be further broken down in more complex projects so that there are multiple distribution channels and divisions per sales org, in which case this file structure would still hold. Also, remember that one feature of a normalised system such as SAP is that customer-dependent data will pull through information from the customer master. Many of the fields on the customer master are shared with the sales order object for instance.
So when a user is creating a sales order manually then they don't have to type a lot of the information each time; they type in the customer and that brings in a whole wealth of information into the order automatically. (This is the same with materials and vendors, e.g. purchase orders and goods movement documents). Bear this in mind when mapping data. It may be that a default is made in the customer and isn't that important because it is going to be altered in the dependent sales order e.g. some shipping information.
2.5 Bank Master
It is rare that you would enter bank details for a customer (this being more relative for vendor payments) however it is worth noting that there is a special feature of the customer and vendor masters is that if a bank key and country combination is entered on the bank screen within the customer and this bank does not exist in SAP (in master table BNKA) then SAP allows you to create the bank master record at the same time as creating the customer relationship to it. So you must be careful when creating your customers that you do not unintentionally create a number of bank records at the same time. Nevertheless allowing the customer and vendor loads to do this can be a legitimate method of creating the banks (if done intentionally) rather than by developing a separate load program. The bank master is a small object with only one mandatory field (bank name) apart from the primary key.
2.6 Reporting
Often on a project the sales group and sale office set up is a key reporting feature that impacts directly on the loading of customers. It is advisable to speak to the functional consultants and business early to ascertain whether the structure has been defined and how the customers can be mapped to the structure. Other fields used for reporting include the customer group fields: customer group 1, customer group 2 etc, which can be customised according to the client's requirements.
3 Footnote
Customer Master migrations, as with all aspects of an SAP project will vary from client to client. There are inevitably data load requirements specific to your own project.
Along with vendors and materials, the customer master is one of the key master data objects to be loaded as part of a SAP migration. The customer data will be very important to your client's business and, as a result, you need to make sure that you get the data correct in this area. This white paper will look at some of the different aspects of the customer master and some of the main issues that arise when trying to migrate data into an SAP system.
The best approach to loading customer master into SAP is via LSMW using either the standard load program RFBIDE00 or the customer master IDOC or BAPI.
2 Discussion Points
2.1 Address Data
One of the main attributes of the customer is the address data. This is important for delivering goods to the correct place, billing the correct company, etc. As part of migration, the address data is often found to be inconsistent in the legacy system through years of maintenance by different users. A migration is a good time to review and improve such data. This is known as "data cleansing". It is normally best practice for the cleansing to occur in the legacy database prior to the migration so that the migration is a clean and transparent as possible. Examples of inconsistencies might be:
- The Address city may be "Kiev" in some addresses, in others, "Kv" - Some telephone numbers may have brackets around the area code, others may not - Some addresses may be missing a postal code which isn't mandatory in the legacy system but which may be in SAP
As data cleansing often involves heavy user interaction, it's often beneficial to look at ways in which the migration team can help, eg. using an ABAP routine within the LSMW to format the telephone numbers correctly. Another option might be to use a middleware system such as DataStage or Informatica, but this will be discussed in a separate paper. The best method for loading customer master data is by using the LSMW tool with the standard program RFBIDE00 which creates a BDC session to be processed.
Some extended address data (held in table ADRC) is not found in the standard structures for this program but this is easily solved by creating a simple recording which can populate up the missing fields. Another LSMW option is to use the BAPI which creates customer master IDOCs in the DEBMAS structure. This option is also flexible and benefits from being based on SAP standard programs, but the IDOC processing is less transparent than the BDC and it is rather slow when processing large volumes of data. Also note that even though many of the address fields for customer master are length 40 (or more in later versions) you should not use more than 35 as many SAP standard programs only look at the first 35.
2.2 Legacy Customer Number
Often when migrating customer master from a legacy system to SAP, there will be an legacy customer ID. In a simple migration you may be able to bring this legacy number into SAP as the main SAP number (KNA1-KUNNR) but this is often not possible due to number range clashes, or not desirable as it will not fit into the range determined for future customers.
In this case it is customary to store the old number in another field on the customer master for the following reasons:
1. The users may like to have the security of knowing that the legacy ID is not completely erased. They can search for their customers based on their legacy IDs while they get used to the new system.
2. It is useful to have the legacy number stored as part of an initial load of customers so that when subsequent update loads take place (e.g. adding extra data using a recording or updating the partner functions), these update programs will have a way of identifying the SAP customers.
3. Apart from update loads, there are also other dependent objects such as pricing conditions, sales orders and open AR items where your source file will normally reference the old legacy IDs. SAP has provided a field called "Previous Account Number" (KNB1-ALTKN) stored at the company code level. This is where you would commonly store the legacy number. This works even on multi-country projects where the same customer may exist in different legacy systems, because the field is at company code level.
If it is not sufficient due to multiple legacy customers in the same company code pointing to one customer, you may need to consider other options such create a custom table or using multi-value characteristics in customer classification. The person responsible for building the LSMW load program should also create a routine which enables other loads to find the new SAP customer for a given ID by interrogating the chosen field.
2.3 Partner Types Be aware of the SD configuration surrounding customers, specifically the Account Group settings. How many Account Groups are to be configured in the new system and how many account groups need to be loaded as part of the migration? The fewer the better for load simplicity. A sold to party will have one Account Group, a ship to party will have another account group. The customer master screens can be configured differently depending on the account group. For instance a bill to party customer will not have a sales organisation screen and a ship to will not have any finance data.
You need to cater for these differences in your LSMW field population. Sometimes, it is possible to simplify the process. For example, it is possible to create all the customers with one account group - Sold To and when it comes to loading the sales orders, if the delivery address is different from the sold to address then you can reflect that difference in the delivery address of the sales order. If you are loading partner relationships, this is normally done in a second step after the creation of the main data. You may need to work some partners into your initial load if they have been configured as mandatory.
2.4 Multiple Company Codes and Sales Areas
A simple migration will contain just one company code and one sales area per customer. But sometimes (especially in multi-country rollouts), there are multiple company codes and sales organisations. If this is the case, then best practice will involve careful examination of the source structure. Data normalisation dictates that it is best in this situation to separate input files depending on the data. So you would have one file for the basic data (KNA1), one file for the company code data (KNB1) and one for the sales organisation data (KNVV).
For example:
2.4.1 Basic File ID Name Street City Country FR12 Acme Ltd 9 Roman Road London UK
2.4.2 Company Code File ID Company Code Account Assignment Group Sort Key FR12 GB01 A1 001 FR12 GB02 A5 005
2.4.3 Sales Organisation File ID Sales Org Dist Channel Division Sales Office FR12 GBX7 01 01 AB1 FR12 GBX6 01 01 AC3
You would assign these files to the different segments in the target structures of the standard program input within the LSMW. Note that the Sales Area could be further broken down in more complex projects so that there are multiple distribution channels and divisions per sales org, in which case this file structure would still hold. Also, remember that one feature of a normalised system such as SAP is that customer-dependent data will pull through information from the customer master. Many of the fields on the customer master are shared with the sales order object for instance.
So when a user is creating a sales order manually then they don't have to type a lot of the information each time; they type in the customer and that brings in a whole wealth of information into the order automatically. (This is the same with materials and vendors, e.g. purchase orders and goods movement documents). Bear this in mind when mapping data. It may be that a default is made in the customer and isn't that important because it is going to be altered in the dependent sales order e.g. some shipping information.
2.5 Bank Master
It is rare that you would enter bank details for a customer (this being more relative for vendor payments) however it is worth noting that there is a special feature of the customer and vendor masters is that if a bank key and country combination is entered on the bank screen within the customer and this bank does not exist in SAP (in master table BNKA) then SAP allows you to create the bank master record at the same time as creating the customer relationship to it. So you must be careful when creating your customers that you do not unintentionally create a number of bank records at the same time. Nevertheless allowing the customer and vendor loads to do this can be a legitimate method of creating the banks (if done intentionally) rather than by developing a separate load program. The bank master is a small object with only one mandatory field (bank name) apart from the primary key.
2.6 Reporting
Often on a project the sales group and sale office set up is a key reporting feature that impacts directly on the loading of customers. It is advisable to speak to the functional consultants and business early to ascertain whether the structure has been defined and how the customers can be mapped to the structure. Other fields used for reporting include the customer group fields: customer group 1, customer group 2 etc, which can be customised according to the client's requirements.
3 Footnote
Customer Master migrations, as with all aspects of an SAP project will vary from client to client. There are inevitably data load requirements specific to your own project.
Seeking for SAP B1 Hana, check out Alenu Group.
No comments:
Post a Comment