AIM

CV.010 DATA CONVERSION

REQUIREMENTS AND STRATEGY
<Company Long Name>
<Subject>

Author: <Author>
Creation Date: May 25, 1999
Last Updated: May 28, 1999
Document Ref: <Document Reference Number>
Version: DRAFT 1A

Approvals:

<Approver 1>

<Approver 2>
CV.010 Data Conversion Requirements and Strategy Doc Ref: <Document Reference Number>
May 28, 1999

Document Control

Change Record
5

Date Author Version Change Reference

25-May-99 <Author> Draft 1a No Previous Document

Reviewers

Name Position

Distribution

Copy No. Name Location

1
Library Master Project Library
2 Project Manager
3
4

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.

<Subject> Acceptance Criteria

File Ref: 380628433.doc (v. DRAFT 1A )
Company Confidential - For internal use only
CV.010 Data Conversion Requirements and Strategy Doc Ref: <Document Reference Number>
May 28, 1999

Contents

Document Control.....................................................................................................................

Introduction................................................................................................................................
Purpose.................................................................................................................................
Project Deliverables Audience..........................................................................................
Benefits.................................................................................................................................
Scope............................................................................................................................................
Background..........................................................................................................................
Applications.........................................................................................................................
Platforms..............................................................................................................................
Connectivity.........................................................................................................................
Tools......................................................................................................................................
Other Technologies.............................................................................................................
Objectives....................................................................................................................................
Objectives.............................................................................................................................
Critical Success Factors......................................................................................................
Approach.....................................................................................................................................
Tasks and Deliverables......................................................................................................
Key Inputs............................................................................................................................
Constraints and Assumptions..........................................................................................
Schedule/Critical Milestones...........................................................................................
Required Resources............................................................................................................
Conversion Team Organization.......................................................................................
Roles and Responsibilities.................................................................................................
Conversion Resource Requirements................................................................................
Conversion Strategy..................................................................................................................
Conversion Approach........................................................................................................
Automated Tools................................................................................................................
Conversion Process Flows........................................................................................................
General Ledger Conversion Process Flow......................................................................
Accounts Receivable Conversion Process Flow............................................................
Accounts Payable Conversion Process Flow..................................................................
Inventory Conversion Process Flow................................................................................
Bills of Material Conversion Process Flow.....................................................................
Work in Process Conversion Process Flow....................................................................
MRP Conversion Process Flow........................................................................................
Engineering Conversion Process Flow............................................................................

<Subject> Acceptance Criteria

File Ref: 380628433.doc (v. DRAFT 1A )
Company Confidential - For internal use only
CV.010 Data Conversion Requirements and Strategy Doc Ref: <Document Reference Number>
May 28, 1999
Purchasing Conversion Process Flow.............................................................................
Order Entry Conversion Process Flow...........................................................................
Project Standards.......................................................................................................................
Century Date Compliance.................................................................................................
Tool Standards....................................................................................................................
Deliverable Naming Standards........................................................................................
Data Clean-up Process..............................................................................................................
Data Clean-up.....................................................................................................................
Key Data Translations........................................................................................................
Testing Strategy..........................................................................................................................

Acceptance Criteria...................................................................................................................
Delivery................................................................................................................................
Data Acceptance.................................................................................................................
Audit/Control.....................................................................................................................
Issue Tracking Procedures.......................................................................................................
Issue Management Procedure..........................................................................................
Issue Resolution..................................................................................................................
Version Control Procedures.....................................................................................................

Change Management.................................................................................................................

Quality Management.................................................................................................................

Conversion Requirements........................................................................................................

Business Object Conversion Selection Criteria.....................................................................

Open and Closed Issues for this Deliverable........................................................................

Open Issues..........................................................................................................................
Closed Issues.......................................................................................................................

<Subject> Acceptance Criteria

File Ref: 380628433.doc (v. DRAFT 1A )
Company Confidential - For internal use only
 Doc Ref:

Introduction

Purpose

This Data Conversion Requirements and Strategy document defines the

requirements, scope, objectives, and strategy for the <Project Name> conversion
effort.

The Data Conversion Requirements and Strategy document is used as follows:

 The primary use of this document is to record and communicate the data
conversion scope, objectives, approach, and requirements.
 The conversion team uses this document to communicate the strategy for
successfully converting the legacy data to the new Oracle system(s).
 The conversion team uses this document as a road map for performing the
conversion. All members of the team should understand and follow the same
strategy.
 The project manager uses this document to understand how the conversion
team plans to perform the conversion, and how the conversion effort may
impact the overall project.

Distribute and communicate the Data Conversion Requirements and Strategy to the:

 project manager from the implementation services provider

 client project manager, who should sign-off on the conversion requirements
and strategy
 conversion team members
 other process leaders who are responsible for tasks that are prerequisites for
