Development Specification

Development ID GDEVWR0007429

Brief development description LSMW for IT0227 Tax File Number for Australia
Gap ID FITGAP0023676

Business Process Level 3 or 4 Hire/Rehire

Functional Owner (Syst. Anal.) Arlene Stacey
SAP Application Specialist Francine Hill
Technical Owner Ed Brady
Author Francine Hill
Reference Documents
Workstream Globe Template
Process Stream Human Resources
mySAP component /module R3/HR
Type of development Data Conversion Program – LSMW
Template Version 1.5
Global / Market Oceania Market
Status In Progress

AU584647725.doc Page 1 of 18
 Development Specification

Version Control

Revision History:
Section Version Description of change (including the Reference Changed Date
Reference No. reason for the change) Change By
Request
FS 1.0 Document created Francine 31.01.05
Hill
1.1
1.2
1.3
TS 1.0
1.1
1.2
1.3
UTP 1.0
1.1
1.2
1.3

FS – Functional Specification
TS – Technical Specification
UTP – Unit Test Plan

Sign-off

Approved by Name Signature Date

Process Team Lead Russel

Rodrigues
Developer
AD Development Coordinator (2 names: On+Off-Site) Ed Brady
GC AOA Application Specialist Francine Hill 31.01.2005
QA Reviewer (TO)

AU584647725.doc Page 2 of 18
 Development Specification

IMPORTANT: All paragraphs titles have been marked with a 'code', defining which
stakeholder is responsible for completing the paragraph. Please find below explanation
of the codes, as well as their roles in the process flow
FO Functional Owner (Systems Analyst)
AS Application Specialist
TO Technical Owner – AD Development Coordinator (On-site and Off-
Site)
QA QA reviewer (for messaging: both Messaging and AD)
DEV Developer
MWTO Middleware Technical Owner
MWQA Middleware QA Reviewer
MWDEV Middleware Developer
TOM Technical Owner Messaging – Messaging Coordinator
TOD Technical Owner Development – AD Development Coordinator

Complete Initial Co mplete

FS Final QA +
Functional Walkthrough + FS Workshop Technival TS QA
Sign-Off
Sections QA Sections

FO TO FO + TO TO TO QA + MWQA

For Messaging Only:

An assigned TOM and TOD are working very closely for the entire development lifecycle. For sections where TO is
responsible to complete, the responsibility in general will fall with the TOM being responsible for the overall
technical solution. TOD is responsible in documenting any coding logic

AU584647725.doc Page 3 of 18
 Development Specification

Table of contents

1 Management Summary (FO)............................................................................5

2 Process Flow / Context (FO)..........................................................................6
3 Functional Requirements (AS)......................................................................7
3.1 DESCRIPTION OF THE DEVELOPMENT (AS)..........................................................................7
3.2 HOW THE DEVELOPMENT WILL WORK (AS)..........................................................................8
3.3 SAP GENERAL REQUIREMENTS (AS)..................................................................................9
3.4 ASSUMPTIONS/DEPENDENCIES/CONSTRAINTS (AS).............................................................9
3.5 QUALITY ASSURANCE REMARKS/SIGN-OFF OF SECTION (TO)............................................10

4 Overall Development Design (TO)..............................................................11

4.1 COMPLEXITY, ESTIMATES AND DEADLINES........................................................................11
4.2 BRIEF TECHNICAL OVERVIEW........................................................................................... 11

5 Appendix D - 1: Data Conversions.............................................................12

