Migrating Customer Master Into SAP - A Harlex Guide

1 OverviewSAP customer for a given ID by interrogating the
1.1 Introductionchosen field.
Along with vendors and materials, the customer2.3 Partner Types Be aware of the SD
master is one of the key master data objects toconfiguration surrounding customers, specifically
be loaded as part of a SAP migration. Thethe Account Group settings. How many Account
customer data will be very important to yourGroups are to be configured in the new system
client's business and, as a result, you need toand how many account groups need to be loaded
make sure that you get the data correct in thisas part of the migration? The fewer the better
area. This white paper will look at some of thefor load simplicity. A sold to party will have one
different aspects of the customer master andAccount Group, a ship to party will have another
some of the main issues that arise when trying toaccount group. The customer master screens can
migrate data into an SAP system.be configured differently depending on the
1.2 Assumptionsaccount group. For instance a bill to party
The best approach to loading customer mastercustomer will not have a sales organisation screen
into SAP is via LSMW using either the standardand a ship to will not have any finance data. You
load program RFBIDE00 or the customer masterneed to cater for these differences in your
IDOC or BAPI.LSMW field population. Sometimes, it is possible to
2 Discussion Pointssimplify the process. For example, it is possible to
2.1 Address Datacreate all the customers with one account group -
One of the main attributes of the customer is theSold To and when it comes to loading the sales
address data. This is important for deliveringorders, if the delivery address is different from
goods to the correct place, billing the correctthe sold to address then you can reflect that
company, etc. As part of migration, the addressdifference in the delivery address of the sales
data is often found to be inconsistent in theorder. If you are loading partner relationships, this
legacy system through years of maintenance byis normally done in a second step after the
different users. A migration is a good time tocreation of the main data. You may need to work
review and improve such data. This is known assome partners into your initial load if they have
"data cleansing". It is normally best practice forbeen configured as mandatory.
the cleansing to occur in the legacy database prior2.4 Multiple Company Codes and Sales Areas
to the migration so that the migration is a cleanA simple migration will contain just one company
and transparent as possible. Examples ofcode and one sales area per customer. But
inconsistencies might be:sometimes (especially in multi-country rollouts),
- The Address city may be "Kiev" in somethere are multiple company codes and sales
addresses, in others, "Kv" - Some telephoneorganisations. If this is the case, then best
numbers may have brackets around the areapractice will involve careful examination of the
code, others may not - Some addresses may besource structure. Data normalisation dictates that
missing a postal code which isn't mandatory in theit is best in this situation to separate input files
legacy system but which may be in SAPdepending on the data. So you would have one
As data cleansing often involves heavy userfile for the basic data (KNA1), one file for the
interaction, it's often beneficial to look at ways incompany code data (KNB1) and one for the sales
which the migration team can help, eg. using anorganisation data (KNVV). For example:
ABAP routine within the LSMW to format the2.4.1 Basic File ID Name Street City Country FR12
telephone numbers correctly. Another optionAcme Ltd 9 Roman Road London UK
might be to use a middleware system such as2.4.2 Company Code File ID Company Code
DataStage or Informatica, but this will beAccount Assignment Group Sort Key FR12 GB01
discussed in a separate paper. The best methodA1 001 FR12 GB02 A5 005
for loading customer master data is by using the2.4.3 Sales Organisation File ID Sales Org Dist
LSMW tool with the standard program RFBIDE00Channel Division Sales Office FR12 GBX7 01 01
which creates a BDC session to be processed.AB1 FR12 GBX6 01 01 AC3
Some extended address data (held in tableYou would assign these files to the different
ADRC) is not found in the standard structures forsegments in the target structures of the standard
this program but this is easily solved by creating aprogram input within the LSMW. Note that the
simple recording which can populate up the missingSales Area could be further broken down in more
fields. Another LSMW option is to use the BAPIcomplex projects so that there are multiple
which creates customer master IDOCs in thedistribution channels and divisions per sales org, in
DEBMAS structure. This option is also flexible andwhich case this file structure would still hold. Also,
benefits from being based on SAP standardremember that one feature of a normalised
programs, but the IDOC processing is lesssystem such as SAP is that customer-dependent
transparent than the BDC and it is rather slowdata will pull through information from the
when processing large volumes of data. Also notecustomer master. Many of the fields on the
that even though many of the address fields forcustomer master are shared with the sales order
customer master are length 40 (or more in laterobject for instance. So when a user is creating a
versions) you should not use more than 35 assales order manually then they don't have to type
many SAP standard programs only look at thea lot of the information each time; they type in
first 35.the customer and that brings in a whole wealth of
2.2 Legacy Customer Numberinformation into the order automatically. (This is
Often when migrating customer master from athe same with materials and vendors, e.g.
legacy system to SAP, there will be an legacypurchase orders and goods movement
customer ID. In a simple migration you may bedocuments). Bear this in mind when mapping data.
able to bring this legacy number into SAP as theIt may be that a default is made in the customer
main SAP number (KNA1-KUNNR) but this is oftenand isn't that important because it is going to be
not possible due to number range clashes, or notaltered in the dependent sales order e.g. some
desirable as it will not fit into the rangeshipping information.
determined for future customers. In this case it is2.5 Bank Master
customary to store the old number in anotherIt is rare that you would enter bank details for a
field on the customer master for the followingcustomer (this being more relative for vendor
reasons:payments) however it is worth noting that there
1. The users may like to have the security ofis a special feature of the customer and vendor
knowing that the legacy ID is not completelymasters is that if a bank key and country
erased. They can search for their customerscombination is entered on the bank screen within
based on their legacy IDs while they get used tothe customer and this bank does not exist in SAP
the new system.(in master table BNKA) then SAP allows you to
2. It is useful to have the legacy number storedcreate the bank master record at the same time
as part of an initial load of customers so thatas creating the customer relationship to it. So you
when subsequent update loads take place (e.g.must be careful when creating your customers
adding extra data using a recording or updatingthat you do not unintentionally create a number
the partner functions), these update programs willof bank records at the same time. Nevertheless
have a way of identifying the SAP customers.allowing the customer and vendor loads to do this
3. Apart from update loads, there are also othercan be a legitimate method of creating the banks
dependent objects such as pricing conditions, sales(if done intentionally) rather than by developing a
orders and open AR items where your source fileseparate load program. The bank master is a
will normally reference the old legacy IDs. SAP hassmall object with only one mandatory field (bank
provided a field called "Previous Account Number"name) apart from the primary key.
(KNB1-ALTKN) stored at the company code level.2.6 Reporting
This is where you would commonly store theOften on a project the sales group and sale office
legacy number. This works even on multi-countryset up is a key reporting feature that impacts
projects where the same customer may exist indirectly on the loading of customers. It is advisable
different legacy systems, because the field is atto speak to the functional consultants and
company code level. If it is not sufficient due tobusiness early to ascertain whether the structure
multiple legacy customers in the same companyhas been defined and how the customers can be
code pointing to one customer, you may need tomapped to the structure. Other fields used for
consider other options such create a custom tablereporting include the customer group fields:
or using multi-value characteristics in customercustomer group 1, customer group 2 etc, which
classification. The person responsible for buildingcan be customised according to the client's
the LSMW load program should also create arequirements.
routine which enables other loads to find the new