conversion tasks, or whose tasks are dependent on output from conversion
tasks

Use the following criteria to ensure the quality of this deliverable:

 Are the project scope and objectives clearly identified?

 Are specific critical success factors documented?

 Is the impact of each dependent task from other processes considered?

 Are the conversion requirements clearly defined, including all legacy

applications and business objects? Do the definitions indicate the level of
detail and history to be converted?

 Is a disposition path for every existing business object/data element

clearly defined?

 Is the strategy understood by those on the distribution list for this

deliverable?

 Are all assumptions, constraints, and risks that could impact the
conversion stated, understood, and mitigated?

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Project Deliverables Audience

The conversion activities involve interaction with the following groups:

 <Company Short Name> conversion and interfaces teams

 the project team members responsible for the following conversion
prerequisites:

Design/Build Standards
Existing and proposed System Data Model
Database Extension Design

 those responsible for the technical architecture of the overall project

conversion and interface capacity requirements
 those responsible for the system test and the systems integration test
 all <Company Short Name> pilot and roll out application and technology
installation project teams
 project managers responsible for staffing the conversion and interface effort
 project managers responsible for training project resources

Benefits

By following the proven AIM conversion approach, the following benefits can be
realized:

 faster data conversion through defined standards and procedures

 lower conversion cost leveraged from repetitive use of conversion programs
 centralized definition and maintenance of conversion practices, designs, and
code
 minimized use of functional and technical resources to repetitively analyze,
design, and deploy conversions
 minimized number of resources to support the conversion tasks

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Scope
This section identifies included and excluded conversion project scope.

Background

Below is a discussion of the following project features:

 single or multi-site conversion implementation

 single or multi-phased conversion implementation
 single or multiple data sources
 common definition of key data elements across multiple sites
 unique project/legacy system features

Single or Multi-site Conversion Implementation

Single or Multi-phased Conversion Implementation

Single or Multiple Data Sources

Common Definition of Key Data Elements Across Multiple Sites

Common reference date:

Common document data:

Common transaction data:

Common historical data:

Unique Project/Legacy System Features

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Applications

This project includes conversion of the following application modules to the defined
Oracle Application modules:

Oracle Application Checkbox Documents Transactions History

Financials
General Ledger
Payables
Purchasing
Fixed Assets
Distribution
Order Entry
Receivables
Inventory
Manufacturing
Bills of Material
Master Scheduling/MRP
Engineering
Capacity
Work in Process
HR/Payroll
Project Accounting
Sales and Marketing

The following data will be converted to a Data Warehouse:





The following legacy system applications will not be converted in this project to
Oracle Applications:





Platforms

Legacy System

The legacy systems currently operate on the following platforms/environment:

Hardware/versions:





Operating system/versions:

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:




Software/versions/module/manufacturer:





Oracle Applications Target System

The Oracle Applications will be running on the following platform/environment:





Connectivity

The following data connectivity/transfer methods are available:

Transparent Gateways




Procedural Gateways




File Transfer Software





PC-Based Transfer Tools





ODBC Drivers



Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Tools

The following automated tools will be available to facilitate the conversion project:

Data Management Tools





Data Modeling Tools





Data Scrubbing Tools





Data Transformation Tools





Data Mapping Tools





Database Utilities




Other Technologies

The following is a list of third party software to be considered in the scope of this
conversion project:





Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Objectives

Objectives

The key objectives of the conversion effort follow:

 Convert legacy and other related enterprise data to the Oracle Application
suite of products.

Critical Success Factors

In addition to the critical success factors that have been identified for the overall
Oracle implementation for <Company Short Name>, the following critical success
factors are specific to this conversion:

 early conversion planning and coordination across all <Company Short

Name> companies to maximize timely and cost-effective enterprise-wide
conversion and migration development investments
 well defined technical architecture strategy, requirements, and application
configurations that are agreed upon and stable
 participation of representatives from each conversion group as part of the
project team helping to ensure consideration of enterprise-wide business and
system interface points
 availability of planned Oracle application programmatic interfaces (APIs)
 early identification and completion of key data translations, clean-up, and
transformations

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Approach

Tasks and Deliverables

The major tasks and corresponding deliverables provided in this conversion project
are:

Task Description Deliverable