5.1 DATA CONVERSION DETAILED DESCRIPTION (AS).............................................................12
5.2 CONTROL & RECONCILIATION REQUIREMENTS (AS)...........................................................12
5.3 IMPORT/EXPORT TO SAP (AS + TO)................................................................................12
5.4 IMPORT/EXPORT DATA MAPPING MATRIX (AS + TO)..........................................................13
5.5 BDC CONVERSIONS (AS & TO).......................................................................................14
5.6 DUPLICATION HANDLING (AS)........................................................................................... 14
5.7 ERROR HANDLING (AS).................................................................................................... 14
5.8 TECHNOLOGY TO BE USED (TO).......................................................................................14
5.9 FILE RETENTION REQUIREMENTS (AS)..............................................................................15
5.10 TECHNICAL DETAILS FOR DATA CONVERSION DEVELOPMENT (TO)...................................15
5.11 QUALITY ASSURANCE REMARKS/SIGN-OFF OF SECTION (TO + QA)..................................16

6 Appendix N: Testing.....................................................................................17
6.1 FUNCTIONAL TEST CASES (FO)........................................................................................ 17
6.2 Technical Test Cases (TO)............................................................................................ 17

AU584647725.doc Page 4 of 18
 Development Specification

1 Management Summary (FO)

This development specification describes the local data load of Infotype 0227 – Australia Tax file Number
(TFN) from the legacy system into the global SAP HR system for the Oceania Globe Implementation.

New employees to Nestle are required to submit their Australian Tax File Number as a legal requirement
to the Australian Taxation Office (ATO), and for Nestle to establish the correct taxation deduction from
salary.

The employee tax data is retrieved from the legacy system in a flat file. After cleansing and validation is
performed, the data is ready for loading into the SAP HR system.

The data will be collected into a loading sheet designed from this development by the DC / GCAOA team.
The loading sheet will detail the target structure and field names of the infotype.

The data is loaded into SAP using the SAP transaction LSMW (Legacy System Migration Workbench).

The volume of data is approximately 4,500 records. Therefore, a manual loading process is not feasible.

AU584647725.doc Page 5 of 18
 Development Specification

2 Process Flow / Context (FO)

The TFN data will be loaded to the SAP HR system using this conversion program. This development
specification will cover the requirements of the upload program and mapping to relevant tables in SAP.

IT0227 – AU TFN
Data Migration to SAP

SAP

Legac Data
IT0227
Legacy Flat File to
y Data Loading
System MS SAP Program
Excel via LSMW

AU584647725.doc Page 6 of 18
 Development Specification

3 Functional Requirements (AS)

3.1 Description of the development (AS)

3.1.1 Overview of development (AS)

The Data Conversion program needs to upload data from a flat file to an internal HR SAP table, PA0227,
via transaction LSMW.

LSMW will load the data using transaction PA30, Infotype 0227. The data from this table is displayed in
the local HR Infotype 0227, TFN Australia.

Infotype Concepts:
Infotype - A screen containing a logical grouping of fields used to describe information about the
employee. From a technical perspective, the data structure of infotypes mirrors a logical set of data
records. Infotypes can be identified by their four-digit code, e.g. 0227 TFN Australia and is accessed by
transaction PA30.

Infotypes can be common and shared by markets; common but contain screen differences per market
and local infotypes, which are country specific. Infotype 0227 is a Country Specific infotype. Country
specific infotypes are developed to meet legal requirements and require a specific output file structure.

Key Field:
The Personnel Number (PERNR) is a unique key ID for each employee, and links all the records for an
employee. The Personnel Number will be assigned externally by each market and is used to link the
uploaded data to the employees record.

Fields within an Infotype

There are multiple fields in one infotype. Each of these fields have been assigned (in the DOS) either
one of the following field status’ by country grouping:

· M – Mandatory
· O – Optional
· X – Not used (display or hidden)

The program is required to upload data to the following table.

SAP Table Type Description Country Dependency

PA0227 PNP SE16 Australia (MOLGA 13)
Data Browser Table
PA0227

The following table defines the required infotype program details.

Infotype Description Screen Program Screen Number Country Grouping

0227 TFN Australia MP027700 2000 13

AU584647725.doc Page 7 of 18
 Development Specification

3.2 How the development will work (AS)

3.2.1 Where this development will be run (AS)

