O2C C 2351 PIR Conversion

O2C_C_2351_PIR_Conversion
8/11/2015
Functional Specification Document
Functional Team P2P

Functional Project Lead Pat Kenney
Original Author(s)
Current Revision Author(s)
Version Date Author(s) Revision Notes Approved Date of

By Approval
1.0 Michael Initial version
GriffithAuthor
1.1 Aravinda Section 2
GururajAuthor
1.2 AuthorSuresh Mapping update
Functional Specification – Conversion – Template v2.1 Page 2 of 28

Table of Contents
1 EXECUTIVE SUMMARY...................................................................................................5
1.1 OBJECT INFORMATION AND ATTRIBUTES........................................................................5
1.2 DETAILED TESTING REQUIREMENTS................................................................................5
1.3 BUSINESS DRIVER............................................................................................................6
1.4 DESIRED FUNCTIONALITY OVERVIEW.............................................................................6
1.5 ASSUMPTIONS...................................................................................................................6
1.6 PROJECT / DEVELOPMENT CONSTRAINTS........................................................................6
1.7 PERFORMANCE CRITERIA.................................................................................................6
1.8 APPLICATIONS AFFECTED................................................................................................7
1.9 DATA VOLUME.................................................................................................................7
1.10 DATA QUALITY METRICS................................................................................................7
1.11 OTHER OBJECTS AFFECTED.............................................................................................7
2 DETAILED REQUIREMENTS...........................................................................................8
2.1 PRICEFW TYPE SPECIFIC INFORMATION – CONVERSION...............................................8
3 ADDITIONAL INFORMATION.......................................................................................18
3.1 BACKUP / RECOVERY.....................................................................................................18
3.2 INFORMATION SECURITY................................................................................................19
3.3 SECURITY ROLES (PROFILES AND AUTHORIZATIONS)...................................................21
3.4 AUDIT.............................................................................................................................21
3.5 CONVERSION ERROR HANDLING....................................................................................22

1 EXECUTIVE SUMMARY
**For Estimation Purposes, fill out the full Executive Summary in detail**
1.1 Object Information and Attributes

The following is current information about this object and document:
Object ID O2C_C_2351
Title O2C_C_2351_PIR_Conversion
Dev ID 351
FDD ID 15.03.00_400
Team Which Owns P2P
the Object
System Version ECC 6.0
Development Type Conversion
Priority Medium
Disposition Draft
Estimated ComplexMedium
Complexity
Release R2
Related Business O2C_003_R2_15.03.00_Vendor_Master
Process Flow
Association to Other Actual name of the associated FSpec, which this Functional Specification is
Functional utilizing
Specification
Approver(s) & Date Pat Kenney
& Version Dan Gillis
Paul GrimoneAuthors
1.2 Detailed Testing Requirements

