data convesions

7/30/2019 Data Convesions

http://slidepdf.com/reader/full/data-convesions 1/4

DATA CONVESIONS

1. Introduction

This document provides an overview of data conversion processes and methodologies which can be used in

manufacturing industry which are ready to move from one ERP system to another ERP (SAP R/3) system.

The objective of this document is to outline detailed descriptions of conversion processes.

Data Conversion is the conversion of one form of computer data to another form for the purpose of application

interoperability or of capability of using features of new system which requires active involvement from business

user to make it right. It is generally recommended when an organization is completely/partially moving from legacy

system to new system and also wants to correct the data from their old system.

2. Overview

In any implementation to a new system from the existing system, data conversion is essential and critical.

Following entities/business objects covering all aspects of SAP (PTP, OTC and PME) in scope for the conversion

process

Master Data:

Item Master

Vendor Master

Customer Master

Program Numbers

Transactions Data:

Open Scheduling Agreement/Purchase Orders Pricing

Open Scheduling Agreement/Purchase Orders

Open Sales Order Pricing

Open Sales Orders

Standard cost data

Inventory Balances

Banking and vendor banking

Intercompany Transactions

Output Determinations

Open AP

Open AR

Finance and Controlling Data:

CostCenter

Asset Master and Asset Transactions

G/L Account Balances

Internal Orders

3. Conversion Process



Based on the complexities and multiple stake holders defined in the Overview section, Data conversion process

had been categorized into 4 stages namely

Pre-cleansing

Extraction

Cleansing, Enrichment and Transformation

Pre and Post Load Validation, Load and post-load support

Signoff

3.1. Pre-Cleansing

As the name suggests, Pre-cleansing is the process which starts before cleansing and was one of the critical and

important activities. It deals with the activities done in the legacy/existing system before even attempting to extract

data for the new system.

Business User (Such as Plant Controller, Plant Manager, Purchasing community, Sales Community, Central

Costing and Finance, Supply Chain Management etc) together with IT leadership (along with 1 or 2 developer of

the existing ERP system) used to drive this process.

The intention of this process is to bring the data owner from different units to a common platform and make them

agree to the quantity and quality of the data to be converted.

During the entire process, the stake holders does brain storming, discussion about what should go into SAP or

what should not. In the database tables pertaining to these business objects i.e. Item, PO, SO etc one field called

"GOSAP" was created. Once the decision was being made about a PO/SO and its related parts, this field used to

be populated with "GOSAP" or "NOSAP". Line items with the value of "GOSAP" were only looked for further

processing.

It is executed for each plant in a given deployment to take a snapshot of the data at any given point in time. This

used to be a weekly activity which used to show the action items for concerned participants or a group of

participants.

Report includes following:

Business object and its related critical attributes,

Records - Count of disconnects

Percentage - What portion of data were in disconnects as compared to over all count of records for a given

business object

Most of the business related questions were answered based on this report

Identify the number of parts which need to converted Parts which are obsolete but have active PO/SO

Parts which have standard cost as 0

Active PO/SO`s but no corresponding conditions records i.e. prices

Active Vendors but no transactions (i.e. PO) associated with them

Active Customers but no transactions (i.e. SO) associated with them

PO`s are active but corresponding Vendors are not need any anymore

SO`s are active but corresponding Customers are not need any anymore

Discrepancies between selling pricing currency and buying price currency



This is how a pre-cleansing report looks like for intercompany to treat intercompany transactions separately

!image1.JPG!

Most of the intercompany related questions were answered based on this report

Same parts are described differently in different plants i.e. same part number having different details or same part

description but different part number, i.e. description match

Prices discrepancies for the same parts between 2 plants like Selling plant is quoting one selling price where as

buying plants shows different price i.e. price mismatch

Parts discrepancies between the plants like one plant is saying they are selling but other is saying that they are not

receiving or vice versa i.e. number of PO lines in one plant is not matching with number of SO from whom he is

buying

Pricing currency mismatch between the transacting plants

Unit of measure (UoM) mismatch

Hard Match - When the PO, line number and Parts matched from buying plant matched with SO, line number and

Parts from selling plant

Soft Match - When only PO and parts matched from buying plant with SO and line number from selling plants

All the above mentioned analysis either for 3rd party or intercompany were discussed in detail with the concerned

data owner to arrive at a common platform so that putting junk/garbage into new system could be avoided.

The decisions based on the data owner analysis were as follows

Convert PO/SO`s only for identified active parts