Geographically
Global Development, will be run in all markets
Local Development, will be run in the following market(s): Australian Market
Environments – Components
MDR
HR
R/3 Core
Financial System (Distributed Architecture only)
Commercial System (Distributed Architecture only)
Manufacturing System (Distributed Architecture only)
SEM (Distributed Architecture only)
Global ATP (Distributed Architecture only)
Restitution System (Distributed Architecture only)
CRM
APO
DP (Distributed Architecture only)
PPDS/SNP (Distributed Architecture only)
R&D
EBP
WPS
Other:

3.2.2 How the development will be run (AS)

Development will be run in the following ways

On-line by end user - From within SAP transaction (s): LSMW using transaction PA30
On-line - Via a development-specific menu path.
In background - Scheduled at regular intervals/time
In background - Triggered by a certain event:
Other:
Comments – Specific Variations

Program must be able to run in a background session.

3.2.3 Security (AS)

How should access to run the development be restricted.
No specific restrictions: Data Loading Task
Restriction on authorization on development-specific transaction code only
Restrictions based on certain criteria.
Other:
Comments:

The DC GC AOA Team will do the data loading.

Must have access to transaction LSMW in the Global HR System

AU584647725.doc Page 8 of 18
 Development Specification

3.3 SAP General Requirements (AS)

3.3.1 Data Volumes (AS)

Country/Market Frequency Volume per run
Australia Initial Uploads to SAP for HR Implementation 4,500

Comments:

3.3.2 Language considerations (AS)

Language considerations
No language considerations
Master Data – Related considerations:
Translation requirements
No translation requirements – Development will be used in English only
Translation required:
Comments
The employee data will be maintained in EN (English)

3.3.3 Currency and Units of Measure (AS)

Units of measure: N/A
Currency: N/A

3.4 Assumptions/Dependencies/Constraints (AS)

1. Configuration completed, Number range is defined.
2. Organizational data (infotypes 0000 and 0001) have been loaded successfully.
3. Flat file(s) with given (SAP) structure as input for loading.

Note: Infotypes are configured using Time Constraints which determines:

 how many records can exist at one time (time constraint 1);
 if periods of time are allowed between records (time constraint 2), or
 if records of the same type can overlap (time constraint 3).

IT0227 is configured with a time contraint of 1. This means that only one record is valid and cannot overlap
with another 0227 record. For particular infotypes (0000 and 0001), it also means that once the first record
is saved, it cannot be deleted – only overwritten or delimitted (split). The first record for IT0227 can be
deleted.

AU584647725.doc Page 9 of 18
 Development Specification

3.5 Quality Assurance Remarks/Sign-Off of Section (TO)

QA Reviewer
QA Date
Subject Yes No N/A Comments

General Information
Development ID is correct
Reference documents provided
Market has been clearly specified
Document contents
'Management Summary' complete and clear
Process Flow / Context complete and clear
Description of development complete and clear
'How the development will work' complete
Data volumes have been provided
Currency and UoM details have been specified
Language requirements have been specified
Security requirements have been specified
All assumptions have been documented
Security Spreadsheet has been completed
All Test Cases have been described in Appendix N

Overall: Functional Section Approved

Comments

AU584647725.doc Page 10 of 18
 Development Specification

4 Overall Development Design (TO)

<Template instructions in red, please delete>
In this section, the on-site technical owner of the development and/or the development coordinator will give a list
the different technical components that need to be delivered.
Typically, this section will be completed after the functional specification workshops by the CD workshop
attendees.
In case of late gaps/specifications, the on-site development coordinator can, before sending the functional
specification to the SDC for technical spec creation, add his very high-level view of what is needed.

4.1 Complexity, Estimates and Deadlines

Complexity Complexity
Estimate Development Estimate by Dev-Coordinator [Mandatory Field]
Expected Delivery Date Expected delivery date of the development [Mandatory Field]

4.2 Brief Technical Overview