FSD Rqmt ID Short Title (limit 100 chars) Description
1 Source Data Validation Validate Source data from legacy systems is
accurately Identified
2 Validate Source Data output is Validate source data is within a format which is
ingestible into SAP consumable by SAP
3 Legacy values successfully Validate all transforms are accounted for (e.g.
transformed (where applicable) Legacy Vendor Number Transformed to co-relating
SAP Supplier Number
4 Confirmation of roll back Validate risk mitigation of rollback of Source data
load SAP in the event data is mis-mapped, omitted,
experiences loading errors etc.
5 Validation of successful Validate all Source data attributes are successfully
placement of data within the mapped to correct SAP target tables /fields
target system
6 Creation of PIR Validate that Purchase Info Records were
successfully created
7 Beta “test” load The conversion will be initially tested with a small

defined record set to be converted within the SAP

application
8 One time Load Upon successfully completing the “Beta

conversion” the full conversion shall be a one-time
upload into the SAP application.
9 QA of converted data within SAP A comprehensive QA effort shall be in place to

ensure all data was successfully ingested into the
SAP application and that 100% of the data reached
its target location successfully
1.3 Business Driver

Overview of Purchase Info Record (PIR)
The Purchase Information Record (PIR) serves as a source of information for Purchasing. The PIR
contains information on a specific material and a vendor supplying the material. For example, the
vendor's current pricing is stored in the info record.
Additionally, the info record allows:
 Identification of which materials have been previously offered or supplied by a specific vendor
 Indication of which vendors have offered or supplied a specific material
 Ability to set tolerance Limits for Over Deliveries & Under deliveries
 Reminders
 Planned Delivery Time ( Lead time required by the vendor to deliver the material )
 Info record memo
o An internal note or comment that is adopted in the PO item. The info record memo is not
printed out.
 PO text in info record
o This text serves to describe the order item and corresponds to the PO text in the material
master record. It is adopted in the PO item and included in the printout
Purchase Info Records will be created in SAP for the purpose of providing the above benefits and
moreover allow for the “No Touch” creation of purchase orders as needed (e.g. fixture orders). The
rationale for this decision is due to the sheer volume of said orders that are currently created on regular
basis
1.2.1 Alternatives to Object
If Purchase Info Records were not created for materials, the ability to create purchase orders in
an automated fashion would not exist.
That being said, all Purchase Orders would have to be manually created. Which in turn adds a
very large manual effort of creating Purchase Orders for various items (e.g. copious amounts of
fixture orders that are sent to Westrock today)

1.2.2 Impact of Implementation

Allows for the ability for the creation of purchase orders in an automated fashion.
1.2.3 Impact of No Implementation

The only option for Purchase Order creation shall be manually
1.3 Desired Functionality Overview

This conversion object shall contain defined values to be loaded into the Purchase Info Record for each
material type. This data shall be obtained from a single legacy system Sybase: -
Access the SYBASE report for the conversion data is displayed below
 Server Name – irs2crs
 Server Port – 20599
 Data Source Name - DO REPORT 32
 DOReport 32 - Adaptive Server Enterprise
 Database Name – db_dir00
 DataBase Table Name - Dbo_do_hist_fy03
 Description – DOReport 32
**FLAT FILE will be provided from SYBASE system for extraction
Once identified this source data point shall be converted from legacy source system to the target system
(SAP).
The Legacy Vendor Number shall be Transformed to SAP Vendor Account Number = ( LIFNR)
via the existing vendor number cross reference process within MDM
Organizational field such as Purchase organization are updated in the conversion file before upload to
SAP.
Material group , Purchase group are extracted from Material master tables to update in conversion file.
Conversion file is stored in Application server with given Menu path. System will extracts records from
conversion file and upload to SAP to create Purchase info record.
1.4 Assumptions
 All Master Data and Organization Structure will be set up prior to entering sales orders.
 SD Organizational Data should be in place
 Vendor Master conversion is assumed to have been handled in Release 1.
 Vendor master data will exist in SAP for vendors that AG procures NPC, Direct Import,
(Evdy Replenishment & Ornaments; Wal*Mart cross-upplied Pallet Train Programs;
Retail Sales Promotion; and REX Fixture product from in Release 2, vendors in SAP
have been approved by AG Global Sourcing
 Material Master conversion should be done
 Material Master will contain the material country of origin and the material tariff code
 Conversion Data is accurate and up to date

 Data required for the creation of a Purchase Info Record shall reside within AG legacy
systems. Said data points shall have the ability to be placed within a file format that is
ingestible within the SAP system.
 Prior to go live the conversion shall be performed again to ensure that any data changes
are loaded into SAP prior to go live
 R1 vendor master create/modify process will be utilized in R2. Drop ship vendors will
require purchase view extension in SAP
 Existing Shared Services vendor form will be used to initiate change/modify and
additional fields will be added to support drop ship vendor requirements
 WestRock will be the vendor for fixtures in R2
 Products or fixture components that are purchased domestically or from Asia sources and
imported or manufactured directly and distributed through AG distribution centers are not
in scope with the exception of NPC
 Plus Mark will remain on Oracle for Release 2
 Info Access service to process vendor invoice processing will be utilized for Release 2
 Cost accounting group will continue to enter standard costs for RockTenn fixtures into
the cost accounting legacy system which feeds MRP (The purchase price will be entered
into SAP on the PIR record)
 AG is Use Tax EXEMPT for RockTenn fixtures
1.5 Project / Development Constraints

 Organization structure is configured
 Customers are loaded
 Materials are loaded
 Vendors are loaded
1.6 Performance Criteria

Performance Requirements for Conversions will be known onc mapping acquired
Average Transactions / Records and Type per Conversion Approx.. 25,000 records for the conversion run
Run:
Peak Transactions / Records and Type per Conversion Run: Approx. 75,000 records for conversion prior to
go live
Required Throughput For Conversion: Conversion should be completed within 2 –
4 hrs.
1.7 Applications Affected

Description:
Outline a list of application areas being changed or affected by this design including both SAP
and non-SAP (legacy) systems. . Note: Additional detailed analysis and detailed application
mapping will be completed during Blueprinting, and captured in section 2.1.
SAP Modules Affected

SAP Module Impact/Change Description
SAP ECC Other Master data process

JDA Modules Affected

JDA Module Impact/Change Description
N/A
Legacy Systems Affected

JDA Module Impact/Change Description
N/A
1.8 Data Volume

Material listing conversion will require approximately 100,000 entries to support the initial load.
1.9 Data Quality Metrics

100% data completeness and accuracy
1.10 Other Objects Affected

Description:
In order to better understand the total impact of this Functional Specification, please describe
other known related/impacted PRICEFW objects. It is important this step be done with
reasonable thoroughness. Think carefully through both downstream impacts and upstream
dependencies. Please discuss with your Development Architect or Tech Arch. Team member. .
Additionally, this should include impacts from both legacy and SAP/JDA perspectives.
Object Impact/Change Description

Purchase Order WT / Andrew
Objects

2 DETAILED REQUIREMENTS
2.1 PRICEFW Type Specific Information – Conversion
Description:
Identify the data requirements of this conversion including the business object, date range to be
considered for extracting information from Source System(s) for conversion, data cleansing and
detailed data mapping requirements. .
Conversion Business Object

Business Object Conversion
Business Object Purchase Info record Conversion
Description
Date Range Considered Active PIR records as on Cutoff date
for Conversion
Conversion Method
1.Data will be collected from multiple servers, and staged via BODS.
2.Custom program or LSMW Project can be developed to load PIR data
Business Object Retention & Archiving Requirements
Extraction :
At present, the legacy system does not contain Purchase info records. We will need to extract last Purchase Order
data for active vendor /active material combination with latest price in a text file as per the mapping fields.
The AG Client team will be responsible for extracting data from the legacy systems. The reason being that this
activity will include data scrubbing activities that must be performed by ISD Client IT (removing duplicates and
unnecessary records). Additionally, ISD Client IT will use vendor cross-reference report to translate the legacy
vendor number to SAP vendor number. The SAP vendor number will be populated in the file. Only data
extracted and scrubbed from the legacy systems will be migrated to the new SAP system. BODS will be used to
upload this data to SAP. Remaining fields to be populated in the PIR will be inherited from the Vendor and
Material Masters.
Transformation:
Fields that are required in SAP but not available in Legacy system will be populated via with BODS interface.
Further detail of these fields is available in the mapping document.
We are having single Purchasing organization 1000-AG Global which will be updated as default value under
purchasing organization field. All the purchasing info record are created with info Category “Standard”.
Upload
Conversion file is available in Application server with menu path.
Using a middleware (e.g. BODS) interface, this data will be uploaded and populated in the appropriate fields in
the SAP PIR.
There should be a detailed log which indicates success/failure records, information on PIR number vendor master,
Material masterPricing validity dates will be defaulted to the date of entry to 12/31/9999
PIR number Vendor code Material Ref.Number Success / Remarks

master Failure

Application Name Source Destination

SAP /JDA Module
< e.g. SCOPES>MRP
< List Application Name1>
Note: For Source Application Conversion, the preferred option via ETL BODS is File or
Database Table and applies for all the applications listed above.
Due to the fact that the same file structures are generated by multiple source systems to a
single destination, you will need to list each source system. The BODS Staging
environment will consolidate the data for the Target system.
Source Systems Contact Name

 SYBASE System details <Provide contact name and info for each
 Server Name – irs2crs system >
 Server Port – 20599
 Data Source Name - DO REPORT 32
 DOReport 32 - Adaptive Server Enterprise
 Database Name – db_dir00
 DataBase Table Name - Dbo_do_hist_fy03
 Description – DOReport 32
>
Source 2
**For Estimation Purposes, define the number of input files**
Number of the Input Files
One
Two
Three or more
**For Estimation Purposes, estimate how many fields are required for the conversion**
# of Fields
Less than 50 fields

50 to 90 fields
100 or more fields
**For Estimation Purposes, estimate how many fields will require special transformation rules
(e.g. require reading a table to put the appropriate value in the field)**
# of Fields Requiring Special Transformation

Rules

0 fields
1 - 2 fields
3 or more fields

**For Estimation Purposes, is there a SAP/JDA pre-formatted record that can be used?**
QUESTION YES NO
SAP/JDA pre-formatted
record available?
2.1.1 Pre/Post Processing (including Data Cleansing & Business Rules/Logic)

Description:
The Functional Team member will define the pre/post processing business rules, logic for data cleansing
and data verification, as well as predecessors/dependencies.
Pre-Processing Business Rules
2.2 ALL PRE-PROCESSING WILL BE MANUALLY PROCESSED BY ISDClient IT team
1. Data extracted from Legacy system are arranged in given format
2. SAP Vendor number will be converted from legacy Vendor Number by ISD Client IT
team at time of extraction using the Vendor Cross Reference
(PI\EXPORT_F2MI038\f2mi038.VendorCrossRef.txt).
Post-Processing Business Rules
1. All the active records uploaded and processed should not have any difference i.e. the
number of agreements loaded in SAP and those created should match/tally. This will
be manually validated.
Data Cleansing Logic/Approach

>
The LegacyVendor Number shall be obtained from the source system (SYBASE) The Legacy Vendor Number
shall be Transformed within middleware via a cross refrence table to match to the SAP Vendor Account Number
Data Verification Logic/Approach

< Describe the logic/approach that will be used for data verification. Define how will it be determined that the
Conversion has been run successfully? What validations will be made to determine that the number of records
extracted is correct? How will it be determined that the records imported into the target system are imported
correctly? Who will be responsible for the testing/validation? Will reports be run out of the source or target
system? Will special reports be required? Be specific as possible, since this information will be used as input to
in the Conversion and Acceptance test plans.>
Extract data from

legacy system.

Input default data /

Convert data
Upload file in SAP

system
**For Estimation Purposes fill out the Post Execution Notification Details in terms of listing whether a
report, email notification or workflow is required.**
Additional Processing Requirements for this Conversion

Information Needed Description
What are the predecessor
processes & dependencies Purchasing Organization
for this conversion? Plant
Material master
Vendor master
Conversion Process Log

Details Log file should be able to get it downloaded to local system
Post Execution Notification
Details (if applicable) Log file
Other processing <List any additional processing requirements not captured above>
requirements?
Not Needed MLG.
Extension of Standard Table/Structure or New Table (if applicable)

Description: For each extension or new table copy and fill out the section below. For extension just show
the new fields to add.
Standard Table/Structure: <Name> OR New Table Name: <Name>
Field Name Key Field type Description
<Field Name> <Y/N> <Char / Numeric / Amount / <Description of field including any default
Date / Time> values>

**For Estimation Purposes, list the proposed interface development tool (standard BAPI, standard SAP/JDA
program, standard IDOC, custom BDC, custom BAPI, LSMW, custom IDOC, JDA SQL Script, etc.) – done by Tech
Arch. Team member/Dev. Architect**
Proposed Development Tool (done by Tech Arch. Team member/Dev. Architect)

Proposed Development Tool(s) <Put in the proposed development tool like Adobe print forms, etc. from the Development Tools
Strategy including if there is an interface report>
Reasoning for Proposed <Reasoning behind the choice of the proposed development tool>
Development Tool(s)
Proposed BAPI, IDOC, etc. <List proposed BAPI, IDOC, etc.>
**For Estimation Purposes, if custom BDC is the proposed development tool then fill out the following section**
SAP/JDA Transaction(s) Required for Interface

SAP/JDA Transaction(s) used <List the SAP/JDA Transaction(s)>
for the interface
Number of possible screens for <For each SAP/JDA Transaction list the number of screens>
the SAP/JDA Transaction(s)

2.2.1 Selection Criteria/Screen
Type of Field (Check Search Help / Single/Multiple

Box / Radio Button / Pick List / Validation Comments /Range/all
Field Selection Text / Select-Option / List of values Required Default (Mandatory possible
Name Description Parameter) (Y / N) (Y / N) Value / Optional) combinations
2.2.2 Detailed Data Mapping

Description:
For the Conversion, identify the detailed mappings from the SOURCE application(s) to the TARGET system. This will require the Functional Team
Member to work with their Technical counterparts to obtain the required information. This section will include details regarding data cleansing,
reconciliation and data consistency checks.
Identify the source that was used to document the TARGET fields that will be used for detailed data mapping– <Screen, ETL, File, Database Table>.
Identify the necessary TARGET fields in the detailed data mapping sheet below. Please indicate the type of integration types used to describe the
elements in the mapping. If you use the standard SAP/JDA form screens elements to identify the data elements to be used for integration, mark the same.
Likewise check mark the object used for identifying the data elements in the mapping spreadsheet. Note: The actual integration type used between systems
will be defined and designed in the Realization phase in the technical specs.
SAP/JDA Fields
Screen
ETL
File
Database Table
JDA SQL Script

Description:
Complete the mapping sheet which includes a definition of all data fields needed for this conversion. . For each additional SOURCE application, you may use an
additional data mapping spreadsheet, but can use the TARGET data fields defined already. As a norm, data conversion file format will be provided by SAP/JDA.
The mapping sheet will also describe the detailed mapping including transformation and business rules to be applied.
Detailed Data Mapping to Source System(s)
Source Application Source Application Source Application SME Contact Source Application Detailed Data
Sample Data
Name Description Info Conversion Type Mapping
<Name of Source <Describe the source <List the name & contact <Identify the source that was <Provide multiple sets
Application> application> information of source system SME. used to complete the detailed of sample data so that
Has the SME been made aware of data mapping to the SAP a full picture of the
our need to extract data?> fields – Screen, Report, File, TA.DEV.007_Functio requirements can be
Database Table, Application realized. Data
nal Specification Template - Conversion ThisMapping
can be v1.1.xlsx
JDA SQL Script> <Reusable an embedded file or
Template> link to sample data.>

**For Estimation Purposes, please list each field which has to be derived in the conversion and a brief description of the calculation/transformation**
Calculations / Transformations
Value to be Derived Business Rules / Algorithm For This Transformation
<Name> <description of calculation/transformation >

2.2.3 File/Table Descriptions (if applicable)

Description:
Describe the overall input file sources (complete this section if file was selected above as source or
target) required to support the object.
Input File/Table Requirements (if applicable)
Information Needed Description
Logical File Name < Name file is commonly known by>
File Description < Description of type and purpose of the file>
Variants <Variants in Logical File Name if used>
System Name <System the file is associated with >
Physical File Location & <Name and directory path of file >
Name
Selection Requirements < Selection criteria if required>
Empty Files < Are empty files to be expected/permitted as part of normal processing?>
Sort Order For Incoming <list of columns for the default sort order and indication on ascending or
File / descending for each column>
Length of Time to Archive <X Days, Months, Years, etc.>
the Source File

Conversion Report Layout (required)

Description:
It is required to show the Technical, Functional and Business Statistics of a Conversion result.
The Technical report is automated, the Functional and Business will require automation and
manual input to reflect the quality dimensions. Any Pre-Processing Steps required will also have a
Pre-processing validation report before committing conversion loads. The requirements for
reports show statistic’s or details about the conversion (not an error report), the the Functional
Team member will capture or describe the desired report layout here, or would attach a document
that provides a graphic illustration.
**For Estimation Purposes, please show a mock-up of each screen of the report**
[Insert the Report Layout]

Conversion Report Field Definition (per different page) –if applicable:

Description: Identify the fields & parameters of this Report. For each different page of the report (there should be
this section below), so if there are two different pages then there should be two of these sections filled out
Description of Each of the Fields on the Report
Field / Description Source Of Data For Field Default Value If Not Given Length
Report Header:
 <Field Label – Description of field> <Table / Field or calculation <Zero, Spaces, Null Values, Value> <$ZZ,ZZ9.99,
or transformation>


Report Body:


Subtotals / Totals:


Footer:

Conversion Report Processing Requirements

Description: Identify the processing requirements for this report in the sections below.
**For Estimation Purposes, please list each field which has to be derived in the report and a brief description of the
calculation/transformation**
Calculations / Transformations
Value to be Derived Business Rules / Algorithm For This Transformation
<Name> <description of calculation / transformation>

**For Estimation Purposes: For a Conversion Report only, please fill out the Default Sort Order, Sortable Columns
and Pagination**
Sort Order and Pagination Requirements

Formatting Description
Default Sort Order <list of columns for the default sort order and indication on ascending or descending for each
column>
Sortable Columns <list of columns that the list can be sorted by after the initial list is loaded; will only apply to
on-line reports>
Pagination <define section breaks and page breaks for the report>
Header <identify the header information that will be repeated on each page of the report>
3 ADDITIONAL INFORMATION
3.1 Backup / Recovery

Description:
The Functional Team member will define the backup/general recovery strategy for the conversion
business object. The Functional Team will come to consensus on data loss acceptance and
downtime allowed by application. As much as possible, teams will reach consensus for both
transactional systems and planning systems. Once agreed on this, the Functional Specifications
will be consistent by team regardless of who the author is. Therefore, a standard approach for
backup and recovery is being identified.
For this Functional Specification, identify any unique backup/recovery needs. Where is the system
of record? Unique requirements will most likely come from inbound interfaces from 3 rd party
systems.

3.2 Information Security

Description:
IT Security will review the information contained within this specification and lead security
requirements implementation with the Functional Teams and technology.
Access to form, report, enhancement, portal, workflow object is dictated by the security role
authorizations assigned to the user. The authorizations would be based on the role defined for
executing the task/activity.
3.3.1 Information Classification

Description: This section has been pre-filled with certain defaults for the One AG project;
please review and collaborate with security team to update this section.:
General Information
Businesses Impacted:
Sourcing, Cost Accounting
Information Classified by whom: Date
Contact Information
Company Name Phone E-mail Address
List Potential
Information Owners:
Architecture
Environments: (impacted by this Fspec): Development Test Training Production
Public (Internet) Facing Internal Only
Architecture: (system exposure): 3rd Party Hosted Company * Hosted
Identity & Access Management

During Project Yes Offshore? Yes List the 3rd Capgemini team
3rd party system access required? No No Parties:
Post Implementation Yes Offshore? Yes List the 3rd Capgemini team
3rd party system access required? No No Parties:
Business Impact Analysis
What may be impacted if the system or information/data is compromised? Check all that may apply.
Company Reputation/Trust Regulatory

Associate Relations Compliance
Competitive Advantage Securities & Exchange Commission (SEC)
Financial Impact Payment Card Industry (PCI)
Productivity Sarbanes-Oxley (SOX)
Supply Chain Privacy Laws
Contractual (i.e. NDA’s, MSA’s)*
Input any additional details related to business impact in the event of compromise:
*NDA – Non-Disclosure Agreement, MSA-Master Service Agreement


Information Classification
Action #1: Check the box below that represents the most restrictive classification.
Action #2: If Level 1 or 2 is selected, check the box below indicating data storage or data transmission.
Information has been defaulted to level 3. Please review and update in collaboration with the security team
Level 1 – Confidential – Secure Handling Required “SHR”
Confidential – Secure Handling Required represents the most sensitive data classification related to individual personal
identifiable information and personal financial account information. This information considered critical to AG such that, if
disclosed, may disrupt or impede business operations, and due to legal, reputational, or operational concerns, requires
additional security controls. Information in this category includes, but is not limited to:
1. Social Security Number
2. Driver’s License Number or Government-issued Identification Number
3. Financial Account Number (card number or personal bank number)
4. Protected Health Information & Electronic Protected Health Information
SHR data stored? SHR data transmitted? SHR data stored and transmitted?
Level 2 – Confidential
Confidential represents the second most sensitive data classification related to operationally significant business information.
This information considered critical to AG such that, if disclosed, may disrupt or impede business operations. Examples of
Restricted Confidential include but are not limited to regulatory governed data, trade secrets, mergers and acquisition
discussions, product formulas and designs, corporate earnings data prior to public announcements, reorganization details prior
to announcements, current/closed company investigations and litigation, detailed network diagrams that could jeopardize
network security, strategic development/marketing plans and information integral to the success and operations of the
company.
This includes: Pre-release aggregated financial data relevant to U.S. Securities and Exchange Commission oversight; AG’s
own commercial bank account numbers (i.e. where AG makes deposits, pays checks and executes ACH transfers for their own
account)
Confidential data stored? Confidential data transmitted? Confidential data stored and transmitted?
Level 3 – Internal AG Use Only
Internal AG Use Only represents the third most data. It represents information that is less critical to privacy and business
operations but still must not be publicly disclosed. This information is not approved for general circulation outside AG.
This includes most transactional financial information.
Level 4 – Public
Public represents information that has been declared public knowledge by the information owner and can freely be given to
anyone without any possible impact to AG. As a result, no special data handling protections are required.

3.3 Security Roles (Profiles and Authorizations)

This section should define the general security administration for this design. SAP/JDA Security
roles, profiles and authorizations will be finalized after Blueprint. Define the general security for
this design including any organizational level restrictions required. List a Standard
TCode/Report/Object that most resembles the custom development. Outline general
authorization checks for special reports and/or enhancements due to data classifications and any
other special security considerations.
Security Requirements for Conversions

Security Type Role Access Allowed
Authority to Request N/A <Roles allowed to request the Conversion or “N/A” if
Conversion automatically requested>
Authority to View < Role 1> <Roles allowed to receive the Conversion >
Conversion Files < Role 2> TBD During TSD
Authority to View < Role 1> <Roles allowed to receive the Error Report>
Error Report < Role 2> TBD During TSD
Field Level Security < Role 1> <Any restrictions on the fields on the Conversion that
< Role 2>TBD During TSD individuals with this role can either see>
Data Security < Role 1> N/A <Any restrictions on the data that someone with this
< Role 2> role can either see and/or update>
3.4 Audit
Audit Trail Requirements
Audit Event Description Audit Trail Updates
Last Modified Date Being another PIR load will be <Date last modified YYYY/MM/DD>
needed prior to go live go live a
audit trail to identify know of
updated data attributes at time of
final conversion

3.5 Conversion Error Handling

Description:
Functional Teams are responsible for the design of their functional error logs (i.e. detail,
messages, frequency, types, format, etc) which will include procedures for error resolutions.
Functional errors are defined as those which can occur as a result of normal application
processing (e.g. user inputs a vendor which is not found in the vendor master, numeric field above
a certain value, etc.). Technical errors are defined as those which can occur as a result of faults in
the underlying infrastructure (e.g. out of disk space) and are automatically reported/handled as
part of a runtime framework already in place for applications and interfaces.
Note: Detailed error descriptions will be identified in the Data mapping section. This section
defines how to report those errors.
Failure Points
Possible Point Of Rules For Handling Failure
Failure
<Failure Point> “Display error message on screen and continue”, “
Write error to error log and continue processing”, “Terminate the screen and
contact the systems department, etc.>
Data Input Display Validation error message for the Data Element. e. g. Date Range entered
Validation on the and request input of correct date range. The Start Date Range cannot be greater
screen than the End Date.
Data Validation of Capture the transaction record having the data validation error and log it in an
the file/message, error report. Also capture the key fields identifying the record and the offending
when it is picked up data element with relevant message describing the error. The Error Report needs
by PI. to be sent via an email alert. The Source system should fix the transaction
file/message and resend the file/message.
Mapping and Send an email alert for the offending message to the PI Support team. The PI
Transformation Support Analyst would need to analyze and identify and recommend resolution.
Error
Business Rule Flag the transaction record in the staging table to be an “Application Error” and
Validation and display an error message indicating type of error, with recommended fix if
Application Logic possible. A notification needs to be sent with the list of transactions that are in
Processing Error error and the type of error for each transaction. The user should be able to review
the transaction make necessary correction, and be able to resubmit transaction for
processing.
Cross Reference Flag the transaction record to be an “Application Error” of type X-REF Error and
Error send email notification. The notification should list the data elements with missing
cross reference and guide user to update the Xref Master table. The transactions in
error need to be reprocessed upon initiation by the user, after the Cross Reference
Master has been updated

Error Report Requirements

Information Description
Needed
Error Notification <Identify who/how to be notified – Report, Email Notification, etc.>
Notification:
Error Type Who
Application Email Group(if it exists); Functional Area/Sub Area Group
System Email Group(if it exists); Functional Area/Sub Area Group
Warning Email Group(if it exists); Functional Area/Sub Area Group
Reports when generated will be saved on to file system for further display and
rendering through Portal/AL11
Error Logging <Identify how/where errors are to be logged>
(beyond
notification)
Error Remediation <Identify what procedures are required to clear the error and (if applicable)
resubmit/re-run? .>
Error Report Layout (if applicable)
[Insert the layout of the error report]
Description of Each of the Fields on the Error Report (if applicable)

Field / Description Source Of Data For Default Value If Length Formatting
Field Not Given Rules
Report Header:
 <Field Label – Description of <Table / Field or <Zero, Spaces, <$ZZ,ZZ9.99,
field> calculation or Null Values, MM/DD/YY
transformation> Value> Bold, Colors>


Report Body:


Subtotals / Totals:


Footer:

Sort Order and Pagination Requirements for the Error Report (if applicable)
Formatting Description
Default Sort <list of columns for the default sort order and indication on ascending or descending for each
Order column>
Sortable <list of columns that the list can be sorted by after the initial list is loaded; will only apply to
Columns on-line reports>
Pagination <define section breaks and page breaks for the report>
Header <identify the header information that will be repeated on each page of the report>
Distribution Requirements for the Error Report (if applicable)

Rule Description

Distribution Requirements for the Error Report (if applicable)

Rule Description
What are the <List of rules by role for which sections of the report each role/actor will receive>
rules for what
sections of the
report each role
will receive?
How is this <Printed centrally and distributed, printed on local printer, available for viewing online, sent
report via e-mail attachment, sent electronically>
distributed?
What size paper <8 ½ by 11, 8 x 14, etc>
will be required
for this report
Are any special <List the form, N/A>
forms required to
print this report?
What is the <Landscape or portrait>
layout for this
report?
Are there any <List, None>
other rules for
distributing this
report?
Archiving Requirements for the Error Report (if applicable)

Rule Description
Length of Time <X Days, Months, Years, etc.>
to Archive the
Error Report

O2C C 2351 PIR Conversion

Uploaded by

Copyright:

Available Formats

O2C C 2351 PIR Conversion

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

O2C C 2351 PIR Conversion

Uploaded by

Copyright:

Available Formats

O2C_C_2351_PIR_Conversion

Functional Team P2P

Version Date Author(s) Revision Notes Approved Date of

Functional Specification – Conversion – Template v2.1 Page 2 of 28

Functional Specification – Conversion – Template v2.1 Page 3 of 28

1.1 Object Information and Attributes

1.2 Detailed Testing Requirements

Functional Specification – Conversion – Template v2.1 Page 4 of 28

defined record set to be converted within the SAP

8 One time Load Upon successfully completing the “Beta

9 QA of converted data within SAP A comprehensive QA effort shall be in place to

1.3 Business Driver

1.2.1 Alternatives to Object

Functional Specification – Conversion – Template v2.1 Page 5 of 28

1.2.2 Impact of Implementation

1.2.3 Impact of No Implementation

1.3 Desired Functionality Overview

Functional Specification – Conversion – Template v2.1 Page 6 of 28

1.5 Project / Development Constraints

1.6 Performance Criteria

1.7 Applications Affected

SAP Modules Affected

Functional Specification – Conversion – Template v2.1 Page 7 of 28

JDA Modules Affected

Legacy Systems Affected

1.8 Data Volume

1.9 Data Quality Metrics

1.10 Other Objects Affected

Object Impact/Change Description

Functional Specification – Conversion – Template v2.1 Page 8 of 28

Conversion Business Object

Business Object Retention & Archiving Requirements

PIR number Vendor code Material Ref.Number Success / Remarks

Functional Specification – Conversion – Template v2.1 Page 9 of 28

Application Name Source Destination

Source Systems Contact Name

**For Estimation Purposes, define the number of input files**

Number of the Input Files

Less than 50 fields

# of Fields Requiring Special Transformation

Functional Specification – Conversion – Template v2.1 Page 10 of 28

Functional Specification – Conversion – Template v2.1 Page 11 of 28

2.1.1 Pre/Post Processing (including Data Cleansing & Business Rules/Logic)

Post-Processing Business Rules

Data Cleansing Logic/Approach

Data Verification Logic/Approach

Extract data from

Functional Specification – Conversion – Template v2.1 Page 12 of 28

Input default data /

Upload file in SAP

Additional Processing Requirements for this Conversion

Conversion Process Log

Not Needed MLG.

Extension of Standard Table/Structure or New Table (if applicable)

Functional Specification – Conversion – Template v2.1 Page 13 of 28

Proposed Development Tool (done by Tech Arch. Team member/Dev. Architect)

SAP/JDA Transaction(s) Required for Interface

Functional Specification – Conversion – Template v2.1 Page 14 of 28

2.2.1 Selection Criteria/Screen

For Estimation Purposes, define the number of input files