Define Data Conversion Requirements Analyze and document the conversion scope, Data Conversion Requirements and
and Strategy objectives, approach, requirements, and the Strategy
strategy for how the conversion will be
performed.
Define Conversion Standards Document the standards that should be followed Conversion Standards
throughout the conversion effort.
Prepare Conversion Environment Prepare the conversion environment for the Conversion Environment
development and testing of the conversion
programs.
Perform Conversion Data Mapping Map legacy data files and elements to the Oracle Conversion Data Mapping
Application table(s) and columns. This map
includes an explanation of business, translation,
foreign key rules, and default settings.
Define Manual Conversion Procedures Define procedures for manually converting Manual Conversion Procedures
applicable business objects through Oracle
Application forms.
Design Conversion Programs Design how the conversion programs should be Conversion Program Designs
coded using conventional programming
techniques or built using an automated
conversion tool.
Prepare Conversion Test Plan Specify test procedures to be followed for Conversion Test Plans
performing conversion unit, business object, and
validation tests.
Develop Conversion Programs Develop conversion programs based on the Conversion Programs
Conversion Program Design that have been
coded or built using an automated conversion
tool.
Perform Conversion Unit Tests Test the performance of each of the individual Unit-Tested Conversion Programs
conversion program modules.
Perform Conversion Business Object Test how the converted data performs within the Business Object-Tested Conversion
Tests target application. Programs
Perform Conversion Validation Tests Test how the converted data performs within the Validation-Tested Conversion Programs
entire suite of target applications.
Install Conversion Programs Install the conversion programs that have been Installed Conversion Programs
coded and tested. If an automated conversion
tool is being used, the tool should remain
installed until the final conversion is performed
Convert and Verify Data Convert data that has been verified by the users Converted and Verified Data
before commencement of production operations.

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Key Inputs

Key inputs to this conversion include:

 Statement of Work
 Documents outlining enterprise application and technology architecture
strategy, requirements, and constraints
 Existing and required Business Data Flow
 Application and module configuration including code table definition, Oracle
flexfield and descriptive flexfield definition, third-party and custom
developed applications key field definitions, etc.
 Module Design Standards
 Module Build Standards
 Existing System Data Model
 Current Process Model
 Trained Users for testing
 Project Management Plan
 Project Workplan
 Project Quality Management Strategies, Standards, and Procedures

Constraints and Assumptions

The conversion effort must operate within the following limits and assumptions:

Time Frames

Resource Availability

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Schedule/Critical Milestones

Oracle and <Company Long Name> will review and approve each project milestone
by using the standard acceptance criteria for each task deliverable produced.

In addition to the conversion deliverables, the following project milestones have

been identified:
Milestone Phase Current Conversion Actual Conversion
Milestone Date Milestone Date
Application Installation Operations November 30, 1999 TBD
Analysis
Configure Applications Solution December 10, 1999 TBD
Design
Complete legacy data Transition March 31, 2000 TBD
cleanup

Required Resources

This conversion has the following resource requirements:

 Project Manager
 Client Project Manager
 Business Analyst
 Application Specialist
 Technical Analyst for data mapping and design
 Developer
 IS Manager
 Client Staff Member
 Tester
 Database Administrator
 System Administrator
 User

Conversion Team Organization

The following are the criteria that were used to develop the structure of the
conversion team:

 conversion to be completed by <Provide a Date>, in time for Business System

Testing
 the number of business objects to be converted
 skills required for conversion
Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

 time estimate for conversion of each business object

 data reconciliation to be done by the users

Based on the above criteria, the conversion team can have one or more groups as
shown below.

Conversion
Lead

Group 1 Group 2 Group 3 Group 4

GL Open Balance, Customers, Cash Vendors, Invoices, Item, Qty on Hand
Assets etc Receipts etc BOM etc Item Cost etc

LEGACY System
Tech Persons (2/3)

Conversion Group 1

This group will be responsible for the following tasks:





Conversion Group 2

This group will be responsible for the following tasks:





Conversion Group 3

This group will be responsible for the following tasks:





Conversion Group 4

This group will be responsible for the following tasks:

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:





Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Roles and Responsibilities

The conversion project roles will be staffed by the individuals listed in the table below:

Conversion Role Oracle Team Member Oracle Team Member Position Client Team Member Client Team Member Position
Group #

Business Analyst
Database Administrator
Client Staff Member
Developer
Technical Analyst
User
Tester
System Administrator
Applications Specialist

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Conversion Resource Requirements

The following software and hardware requirements are considered components of

this conversion effort:

Software

The application software used as part of this project includes:

Existing Legacy Environment (Source)





Planned Oracle Environment (Target)





Hardware Environment

The hardware and operating software used as part of this project include:

Existing Legacy Environment





Planned Oracle Environment




Network/File Transport
Existing File Transfer and Network Capabilities

Planned File Transfer and Network Capabilities

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Experience/Training Requirements

The staff involved with this conversion must have the background, experience, and
training in the following areas:

Task ID Conversion Task Background/Experience

CV.010 Define Data Conversion Requirements and

