Sei sulla pagina 1di 23

AIM

CV.040 CONVERSION DATA


MAPPING
GE Aviation
Open Purchase Order Information.

Author: Hariprasad Valli


Creation Date: Jan 30, 2012
Last Updated: April 30, 2012
Document Ref:
Version: 1.4

Approvals:

Carla, Woodyard GE Project Manager

Darryl, Dalton GE Conversion Lead


CV.040 Conversion Data Mapping Conversion Document
Open Purchase Orders

Document Control

Change Record
4

Date Author Version Change Reference

April 30, Hariprasad Valli 1.0 No Previous Document


2012
Feb22, Hariprasad Valli 1.1 Rule PODR7 has been Removed,Account geration
2012 setup added
April 2nd, Hariprasad Valli 1.2 Embedded mapping sheet has modified i.e extract
2012 sequence, Mapping has given for field Category and
extract sequence given for Description
April20, Hariprasad Valli 1,3 1. Sales Orders added at dependencies
2012 2. Mapping, extract given for Project,Task in
embedded mapping sheet.
3. Audit Requirement section has added.
4. Conversion rule has modified as per updated
vision statement.
5. Following assumption added.
The Requisition Clean up Post process will cancel all
requisitions generated by the WIP Jobs with OSP
Operations during the WIP Conversion process.
April 30, Hariprasad Valli 1.4 The updated Vision document has embedded.
2012

Reviewers

Name Position

Distribution

Copy No. Name Location


1
Library Master Support Central
2 Project Manager
3

ii

Not for use or disclosure outside GE


CV.040 Conversion Data Mapping Conversion Document
Open Purchase Orders

Copy No. Name Location

Note To Holders:
If you receive an electronic copy of this document and print it out, please write your
name on the equivalent of the cover page, for document control purposes.
If you receive a hard copy of this document, please write your name on the front
cover, for document control purposes.

ii

Not for use or disclosure outside GE


CV.040 Conversion Data Mapping Conversion Document
Open Purchase Orders

Contents

Document Control ii
Introduction 5
Purpose 5
Background 5
Scope and Application 6
Audience 7
Conversion Plan 7
User Procedures 8
Error Handling 8
Assumptions 9
Audit Requirements 10
Dependencies 11
Prerequisite Set-ups 11
Application Business Object Reference Information 13
Conversion Validation Rules 14
Conversion Mapping Open Purchase Orders 16
Processing Rules 16
Translation Rules 17
Filter Rules 17
Foreign Key Rules 17
Derivation Rules 17
Default Values 18
R12 to Legacy Data column mapping 19
Extract File Layout 20
Post Conversion Tasks 21
Test Conditions 21
Open and Closed Issues for this Deliverable 22
Open Issues 22
Closed Issues 22

ii

Not for use or disclosure outside GE


CV.040 Conversion Data Mapping Conversion Document
Open Purchase Orders

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Introduction

Purpose
The Conversion Data Mapping document describes the:
Detailed data mapping from the source legacy system to the Oracle R12
Applications for Projects
File layout to be used for extraction of the data from the source system
Key assumptions, rules and logic needed to create the conversion
programs

Background
The information in this document has been defined as the result of discussions
between project staff, GE Aviation technical staff, and FCS consultants.
GE Aviation Systems are implementing two instances of a necw Oracle eBusiness
Suite ERP application. One will be based in the USA the second in the UK. These
two systems will replace legacy ERP systems on all GE Aviation System sites.
It is a requirement that some data currently in the site legacy systems be
transferred into either the live Oracle eBusiness Suite database for future
transaction or held within an archive database for reference purposes only. The
current list of data sets required to be imported is held in GE Libraries at the
following address - http://libraries.ge.com/foldersIndex.do?
entity_id=16959948101&sid=101&SF=1
As part of this project, a team has been set up to manage the migration of data
from the legacy systems to the new ERP system or archive application. The team
is divided into two areas:
Site based team responsible for:
o Mapping of legacy system data to Oracle R12 requirements (live and
archive);
o Extraction of live and archive data from the legacy system(s) in the
prescribed format;
o Cleansing of legacy system data;
o Conversion of legacy system data into Oracle R12 values;
o The provision of all infrastructures required to produce the extract
file and transmit it to the location specified by the Oracle R12 import
team.
Oracle R12 import team responsible for:
o Overall design of the import process for live and archive data;
o Interpretation of Oracle eBusiness Suite process requirements into an
import specification;
o Import files specification for live and archive data. This will include
the format of the extract file(s) to be produced by the site teams

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