Convert Vendor/Customer based on these active PO/SO`s thus making master data dependent on the transaction

data

Maintain standard costs for the active items

Maintain condition records i.e. Pricing for every PO/SO`s except for future or release orders to customer

Resolve selling and buying currency issues and adjusting the prices accordingly

For intercompany, Resolve price, parts, currency, UoM discrepancies by doing workshop with both plant controller

and central costing and finance team

3.2. Extract

After pre-cleansing was done or reaching at the final stages, Data pertaining to each business objects used to be

extracted from the legacy system. The extract program was designed with the help of data and process owner

considering the correct mapping of fields from legacy system to SAP system. It was developed by the existing

system developer in the existing system language and was stored in the central repository called Livelink. For any

deployment, the program used to be exported to respective plant database and was executed. The extracts for all

the business objects used to be taken at the same time to avoid any discrepancies among the master data and

transaction data. Atleast for every legacy field, a new SAP field had been added in the program so that while

cleansing/enrichment, data owner compares the values without going into the existing system.

Data used to be extracted in its entirety from the old system which means no business logic in the extraction

program/scripts thus reducing one level of complexities. During the pre-cleansing all the data which needed to be

converted in the target system was flagged with "GOSAP/NOSAP" status. The cleansing team used to filter the

relevant data based on this flag. Data were always extracted and put into flat files for further processing.

3.3. Cleansing, Enrichment and Transform



As the title suggests, it describes 3 steps in the conversion process

- Cleansing - Modify/make corrections in the existing data

- Enrichment - Provide Information which are not present in the existing system but are needed by SAP

system

- Transform - Transform the cleansed/enriched data into load format using a tool called "Trillium"

Though the definition seems quite simple, it was as exhaustive as pre-cleansing cleansing. During this process of

conversion completeness, correctness and accuracy of the data is one of the critical tasks which were done during

this process.

After Extraction of the data for all the business objects, the data used to be formatted based on pre-defined

formatting rules using Trillium and sent to business users/data owners to validate the existing information and

provide the additional information (called enrichment) needed by SAP e.g. Vendors have name, address, city, zip

code, Phone etc were already present in the existing system which the purchasing community were asked to

validate for correctness but they were also asked to fill the information like Sales contact, Commodity that these

vendors are supplying, Inco terms, Whether the vendor is minority vendor etc etc which formed the enrichment

part. There were data owners for each process areas like PTP, PME and OTC and one had to follow up constantly

to get the correct and accurate data from these owners.

Once the cleansed and enriched were sent back, it used to be run again in Trillium to prepare the LSMW input flat

file.

For data transformation i.e. cleansing or static enrichment, Trillium was used. A lot of customization has been done

in Trillium to get the data file in the format as needed by LSMW tool.

Trillium was preferred as compared to Microsoft access as the formatting tool because of the following reason:

De-duplication and identifying relationships are inbuilt features in Trillium so no manual effort for de-duplication

Data Cleansing and Standardization are inbuilt again features in Trillium. So customization to certain extent would

give maximum output.

Handle multi plants and huge volume of data efficiently and comfortably3.4. Load

During this process of conversion, data were loaded into SAP system using the upload tool from SAP called

LSMW. The LSMW was customized to validate business needs especially for mandatory value attributes,

dependencies, sequences and format. Hence it used to serve as the last validation juncture to identify the

correctness of the data.

Every business objects had their own customized program.

3.5. Validation after Load

Reports were developed and run in the SAP system and compare the results against what were

extracted/cleansed/enriched and what got loaded to validate the correctness of the data and thus create the

credibility between the data owner with the new system.

3.6. Signoff

data convesions

Documents