Strategy
CV.020 Define Conversion Standards
CV.030 Prepare Conversion Environment
CV.040 Perform Conversion Data Mapping
CV.050 Define Manual Conversion Procedures
CV.060 Design Conversion Programs
CV.070 Prepare Conversion Test Plans
CV.080 Develop Conversion Programs
CV.090 Perform Conversion Unit Tests
CV.100 Perform Conversion Business Object Tests
CV.110 Perform Conversion Validation Tests
CV.120 Install Conversion Programs
CV.130 Convert and Verify Data

Below is a list of skills that the current conversion project team does not fulfill:





Specialty Tools

The risks associated with the skills that the conversion team does not currently have
can be mitigated through training, outside resources, or by using specialty tools.
Below is a list with descriptions of the specialty tools proposed for use on this
conversion project:





Business Constraints

This conversion must comply with the following business constraints:

Hardware Availability





Budget Constraints




Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Legacy System Decommissioning





Technical Standards and Architecture

The project deliverables will be developed subject to:

 any governing <Company Short Name> technology platforms strategy and

standards
 decisions made regarding the <Company Short Name> technical architecture
plan
 architectural connectivity issues in linking local environments to the central
or consolidation environment
 the Technical Architecture (TA) deliverables

Risks and Contingencies

Identified conversion risks include the following:

 incomplete definition of the conversion process

 lack of legacy resources to identify, document, and extract legacy data
 lack of tools to manage/manipulate data
 lack of understanding of project timelines and milestones
 poor data quality
 lack of understanding of required key data translation, clean-up, and
transformation criteria
 lack of reliable mechanism for data transfer

The contingency plans that should be put in place for the above risks follow:





Project Metrics

Key metrics for this conversion project follow:

 number of platforms:

 number of conversion business objects to design and build:

 number of database tables (may not be known):

 number of conversion modules that can be reused:

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

 number of source applications to convert from:

 volume of data to be converted and/or migrated:

 complexity of the data to be converted and/or migrated:

 number of legacy data sources:

 amount of required data cleanup:

 number of data translations:

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Conversion Strategy
This section provides a graphical description of the conversion approach that will be
used to convert the legacy data to the Oracle Applications. An explanation of this
strategy follows.

Legacy Systems
Internet
Computing
E Environment
n
v
i
r
o Client w/ Client w/
n browser browser
m
e
n
t Mainframe
Application Database
Server Server
ASCII
Legacy Data Flat File s Network

Interface Table Applicatio n Tables

S
t
D
o
a Relational
r
t non-Relational
a Database /
a ORACLE
g Indexed Files Database
e ORACLE
Oracle Apps
Manugistics

P Data Extract Data Load Data Interface

r
o
c
e
s
s
Data Valid ation /
Transformation

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Conversion Approach

1. Conversion Data Mapping

The data mapping process provides detailed lists of the data sets and data elements
that will need to be moved into the Oracle tables during the data conversion.
During this process, some decisions will need to be made with regard to obtaining
information needed by the target application that may not be present in the old
system. Default settings, user input, and new data entries are some of the issues
that must be addressed during this phase.

The output of this activity is data mapping tables that show what is needed for the
Oracle target application processing to meet business operational requirements and
where these data elements will come from. Based on this mapping, a design of the
legacy data extract is defined.

2. Download Programs

These programs are used to extract the identified conversion data elements from the
current systems in the form of an ASCII flat file. The tool that is used to accomplish
this task is usually dependent on the abilities and training of the current system
programmers . It is important to remember how the flat file will be structured (the
order of the records as they are pulled) , type of delimitation used, number of
records, etc. The flat files must match how the interim tables are set up. The output
from a download program is an ASCII flat file as described in the next section.

3. ASCII Flat File

Most database or file systems output data in text form. A comma or space
delimited, variable or fixed format data file from the existing system should be
generated. If you cannot find a way to produce clean text data, try generating a
report to disk, using a text editor to format your data.

One of the outputs of conversion data mapping is to identify the legacy data
element data types and precision. After the conversion data mapping is complete,
you should know if there are inconsistencies between the legacy data types and the
requirements for the Oracle data types. If there are translations that need to take
place, these translations can be performed on the legacy system prior to creating the
extract or in an interface table. Also, if you are creating a fixed length extract file,
you need to take into account the precision level of decimal numbers.

4. Upload Program

Once data has been put into an ASCII EBCDIC flat file and physically moved onto
the same computer that has the Oracle RDBMS, the next step is to load the data into
a relational database environment.

Programs must be written and run to move data, validate data, and insert/update
standard values into default fields. Usually a single loader program is written for
each data table being loaded.

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

5a. Description of Interface Table

The detailed technical description of any interface table that the data is placed into
from the ASCII flat file is prepared. An interface table that mimics the production
table into which the data will eventually be loaded into should be defined. This
allows you to manipulate the data as needed before loading the legacy data into the
production tables.

5b. Creation of Interface Table