<Template instructions in red, please delete>
Give a brief technical overview of different components needed to realize the development + add any special
recommendations/remarks.
(e.g. for an interface: IDOC Based interface
- Create extension for Idoc type XXXX
- Link extension to message type YYY
- Develop a new function module.ZZZZ (short description)

AU584647725.doc Page 11 of 18
 Development Specification

5 Appendix D - 1: Data Conversions

5.1 Data Conversion Detailed Description (AS)

Reference Field Business Rules Comments

(Business Name)
PERNR Personnel Number Key Id displayed in the Exists in SAP table PA0001. Must
Header of the IT. exist before upload of 0227 data.
BEGDA Start Date YYYYMMDD Will be changed in flat file during
cutover simulations
ENDDA End Date Will always be Can be changed in Flat File if
99991231 required
TAXFN Tax File Number This field contains a Field will also accept the following
Check-digit rule for ATO values: 000000000, 111111111,
requirements. 333333333, 444444444 and
987654321.

5.2 Control & Reconciliation requirements (AS)

The program should provide a summary of the data loaded, including total number of records processed,
number of records created, and number of records rejected.

5.3 Import/Export to SAP (AS + TO)

Source/Target System: CA5 HR Production

Source/Target File Path/File Name or Defined by DC GCAOA Team
Database:
Source File Type: MS-Excel
File Delimiter: |
Source File Description: AU_IT0227_Data

AU584647725.doc Page 12 of 18
 Development Specification

5.4 Import/Export data mapping matrix (AS + TO)

Outpu SAP IDOC / Field Desc. Format SAP Require SAP SAP Check
t File Table BI / (Type Default d Conversion Validatio Table for
Field Field Loading and Value (M/O). rules / logic n validatio
name Name program Length) n
field
name
PERNR PERNR Personnel M Range for PA0000
Number Oceania:
02300000 –
02399999
CCNTR CCNTR Personnel Default M Header PA0001
Assignmen s
t
PERSG PERSG Employee Default M Header PA0001
Group s
ENAM ENAM Name Default M Header PA0002
E E s
PERSK PERSK Employee Default M Header PA0001
Sub-group s
WERK WERK Personnel Default M Header PA0001
S S Area s
INFTY INFTY Infotype CHAR- M Program PA0227
35 chooses from
PA30
NNNN
BEGD BEGD Start Date DATS- M YYYYMMD PA0227
A A 8 D
ENDD ENDD End Date DATS- M YYYYMMD PA0227
A A 8 D
TAXFN TAXFN Tax File NUMC O Check digit PA0227
Number -9 rule or any of
the following:
000000000
111111111
333333333
444444444
987654321

AU584647725.doc Page 13 of 18
 Development Specification

5.5 BDC Conversions (AS & TO)

5.6 Duplication handling (AS)

Only one infotype record can exist for a specific time period. If a duplicate record is created with the same
start and end dates (BEGDA and ENDDA), the duplicate record will delete the first record. A warning
message is displayed when the user validates the record (enter/return key). To save the record, the user
must validate the record again which will then cause the first record to be overwritten by the duplicate
record.

If the duplicate record has a BEGDA with a later date than the first record, the first record will be
delimitted with the new date period, creating two records. For example:

First Record: 01.01.2005 to 31.12.9999

Second Record: 20.10.2005 to 31.12.9999

Result: First record becomes 01.01.2005 to 19.10.2005 (the day before the second record commences)

If the duplicate record has a BEGDA with an earlier date than the first record, it will first validate againist
the Org Assignment BEGDA (IT0001) and provide a warning if the 0227 record is earlier than the IT0001
record. It will then overwrite the the first record if validated. Both scenarios will issue a warning message
which requires validation.

5.7 Error Handling (AS)

Error and Process Log: Use SAP standard error report.

Reconciliation Report: Use SAP standard reconciliation report

Severe Error Conditions: Need to be mindful of warning messages given when a validation is occurring
between field values, or any other validation messages. Program should replicate validation
requirements.

Post Execution notification details: Use SAP standard. Specify all records that error.

Restart/Recovery: The program will not be able to be re-run because external number assignment is used
for the PERNR. Correct errors by restarting BDC.

5.8 Technology to be used (TO)

<Template instructions in red, please delete>
This section should be filled by the Custom Development team member who is completing this specification. The
method of uploading (e.g. LSMW, BDC, Direct Input, Direct Update, etc.) should be described here. Provide
additional information like the name of the structure to be used (in case of LSMW), Program name for direct input,
etc.

AU584647725.doc Page 14 of 18
 Development Specification

5.9 File Retention Requirements (AS)

The data file will be archived for auditing purposes once validation of the upload to the Global SAP HR
system is completed.

5.10 Technical Details for Data Conversion Development (TO)

5.10.1 Data Processing (TO)

A. Preparation steps
e.g. When using Idocs, describe which port, partner type, partner function, etc need to be set up.
e.g. When a new upload program has been developed, then this program needs to be built in LSMW.
Describe in this section, the entries required in the SAP tables SXDA0, SXDA1, SXDA2 and SXDA3.

B. Loading Steps within LSMW

STEP1: Initial Screen
Give the project name/description, subproject/description and object name/description of the LSMW object.

STEP 2: Maintain Object Attributes

Give an overview of the object type and import technique set up in order to upload the data.

STEP 3: Maintain Source Structures

Give an overview of the source structures defined within LSMW.

STEP 4: Maintain Source Fields

Give an overview of the source fields.

STEP 5: Maintain Structure Relations

SAP structures Source structure

/

STEP 6: Maintain field mappings and conversion rules

Describe the conversion rules required.

STEP 7: Specify Files

Give a list of the files needed, together with their properties for: File contents, delimiter, file structure, file type and
code page.

STEP 8: Assign Files

Assign the respective files defined in Step 7 to the source structures

Input files Source structure

Step 9 Read Data

Step 10 Display read data
Step 11 Convert Data
Step 12 Display converted data
etc.

C. Pseudocode for new developments

In case there is no standard upload program available to upload the data, describe in this section the
pseudocode of the upload program that has been developed.

AU584647725.doc Page 15 of 18
 Development Specification

5.11 Quality Assurance Remarks/Sign-Off of Section (TO + QA)

QA Reviewer
QA Date
Subject Yes No N/A Comments

Functional Section

Technical Details

Comments

AU584647725.doc Page 16 of 18
 Development Specification

6 Appendix N: Testing

6.1 Functional Test Cases (FO)

Test Case Test Case Description Expected Result CD Comments

Upload Upload data for 0227 Data from Flat File will be uploaded successfully
Upload Upload data for 0227 using Batch Input Session Data from Flat File will be uploaded successfully
Batch
Validation Validation of data in PA0227 Data should be displayed in PA0227 as per upload file including
amount of records created.
Validation Validation of data in Infotype 0227 Run report to check records and numbers. Display/change records in
IT 0227.
Error Set up an error in Flat File Upload program should record error.
Error Batch Fix error by running Batch Session Successful creation of record.
Error Program can only be run after IT0001 is loaded. Error if attempt to run before IT0001 upload.
IT0001

6.2 Technical Test Cases (TO)

<Template instructions in red, please delete>
In this section, the technical owner will attach any extra information on how to test the cases described above, as well as any additional technical testing that he thinks needs
to be done, such as ALE-Config/Error handling testing.

In this section, the actual execution of the testing should be documented as well.

Test Case Description Steps Test Data Expected Result Actual Result/Remarks Executed By/Date

584647725.doc Page 17 of 18 Created: 31.01.05

GCC Application Development
 Development Specification

Test Case Description Steps Test Data Expected Result Actual Result/Remarks Executed By/Date

584647725.doc Page 18 of 18 Created: 31.01.05

GCC Application Development