together with the identification of mandatory, optional and not


required fields;
o Creation of non-standard import routines for data not supported by
Oracle tools;
o Validation of the received data files;
o Elimination of records already existing in Oracle R12;
o The provision of all infrastructure required to take the legacy system
files provided by the site based teams and create either a viable
record within Oracle R12 or an appropriate record within the archive
database;

GE Aviation, <Legacy System> as their master PO Entry system. The current


project is to implement a global Oracle e-Business Suite R12 application for the
entire company. As part of this project, Open POs data from the existing systems
must be converted into this new R12 EBS system. This document provides
details of the functional design to achieve this.
The document deals with the Open Purchase Orders and the mapping
exercise between the <Legacy System> and Oracle Applications in order to load
the Open Pos into the R12 instance. Data from legacy system would be extracted
after <Legacy System IT team> has cleansed the data along with
Business/Functional users. An extract program would be developed in legacy
system on the cleansed data that would extract the relevant data into a flat file
and using Loader utility, the data will be migrated to R12 staging tables that will
be validated as per the business rules. The validated data would be sent as an
input to Standard R12 Interface tables for running import programs to create
respective purchase orders.
A section in this document will also discuss the mapping between extracted
PO information from legacy with Oracle interface tables. This section will list all
the PO information that is required from a conversion perspective for the load
into R12.
Validations will be classified as mandatory and optional. If the mandatory
validations fail, the entire Purchase Order will be marked as Error in the staging
table and Failure of optional validations will be considered as S for Success and
will be created in Oracle.
As of date the document being created, there are approximately <????> Open
Purchase Orders out of total <????> That needs to be migrated.

Scope and Application


The Conversion Data Mapping identifies for use in designing conversion
programs to convert Open Purchase Orders and relevant if any:
data sources
target tables and columns
validation
processing

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

translation
filter
foreign key rules

PO header data should have at least one PO Line and one Distribution Line. If
not, the PO will be rejected.
The defaulting logic for some of the data elements is not known at the time of
preparation of this document. However, this needs to be discussed and
documented as a revision prior to the conversion process. Value of the default
will be confirmed once the setup is completed for PO.
The custom conversion code should perform required validations like duplicate
Pos and display validation failures, if any.
A Custom report that gives the results of validation failures with success/failure
counts and reasons for failures will be retrieved from the error tables
appropriately.

Vision and Use case statements and Pillar constraints


This section elobrated as result of discussion with process teams and site team
sign off. For more detail information, refer an attached vision&use case
document.

Standard_Purchase_
Order_04192012[1].docx

Audience
This document is intended for the following individuals:
GE Aviation conversion project staff
outside consultants
reviewers of data conversion deliverables

Conversion Plan
The Purchase Order Import interface process will be used to convert Open POs

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

GE Aviation has a <Legacy system> that will provide us Open PO data. PO


Document numbers will be generated in Oracle, but to keep the reference,
legacy Purchase Order Number will be stored in the Header/Site level
Descriptive flex fields.
3-way matching will be implemented to integrate with payables

User Procedures
In order to populate Open Purchase Orders data into the Oracle Applications the
following steps need to occur:
GE Aviation staff will generate data file in specified format.
Conversion staff will FTP data file to specified UNIX directory on the
database server in ASCII mode.
Conversion staff will run SQL*Loader concurrent program to load Open
Purchase Order data from data file into the staging tables.
Review concurrent program output and log. Resolve errors.
Run the conversion concurrent program to validate data and populate
interface tables.
Review concurrent program output and log. Resolve errors.
Run the import Interface program to import data from interface tables to
core tables.
Review concurrent program output and log. Resolve errors.

