Академический Документы
Профессиональный Документы
Культура Документы
Approvals:
Document Control
Change Record
4
Reviewers
Name Position
Distribution
ii
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
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
ii
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
ii
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.
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
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
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
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.
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
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
Prerequisite Set-ups
Profile Options
Purchasing Profile Options need to be defined that may have an impact on the PO creation
process.
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
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
Business Object Owned Open Interface Production Table Foreign Key Table
By Name(s) Name(s)
ii
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
ii
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
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:
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
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:
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
PO_DISTRIBUTIONS_INTERFACE,
Std_PO_Conversion_
Mapping Sheet_v1.3.xlsx
ii
ii
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
Open Issues
Closed Issues
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?
ii