Professional Documents
Culture Documents
1 Document Information.............................................................................................4
2 Introduction..............................................................................................................5
3 Definitions of Different Types of Data......................................................................6
3.1 Master Data...................................................................................................................6
3.2 Configuration Data.........................................................................................................6
3.3 Transaction Data........................................................................................................... 6
Area Data
SolMan Dev ID
Reviewed by
Approved by
Data migration is typically a ‘one-off’ activity prior to go-live. Any ongoing data loads required on a
frequent or ad-hoc basis are considered to be interfaces, and are not part of the data migration scope.
This document outlines how the CF project intend to manage the data migration from the various
council legacy systems the SAP CRM system
The creation of the Single Customer Record is not included in this document; refer to the Single
Customer Record MDM design paper for information on this subject.
Open Transaction Data - is transactional data that has not completed its business cycle, for
example a service ticket that remains open with additional activities required prior to being
closed.
Closed Transactional Data – is transactional data that has completed its business cycle and is
subsequently used for information purposes only, for example a service ticket will all related
activities completed and a ticket status of closed.
Cleansing is an iterative process that can start as soon as the data has been identified as being
required for migration into SAP. The data cleansing cycle includes the following steps:
The elimination obsolete records.
The removal of duplicate records.
Correcting inaccurate records.
Correcting incomplete records.
Note: Where the master data resides in an application that is not being replaced by SAP, but is required
by SAP to support specific functionality, the data will NOT be migrated but accessed from SAP using a
dynamic query look-up. A dynamic query look-up is a real-time query accessing the data in the source
application as and when it is required. The advantages of this approach are;
It is the responsibility of the data owner (i.e. the business) to ensure the data provided to the Customer
First Project for migration into SAP (whether this is from a legacy source or a template populated
specifically for the CF project) is accurate.
Data cleansing should, wherever possible, be done at source, i.e. in the legacy systems, for the
following reasons:
Unless a data change freeze is put in place, extracted datasets become out of date as soon as
they have been extracted, due to updates taking place in the source system. When re-
extracting the data at a later date to get the most recent updates, data cleansing actions will get
overwritten. Therefore cleansing will have to be repeated each time a new dataset is extracted.
In most cases, this is impractical and requires a large effort.
Data cleansing is typically a business activity. Therefore, cleansing in the actual legacy system
has the advantage that business people already have access to the legacy system, and are
also familiar with the application. Something that is not the case when data is stored in staging
areas. In certain cases it may be possible to develop a programme to do a certain degree of
automated cleansing although this adds additional risk of data errors.
Legacy Data
on PC
Convert
Field- SAP
Data
Assignments System
Batch Input
Conversion Processing
SAP System
Rules
Converted Direct Input
Data Processing
-
Inbound IDoc
SAP Application Server Processing
SAP
There is one DOS for each Data Object or group of Data Objects in scope. The main purpose of this
document is to achieve:
A consistent look and feel for all DOS records
Clarification of the DOS columns
Standard values for columns across all DOS records
Clear rules for different scenarios
Better interpretation of an SAP data object.
Each DOS sheet is an Excel file that conforms to the following generic layout. See Appendix 1 for the sample
template
Screen Name Mandatory This is the name at the top of the SAP screen when entering
fields. Enter once at the beginning of the section, not on each
line. For example Business Partner.
Field Description Mandatory Field Description, for example Customer Name
Table/Structure Mandatory SAP Table Name.
Field Name Mandatory SAP Field Name
Length Mandatory Length of field
Format Mandatory Example CHAR, DATS, CURR
Field Status Mandatory Field Status; R=Required, A=Automatic, C=Conditional,
O=Optional, NR=Not Required
Comments Mandatory Insert comments to assist with data mapping and transforming.
For example: Describe allowable values with the conditions for
deciding which value must be used
Source System Mandatory The name of the legacy system
Legacy Mandatory The name of the legacy table and field.
Table/Field
Conversion Rule Mandatory The Conversion Rule, describe the transformation values, any
fixed values or logical rules
The Data Object Register layout and content is detailed in the able below;
Field
Source
Field Table/ Status Source Conversion
Screen Field Purpose/Description Length Format Comments Table
Name Structure System Rule
Field Name
Address Data
Title Title key - e.g. Mr, Mrs, etc. title addr1_data 4 char M
Name 1 Address component: Name of an address. name1 addr1_data 40 char M
Name 2 Address component: Name of an address. name2 addr1_data 40 char M
Name 3 Address component: Name of an address. name3 addr1_data 40 char M
Name 4 Address component: Name of an address. name4 addr1_data 40 char M
Search term 1 Short description for a search help. sort1 addr1_data 20 char O