Error Handling
Each program executed will provide an error report in the concurrent program
output.
The SQL*Loader program will be designed to replace all records in the custom
staging table. Therefore any records that fail loading to the custom table will
have to be corrected in the data file by GE Aviation staff. It is critical that the
corrected data file is reverted back to the development within 1 day in order to
avoid development schedule impact. The entire data file (error and non-error)
received from GE Aviation will have to be re-loaded by Technical Development
team.
The Custom Conversion Program will validate data and load data from staging
table to interface tables. Any error records will have to be corrected in the data
file. The Interface tables and the staging tables will have to be truncated. And the
entire process will have to be resubmitted starting with the SQL*Loader
program. Alternatively, the data errors will need to be corrected in the staging
table and re-processed.
The standard Interface Program will provide an error report. In this case only the
error records will have to be corrected and re-submitted. The valid records will
already have been imported.

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Assumptions
The Purchasing setups must be complete before executing document
type Standard PO conversion.
POs with all open lines (Standard purchase orders, Blanket Releases)
will go to R12.
The document number for PO in R12 will be system generated numbers.
Only 3 way matching PO is in scope for converted Standard Pos.
Business use position approval hierarchy process in oracle R12
For conversion, blanket releases in legacy will be brought over as
Standard Purchase Orders.
If the PO has a reference of the Project number in legacy, the linkage /
relation should be brought over to R12
Pay on code is receipt in scope for converted Standard Pos.
Number of standard purchase orders created in R12 vs. Number of
purchase orders in the source instance. This report should consist of total
number of records in both legacy system and R12 instance.
The report should have the legacy purchase order number and the R12
purchase order number. Any purchase order that is not converted for
any reason should also be listed with the reason code for failure.
Error reports must be developed to capture the error records in staging
tables, interface tables before they are loaded in to the Oracle base tables.
A report need to be provided for all the POs with OSP items with the
details of the Purchase order number, WIP job number associated with
the converted PO and the converted WIP job status in R12.
The Requisition Clean up Post process will cancel all requisitions
generated by the WIP Jobs with OSP Operations during the WIP
Conversion process. These requisitions can be identified by the
following:
o Requisition Line Type will be Outside Processing
o Requisition Import Source will be WIP

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Audit Requirements
Audit report of data file after the Standard Purchase Orders are loaded into R12
must detail the following information Legacy PO Number, R12 PO Number,
Supplier Name, Supplier Site, R12 PO Line Number, R12 PO Line Qty, R12 Qty
Received, R12 Qty Open.

The PO Conversion must consider the transformation of Project Number and


Task Number from Legacy to R12. Conversion of Projects and Tasks from legacy
to R12 is a pre-requisite for PO Conversion. This information must be based on
the Project and Task Number transformation between legacy and R12 being
developed by the Project Conversion team.

Audit Report required which should detail the WIP Jobs with OSP Operations
and the associated requisitions that were generated by the WIP Conversion
process and subsequently cancelled by the Requisition Clean-Up Post Process.

Audit report detailing all Standard Purchase Orders converted to R12 with OSP
Items that are NOT linked to a WIP Job in R12.The line type for these POs would
be Outside Processing item.

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Dependencies
This section lists the tables that need to be populated before Open Purchase
Orders
The associated Inventory, Purchasing and GL periods should be open
prior to converting Standard Purchase Orders.
Lookups values for data elements as identified should be defined before
converting Open Purchase Orders and releases.
All of the following conversions must be completed prior to purchase
order conversion

o Suppliers and supplier sites


o Items and Categories.
o Employee Conversion.
o Quotations.
o Global Blanket Agreements.
o Project and Task Conversion.
o WIP JOB conversion[OSP]
o Sales Orders

Prerequisite Set-ups

Profile Options
Purchasing Profile Options need to be defined that may have an impact on the PO creation
process.

Organizations and Parameters


Organization structure and associated Operating Units, Warehouse information of each site
should be configured and setup accordingly.

Setup Configuration
All of the following setups should be configured and setup accordingly for each site to be
used for mapping and transformation as appropriate:

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

o Locations.
o Sub inventories.
o Document Types.
o Line Types.
o Financial Options.
o Purchasing Options.
o Receiving Options.
o Payment Terms.
o Buyer.
o Define employee Job
o Define employee position
o Position hierarchy
o Unit of measures.
o Exchange Rates.
o Exchange Rate Type.
o Exchange Rate date.
o UN Numbers.
o Hazard Classes.
o Freight Carrier.
o Setup GL code combination
o UOM conversion
o Account generator setups /workflow

All of the following Lookup Types should be configured and setup accordingly for each site
to be used for mapping and transformation as appropriate:

o AUTHORIZATION STATUS.
o FREIGHT TERMS.
o FOB.

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Application Business Object Reference Information


In each of the following sections, a table maps the business objects for Open Purchase Order Conversion to
the Oracle Application tables. The foreign key relationships between the Oracle Application tables
are also indicated. In column (4), the standard Oracle interface is documented if one exists for
facilitating the conversion of a specific business object.

Business Object Owned Open Interface Production Table Foreign Key Table
By Name(s) Name(s)

Standard Open Purchasing PO_HEADERS_INTERFACE PO_HEADERS_ALL


Pos Conversion PO_LINES_INTERFACE PO_LINES_ALL
PO_LINE_LOCATIONS_INT PO_LINE_LOCATIONS
ERFACE, _ALL
PO_DISTRIBUTIONS_INTER PO_DISTRIBUTIONS_A
FACE LL
FND_ATTACHED_DOCUM FND_ATTACHED_DO
ENTS_PKG.INSERT_ROW CS_FORM_VL

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Conversion Validation Rules


Following rules have been defined and elaborated as the result of discussion with ERP Core Process Team to
be applied for data extracts and development:

All the existing legacy data i.e. purchase orders (releasesaganist blanket,
standard purchase orders) should be brought in as Standard Purchase
orders in to R12.
o All Standard Purchase Orders, Releases against blanket which
are in APPROVED status in legacy system only will be
converted into R12.
o If a Purchase Order has a mix of open and closed lines, only
open lines for receiving will be converted into R12.
o If a Purchase Orders line has partially open quantity, the entire
PO line quantity will be converted.
o All open Purchase Orders should be converted with receipt
routing as INSPECTION REQUIRED and PO matching level as
3 way matching
o Purchase Orders that having expense items and 2 way match in
legacy will be converted as 3 way matching.
Standard Purchase Orders sequence numbers will be generated
automatically in R12 and the legacy PO numbers will be store in
description field of Standard Purchase Orders.
The Purchase Orders, Releases which are fully received in legacy for the
past seven years will be achieved into Data Warehouse.
o All Purchase Orders, Releases which are not in cancelled status
will be achieved into Data Warehouse.
o All Purchase Orders, Release which achieved into Data
Warehouse will be having Legacy Purchase Order Number
Header and line level attachments, notes to the supplier that had been
through data cleansing and have been designated for conversion in
middle river POs / releases should be loaded in to the document
catalogue and attached to the purchase order header or line when
converted to R12.
o Header and line attachments should be converted after
converting PO headers and Lines.
POs generated for out-side processing jobs The WIP job number
referenced on the legacy PO need to be replaced with new WIP job
created from Conversion in R12.
o The status of the WIP job in R12 should be Open/Released

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Purchase Orders/Releases which are generated from BPA in the legacy


system should be converted as standard Purchase Orders with reference
to the legacy PO number in the description field and the R12 GBPA
number in the reference at PO line level.
Supplier and site must be active
Employee must be active
Bill to location and Ship to location must be active
All the standard PO conversion will include details from PO Header, PO
Line, PO Distribution, PO Shipment and OSP details as per the data
mapping sheet.

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Conversion Mapping Open Purchase Orders


Below is a table mapping the legacy data elements to the Oracle tables and columns. The following
processing ID codes are used in the mapping spreadsheet:

POPR = Processing Rule

POTR = Translation Rule

POFR = Filter Rule

POFKR = Foreign Key Rule

PODR = Derivation Rule

PODV = Default Value Rule

Processing Rules

This section lists the processing rules that are to be used in the conversion of
Open Purchase Orders:
Rules:
POPR1: Generate Interface_Header_Id based on relevant sequence
POPR2: Generate Interface_Line_Id based on relevant sequence
POPR3: Generate Interface_Distribution_Id based on relevant sequence
POPR4: Validate rows and mark rows that fail validation as Error:
o Duplicate Rows
o Lookup Validation Failures
o Custom Validations as per mapping
POPR4: Report Output for Processing Counts

Translation Rules
This section lists the translation rules, which are to be used in the conversion of
Open Purchase Orders:

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Rules:
POTR1: Get the Oracle Buyer Name using Legacy Buyer Name
POTR2: Translate the date to DD-MON-YYYY format.
POTR3: Get the Vendor Name using Legacy Vendor Number