Before loading the Oracle Application production tables, the legacy data should first
be loaded into temporary or interface tables. The interface tables provide a location
for you to manipulate and translate the data as needed before validating the data
and loading the application production tables. These temporary interface tables
need to be built before you run the loader script to populate these tables. The
interface tables may be standard Oracle Application interface tables or may be
custom interface tables.

6. Translation Programs
These scripts are developed to translate data from the existing system format into
useful data for the Oracle target application. An example of this might be taking the
date format that exists in the legacy system and converting it into an Oracle format.
There may be several or no translation programs, depending on both the type of
data coming across and the format of that data.

7. Interface Programs

The interface program scripts are used to populate the production database. The
purpose of the interface programs is not only to move the data to the target tables
but also to validate the data that would be validated by the form in the target
application if the data was converted manually.

8. Application Production Table

This is the final production data table where the converted data resides. These
tables are identified early on when doing the initial data mapping. These tables
drive some of the translation programs that must ultimately ensure that 100% of the
information that the target applications require is present in the final data
structures.

9. Testing

This test plan has been integrated into the entire conversion process so that, even
during the pre-conversion steps, some type of validation reports are generated from
the legacy systems, to be compared later with the converted data.

The approach taken is to use as many standard reports as possible that are available
in the legacy and target system for the final data validation. If no reports support
the validation requirements, then custom scripts will need to be created for specific
validation purposes.

10. Write and Perform Conversion Execution Plan

The conversion execution plan is the execution document that is to be followed

when performing the actual conversion. This document is specifically tailored for
the <Company Short Name> conversion.
Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Automated Tools

The following steps within the approach described above will be managed using the
automated conversion tool described below:





Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Conversion Process Flows

When converting specific business objects for a given Oracle application there are
business object prerequisites that must be followed. This section contains
conversion process flows for the Oracle Applications you are converting that
diagram these business object dependencies.

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

General Ledger Conversion Process Flow

General Ledger Conversion Process Flow Overview

Related Application Master Transactional

Prerequisites Data Data

GL GL

Set of Books
Balances:
Journal Import

Transactions:
FlexField Value Sets
Journal Import

Budgets :
Code Combinations: Bubget Upload
Journal Import

Legend:

Standard Interface Custom Interface Applic ation Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Accounts Receivable Conversion Process Flow

Receivables Conversion Process Flow Overview

Related Application Master Transactional

Prerequisites Data Data

GL AR AR
Set of Books
Quic kcodes
Invoic es:
Auto Invoic e
Code Combinations
Journal Import
Salesreps
Debit Memos: Credit Memos: Cash Receipts :
Auto Invoic e Auto Invoice Auto Lock Box

Sales Tax Rate:

SaleTax Rate I/F
IN V OnAccount Credit:
Auto Invoic e
Items:
Open Item Interface Customers:
Customer Interface

Legend:

Standard Interface Custom Interface Applic ation Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Accounts Payable Conversion Process Flow

Payables Conversion Process Flow Overview
Related Application Master Transactional
Prerequisites Data Data

GL
Set of Books

AP AP

GLCode Combinations:
Journal Import

Invoic es:
APQuic k Codes Invoice Import
PER

Locations

Bank Payments :
Vendors Auto Clear
Jobs Employees

Positions

Legend:

Standard Interface Custom Interface Applic ation Module

Note : Customers Entity can be implemented either in AR or OE

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Inventory Conversion Process Flow

Inventory Conversion Process Flow Overview

Related Application Master Transactional

Prerequisites Data Data

IN V

Items
Open Item Inte rfaces

Ite m Revisions
Ite ms Revis io ns Inte rface

Item Catagorie s
FND

Common Lookup Lot Numbers

MTL lot number I/F

Serial Numbers
Mate rial
MTLSeria l Number I/F
Transactio ns
GL
Receipts
Set of Books Retu rns
Ite m Sub Inv Is sues
Ite m Subin ventorie s OnHands
Account Numbers Transfe rs
In tr ansis ts

Item Sec Locations

PER Item Locatio ns
MTLTransaction I/F
Jobs /Positio ns
Locatio ns
Organiz ations
Emplo yees In vento ry Demand
Open Demand I/F

AR Pending
Ite m Sta tus
Tax Code
Accountin g Rules

Cycle Counts
Cycle Count Item

Physic al Invento ry
Physic al Inventory Tags

CST MRP
Ite m Costs Item Forecast
Item Cost Deta il Open Forecast Inte rfa ce

Legend:

Sta ndard In te rfa ce Custom In te rface Applic ation Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Bills of Material Conversion Process Flow

BOM Conversion Process Flow Overview

Related Application Master Transactional

Prerequisites Data Data

FND

Set of Books

INV

BOM BOM
Items:
Open Ite m Interface