Filter Rules
This section lists the foreign key rules that are to be used for the conversion of
Open Purchase Orders:

Foreign Key Rules


This section lists the foreign key rules that are to be used for the conversion of
Open Purchase Orders:
Rules:
POFKR1:
PO_LINES_INTERFACE.INTERFACE_HEADER_ID =
PO_HEADERS_INTERFACE.INTERFACE_HEADER_ID
POFKR2:
PO_DISTRIBUTIONS_INTERFACE.INTERFACE_HEADER_ID =
PO_HEADERS_INTERFACE.INTERFACE_HEADER_ID
PO_DISTRIBUTIONS_INTERFACE.INTERFACE_LINE_ID =
PO_LINES_INTERFACE.INTERFACE_LINE_ID

Derivation Rules
This section lists the derivation rules that are to be used in the conversion of
Open Purchase Orders.

Rules:
PODR1: Derive the Agent_Id column from Oracle based on Legacy Buyer Name
PODR2: Derive the Created_By/Last_Updated_By column based on user
CONVERSION
PODR3: Derive the Vendor Id using Legacy Vendor Number

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

PODR4: Derive the Vendor Site Id using Legacy Vendor Number and Site Code
PODR5: Get the Vendor Contact Id using Legacy Vendor Number and/or Site
Code and Contact Name
PODR6: Derive the Item Id using Legacy Item Number

Default Values
This section lists the default value rules that are to be used in the conversion of
Open Purchase Orders. The default value rules explain the logic behind why a
certain default value has been selected.
Rules:
PODV1:
PODV2:
PODV3:
PODV4:
PODV5:
PODV6:

R12 to Legacy Data column mapping

Below is a mapping spreadsheet that maps the legacy data elements to the Oracle tables
and columns.
Target Application: Oracle Applications
Business Object: Open Purchase Orders
Target Application Tables: PO_HEADERS_INTERFACE, PO_LINES_INTERFACE,

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

PO_DISTRIBUTIONS_INTERFACE,

Data Mapping Spreadsheet: Project Folder: Aviation Systems ERP Implementation


Current Folder Navigate to:
Design > Technical > Data Conversion R12 > CV40s > Design Document > Open POs

Data Mapping Excel to be inserted in here

Std_PO_Conversion_
Mapping Sheet_v1.3.xlsx

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Extract File Layout


The column values are to be separated with a tilda (~) delimiter and must have a header
record identifying each column associated with legacy extract. Refer to the mapping
sheet for more details with respect to the relevant oracle column mapped to.
The data extract file has the columns in the order marked with sequence number/ID in
the Data mapping excel embedded in the prior section.

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Post Conversion Tasks


(Any Manual/Programmatic intervention steps as per Business necessity during the conversion
process are to be documented in this section)
The following steps to be executed after conversion of Standard Purchase Orders.

Purchase orders with approved status data is available in Oracle R12


Receive the goods/services against Std PO
Inspect the goods against Std PO
Generate the Invoice against Std PO.
Make the Payment against Std PO.
Transfer to GL

Test Conditions
Refer the CV070 for detailed test conditions that are required for conversion to be marked as
successful.
The interface work units are approved by the GE Aviation through System Integration Tests and
User Acceptance Tests.
All destination attributes must map to source attributes as in the attribute mapping provided in
the mapping matrix.
Error handling is complete, accurate, and appropriate for the purposes of this interface.
Printed output is satisfactory and conforms to the standards set for the Oracle Applications
implementation project.

ii

Not for use or disclosure outside GE


Conversion Document Open Purchase Orders

Open and Closed Issues for this Deliverable

Open Issues

ID Issue Resolution Responsibility Target Date Impact Date

Closed Issues

ID Issue Resolution Responsibility Target Date Impact Date

1.0 How do you handle if there If there is any returen line it should be
is any return lines reflected at converted quantity.
associated with Legacy PO?

1.1 From the Vision Use case 7 years


"All Purchase Orders,
Releases which are not in
cancelled status will be
archieved into Data
Warehouse".
Is there any timeline
associated with above
statement?

1.2 What type of Approval Position


Heirarchies You are using?

1.3 Is PO attachments are in Yes


scope of Conversion?

ii

Not for use or disclosure outside GE