Bil of Materials : Routings:

Open BOM Interface Open Routing Interface
Item Revis ions

Legend:

Standard Interface Custom Interface Application Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Work in Process Conversion Process Flow

WIPConversion Process Flow Overview

Related Application Master Transactional

Prerequisites Data Data

PER WIP

Locations Create WIPDis crete Jobs

Open Jobs / Repetitiv e Schedule I/F

WIP
Employees
Create ShopFloor MoveTransactions:
Open MoveTransaction Interface

Reschedule WIPDis crete Jobs

Open Jobs / Repetitiv e Schedule I/F
Create Resources Transaction:
Open ResourceTransaction Interface

IN V

Items:
Open Item Interface Create Repetitiv e Schedules
Open Jobs / Repetitiv e Schedule I/F

Legend:

Standard Interface Custom Interface Application Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

MRP Conversion Process Flow

MPS/MRP Conversion Process Flow Overview

Related Application Master Transactional

Prerequisites Data Data

PER MPS/MRP

Locations
Forecasts:
Open Forecast Interface

Employees

Master Schedules:
Open Master Schedule Interface

Master Schedule Relief:

Master Schedule Relief Interface
INV

Items:
Open Item Interface

Legend:

Standard Interface Custom Interface Applic ation Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Engineering Conversion Process Flow

ENG Process Flow Diagram

Related Application Master Transactional

Prerequisites Data Data

FND ENG BOM

Set of Books
Eng Change Order Eng Bil of Materials :
Order Import I/F Open Bil of Material Interface

Eng Routings:
Open Routings Interface
INV

Eng I tems:
Open Item Interface

Eng Item Revis ions

Legend:

Standard Interface Custom Interface Applic ation Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Purchasing Conversion Process Flow

Purchasing Conversion Process Flow Diagram
Related Application Master Transactional
Prerequisites Data Data

GL

Set of Books

GLCode Combin atio ns:

Journal Import

PO PO

Puchase Orders:
PER
Custo m Consultin g Solu tion

Locatio ns
PO Lookups

RFQ's :
Custo m Consultin g Solu tion Purchase Order Receip t:
Jobs Emplo yees Custo m Consulting Solutio n

Requisitio n:
Open Requis itio ns Inte rface
Positions
Quotation:
Custo m Consultin g Solu tion

IN V

Cate gorie s
(Item Cate gories)

Ite ms/Part Numbers:

Open Item In te rfa ce

Legend:

Standard Interfa ce Custo m In te rface Applic ation Module

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Order Entry Conversion Process Flow

Order Entry Conversion Flow Overview
Related Application Master Transactional
Prerequisites Data Data

GL OE

Set of Books OE Orders

Order Import In te rfa ce

Code Combin ations:

Journal Import
Setups

FND
Lookups &
Quickcodes OE

Pic k Rele ase

Profile Optio ns

Pric eLis ts

AR
Transactio nTypes

Tax Codes: Sales Tax OE

In terfa ce

Ship Confir m

Salespersons

Customers
Custo mers: Custo mer Customer In te rface
In terfa ce

IN V OE

Items:
Open Item Inte rfa ce RMA

Legend:

Standard In terface Custo m In terface Applic atio n Module

Note : Customers Entity can be implemented either in AR or OE

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Project Standards

Century Date Compliance

In the past, two character date coding was an acceptable convention due to
perceived costs associated with the additional disk and memory storage
requirements of full four character date encoding. As the year 2000 approached, it
became evident that a full four character coding scheme was more appropriate.

In the context of the Application Implementation Method (AIM), the convention

Century Date or C/Date support rather than Year2000 or Y2K support is used.
Coding for any future Century Date is now considered the modern business and
technical convention.

Every applications implementation team needs to consider the impact of the century
date on their implementation project. As part of the implementation effort, all
customizations, legacy data conversions, and custom interfaces need to be reviewed
for Century Date compliance.

Programmatically converted legacy data must be translated to the appropriate

century date state before being uploaded to the production tables. Manually
converted legacy data must be keyed into the data entry forms using 4 digits for the
year, where supported.

Tool Standards

A list of tool standards specific to the conversion effort follows:

Application Tools

Conversion Tools

Source Control

Version Control

System Management Tools

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Deliverable Naming Standards

The following table provides instructions on how to name files, programs, and other
project deliverables.

Program Type Format Extension Location/Directory Example

Upload Module
Download Module
Interface Table Creation
Module
Translation Module
Interface/Conversion
Module
Word Documents
Other Project Deliverables

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Data Clean-up Process

Data Clean-up

Specific business objects that are candidates for data clean-up include the following:





The strategy for meeting the above data clean-up requirements is as follows:





Key Data Translations

Strategic data that requires translation includes the following business objects:





The strategy for meeting the above data translation requirements is as follows:





Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Testing Strategy
The agreed upon conversion deliverables should be approved by the client
representatives who are responsible for the success of the conversion. In addition,
three levels of conversion testing have been identified and described in the Prepare
Conversion Test Plans deliverable (CV.070). The following criteria should be
considered while performing business object and conversion validation testing:

Application Business Object Test Criteria

GL Summary Balances Record Counts

Hash Totals
Balances
Journal Debits and Credits

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Acceptance Criteria
This conversion’s acceptance criteria will be measured by the completion and sign-
off of key deliverables as specified in the Project Management Plan [PJM.CR.010,
initial complete], produced in task PJM.CR.030. For some projects, these
deliverables will be subjected to a quality assurance review.

Each deliverable in the conversion process will be reviewed and approved by the
<Company Short Name> representative.

Additionally, each business object conversion may be subject to third-party audit

requirements.

Delivery

All conversions will be deemed to be delivered following successful business system

testing.

Data Acceptance

Conversion data acceptance criteria should include the following:

 transactability
 ability to reconcile financial information
 definition and acceptance of account level variances

Audit/Control

The audit and control requirements that need to be met are listed below:





Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Issue Tracking Procedures

Issue Management Procedure

All conversion issues will be tracked and managed as part of the overall project-
level implementation process.

Issue Resolution

All conversion issues will be resolved using the project issue resolution process.

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Version Control Procedures

All versions of instance information and conversion modules will be managed
under version/source control. The version source control strategy being used by
the overall project will be followed. Specific conversion version control standards
are discussed in the deliverable Conversion Standards (CV.020).

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Change Management
The scope and objectives of this conversion will be strictly controlled using the
Oracle Project Management Method (PJM). A detailed discussion of change
management is found in the Quality Management Strategies, Standards, and
Procedures (PJM.QM.010). Change management should be adopted at the overall
project level. Therefore, the conversion should use the same change management
guidelines used by each of the other AIM processes.

The following change management procedures will be followed:

 identify scope definition change

 review the identified scope change with management
 analyze the impact of the scope change on the schedule and conversion
project estimate
 review the scope change and obtain approval from overall project manager
 incorporate the scope change into the project workplans and budgets

Scope changes may be addressed and formalized for any of the reasons below:

 delayed delivery of legacy data extracts

 increased requirements for data-cleanup
 increased need for data translations between legacy data and target
application data
 delayed receipt of application code
 delayed change in accounting flexfield structure and segment values

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Quality Management
It is part of the Quality Management Strategies, Standards, and Procedures
(PJM.QM.010) scope to determine the governing quality system that will be in effect
for its deliverables and to define quality management procedures in detail to satisfy
the requirements of the quality system.

At a minimum, an independent quality review will be provided to address two

fundamentally different aspects of project activities:

 quality, completeness, and appropriateness of the project deliverables

 quality, completeness and appropriateness of project management, practices,
and procedures

The review participants are expected to be designated by both <Company Short

Name> and Oracle in accordance with the detailed quality procedures developed by
the overall project.

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Conversion Requirements
Disposition Type:

 M= Manual
 P= Programmatic
 A= Archival

Business Object Type:

 R= Reference
 D= Document
 T= Transaction
 H= Historical
 A= Aggregation/Roll-up

Business Ranking:

 M= Mandatory
 R= Preferred
 O= Optional
 W= Wish List

(1) (2) (3) (4) (5) (6) (7) (8) (9)

Application Sequence to Business Object & Business Disposition Data Frequency: Standard Oracle Open Comments/Open Issues
Module be Converted Business Object Type Ranking Type Volumes/ One Time/ Interface
Number of Periodic
Legacy
Sources

GL 1 Account Valid Values

2 Code Combinations Journal Import
3 Journal Entries Journal Import
4 Balances-: Summary Journal import
5 Balances: Detail Journal Import
6 Budgets Budget Upload
Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

(1) (2) (3) (4) (5) (6) (7) (8) (9)

Application Sequence to Business Object & Business Disposition Data Frequency: Standard Oracle Open Comments/Open Issues
Module be Converted Business Object Type Ranking Type Volumes/ One Time/ Interface
Number of Periodic
Legacy
Sources

PO 1 Employees/ Buyers
2 Vendors
3 Items Open Item Interface
4 Purchase Agreements
5 Quotations
6 Requisitions Requisitions Interface
7 Purchase Orders (Open)
7 Purchase Orders
(Closed)
8 Receipts
AP 1 Employees
2 Bank Accounts
2 Vendors
4 Invoices (Open) Invoice Import
4 Invoices (Closed) Invoice Import
5 Payments
5 Prepayments
6 Notes
FA 1 Mass Additions Mass Additions Interface
2 Production Production Interface
3 Budgets Budget Interface
AR 1 Salespersons
1 Tax Codes & Rates
1 Banks
1 Sales Tax Rates Sales Tax Rate Interface
1 Exchange Rate
Adjustments
2 Customers Customer Interface
3 Invoices: Open AutoInvoice
3 Invoices: Closed AutoInvoice
3 Invoices: Partially paid AutoInvoice
3 Commitments
4 Credit Memos AutoInvoice

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

(1) (2) (3) (4) (5) (6) (7) (8) (9)

Application Sequence to Business Object & Business Disposition Data Frequency: Standard Oracle Open Comments/Open Issues
Module be Converted Business Object Type Ranking Type Volumes/ One Time/ Interface
Number of Periodic
Legacy
Sources

4 Debit Memos AutoInvoice

4 On-Account Credit AutoInvoice
5 Cash Receipts AutoLockbox
6 Invoice Adjustments
OE 1 Items Open Item Interface
1 Price Lists
1 Salespersons
1 Tax Locations and Rates
2 Customers Customer Interface
3 Sales Orders (Open) Order Import
3 Sales Orders (Closed) Order Import
4 Sales Order Notes
5 Return Material
Authorization
6 Pick Release
INV 1 Subinventories
1 Locators
2 Items Open Item Interface
3 Inventory Receipts Open Transactions Interface
3 Returns and Open Transactions Interface
Adjustments
3 Item Revisions
3 Item Replenishment Open Replenishment
Interface
3 Item Costs
3 Item Demand Open Demand Interface
3 On-hand Quantities Open Transaction Interface
BOM 1 Resources
1 Locations
1 Departments
1 Alternates
2 Bills of Material Bill of Material Interface
3 Routings Routings Interface
Master 1 Employees

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

(1) (2) (3) (4) (5) (6) (7) (8) (9)

Application Sequence to Business Object & Business Disposition Data Frequency: Standard Oracle Open Comments/Open Issues
Module be Converted Business Object Type Ranking Type Volumes/ One Time/ Interface
Number of Periodic
Legacy
Sources

Scheduling/
MRP
2 Forecasts Open Forecast Interface
3 Master Schedule Entries Open Master Schedule
Interface
4 Master Schedule Relief Master Schedule Relief
Interface
ENG 1 Employees
2 ECO Departments
3 Engineering Items Open Item Interface
4 Eng. Item Revisions
5 Item Cross Reference
6 Engineering Change
Notice
7 Eng. Item BOM Bill of Material Interface
8 Eng. Routing Routings Interface
Capacity 1 Bill of Resources
2 Bill of Resource Sets
WIP 1 Resources Open Resource Transaction
Interface
2 Material (Serial Material Transaction If you are using serial number or lot
Numbers & Lot Interface/ Serial Number number control then use the Serial Number
Numbers) Interface and Lots Interface and / or Lot Number Interface.
2 WIP Floor Transactions Open Move Transactions
Interface
2 WIP Material Open Move Transactions
Transactions Interface
2 WIP Completion Open Move Transactions
Transactions Interface
3 Discrete Jobs Open Job and Repetitive
Schedule Interface
4 Repetitive Schedules Open Job and Repetitive
Schedule Interface
Projects 1 Project Templates
2 Projects Capital, Contract, and Indirect Projects
3 Tasks
4 Budgets Cost and Revenue Budgets

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

(1) (2) (3) (4) (5) (6) (7) (8) (9)

Application Sequence to Business Object & Business Disposition Data Frequency: Standard Oracle Open Comments/Open Issues
Module be Converted Business Object Type Ranking Type Volumes/ One Time/ Interface
Number of Periodic
Legacy
Sources

5 Agreements
6 Funding
7 Expenditures
8 Revenue
9 Invoices
HR/Payroll 1 Locations
2 Organizations
3 Jobs
4 Grades
5 Positions
6 Employees
7 Positions
8 Pay Elements
9 Pay Elements History
10 Deductions
11 Deductions History
Oracle Sales & Sales Force
Marketing
Companies Prospects and Customers
Company Contacts
Events
Event Facilities
Collateral Product Literature
Advertisements
Sales Territories
Action Items
Marketing Programs
Mail or Call Scripts
Letters Cover letters to send with product
literature
Forecasts

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

Business Object Conversion Selection Criteria

Define the selection criteria for each of the business objects that are being converted
as identified in the Conversion Requirements table in the previous component.

The selection criteria are:

 Historical/Active Periods
 Date Ranges
 Active/Obsolete
 Acquired/Dissolved/Sold-off
 Number of Periods

Business Object Selection Criteria

AP Invoices Open (Unpaid) status only

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only
 Doc Ref:

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

Acceptance Criteria
File Ref: 380628433.doc (v. )
Company Confidential - For internal use only