Development Specification

Development ID GDEVWR0007432
IT0313 – Tax New Zealand Data Loading
Brief development description
Program
FITGAP FITGAP0025204

Business Process Level 3 or 4 Hire/Rehire

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

584647687.doc Page 1 of 19
 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 creation Francine 7.02.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 7.2.05
QA Reviewer (TO)

584647687.doc Page 2 of 19
 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

584647687.doc Page 3 of 19
 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)................................................................................13
5.4 IMPORT/EXPORT DATA MAPPING MATRIX (AS + TO)..........................................................13
5.5 BDC CONVERSIONS (AS + TO).......................................................................................15
5.6 DUPLICATION HANDLING (AS)........................................................................................... 15
5.7 ERROR HANDLING (AS).................................................................................................... 15
5.8 TECHNOLOGY TO BE USED (TO).......................................................................................15
5.9 FILE RETENTION REQUIREMENTS (AS)..............................................................................16
5.10 TECHNICAL DETAILS FOR DATA CONVERSION DEVELOPMENT (TO)...................................16
5.11 QUALITY ASSURANCE REMARKS/SIGN-OFF OF SECTION (TO + QA)..................................17

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

584647687.doc Page 4 of 19
 Development Specification

1 Management Summary (FO)

This development specification describes the local data load of Infotype 0313 – Tax New Zealand from
the legacy system into the global SAP HR system for the Oceania Globe Implementation.

New employees to Nestle are required to submit their New Zealand Taxation Details as a legal
requirement to the Internal Revenue Department (IRD), and for Nestle to establish the correct taxation
deduction from salary.

The employee tax data is retrieved from the legacy system into 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 1,000 records. Therefore, a manual loading process is not feasible.

584647687.doc Page 5 of 19
 Development Specification

2 Process Flow / Context (FO)

The Tax New Zealand 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.

IT0313 – Tax NZ
Data Migration to SAP

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

584647687.doc Page 6 of 19
 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, PA0313
via transaction PA30. The data from this table is displayed in the local HR Infotype 0313, Tax New
Zealand. The program needs to be run via the LSMW transaction in SAP.

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. 0313 Tax New Zealand 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 0313 is a Country Specific infotype for New
Zealand. Country specific infotypes are developed to meet legal requirements for data reporting 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

PA0313 PNP SE16 New Zealand (MOLGA
Data Browser Table 43)
PA0313

The following table defines the required infotype program details.

Infotype Description Screen Program Screen Number Country Grouping

0313 Tax New Zealand MP031300 2000 43

584647687.doc Page 7 of 19
 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): Oceania Market (New Zealand)
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 data will be loaded by the DC GC AOA Team.
Must have access to transaction LSMW in the Global HR System

584647687.doc Page 8 of 19
 Development Specification

3.3 SAP General Requirements (AS)

3.3.1 Data Volumes (AS)

Country/Market Frequency Volume per run
New Initial Uploads to SAP for HR Implementation 1,000
Zealand/Oceania

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: NZD

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).

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

584647687.doc Page 9 of 19
 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

584647687.doc Page 10 of 19
 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)

584647687.doc Page 11 of 19
 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 Exists in SAP table PA0001. Must
exist before upload of 0313 data.
BEGDA Start Date Will be changed in flat file during
cutover simulations
ENDDA End Date Will always be Can be changed in Flat File if
31.12.9999 required
TAXCD Tax Code Defaults to M from Determines how the employees tax is
configured values calculated
TAXEE Extra Emolument Rate Allows the employee to pay extra tax.
Numeric.
SURCD Surcharge Code Not used Field only kept for historical purposes
TAXPC Tax Percentage Numeric value For employees on a Flat Tax
agreement
EPINC Add Earner Prem Flag
STLPC Student Loan Numeric
Percentage
IRISS Year Issued Numeric Year e.g. 2004
IRNUM Certificate Number Numeric – first two e.g. SS999999
characters must be
alpha letters

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.

584647687.doc Page 12 of 19
 Development Specification

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: NZ_IT0313_Data

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

Outpu SAP IDOC / Field Format SAP Require SAP SAP Check
t File Table BI / Desc. (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 Cost Defaults PA0001
Center
PERSG PERSG Employee Defaults PA0001
Group
ENAM ENAM Name Defaults PA0002
E E
PERSK PERSK Subarea Defaults PA0001
WERK WERK Personnel Defaults PA0001
S S Area
INFTY INFTY Infotype CHAR- M NNNN PA0313
35
BEGD BEGD Start Date DATS- M YYYYMMD PA0313
A A 8 D
ENDD ENDD End Date DATS- 31.12.999 M YYYYMMD PA0313
A A 8 9 D
TAXC TAXC Tax Code CHAR- M M PA0313
D D 6
TAXEE TAXEE Extra DEC-5 O Numeric PA0313
Emolumen
t Rate
SURCD SURCD Surcharge CHAR- O Not used PA0313
Code 3
TAXPC TAXPC Tax DEC-5 O Numeric value PA0313
Percentage
EPINC EPINC Add CHAR- O Flag PA0313

584647687.doc Page 13 of 19
 Development Specification

Earner 1
Prem
STLPC STLPC Student DEC-5 O Numeric PA0313
Loan
Percentage
IRISS IRISS Year NUMC- O Numeric PA0313
Issued 4

IRNUM IRNUM Certificate CHAR- O Numeric – PA0313

Number 8 first two
characters
must be alpha
letters

584647687.doc Page 14 of 19
 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 0313 record is earlier than the IT0313
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.

584647687.doc Page 15 of 19
 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.

584647687.doc Page 16 of 19
 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

584647687.doc Page 17 of 19
 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 0313 Data from Flat File will be uploaded successfully
Upload Upload data for 0313 using Batch Input Session Data from Flat File will be uploaded successfully
Batch
Validation Validation of data in PA0313 Data should be displayed in PA0313 as per upload file including
amount of records created.
Validation Validation of data in Infotype 0313 Run report to check records and numbers. Display/change records in
IT 0313
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

584647687.doc Page 18 of 19 Created: 25.02.2005

Printed: 13.01.2004 14:39
 Development Specification

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

584647687.doc Page 19 of 19 Created: 25.02.2005

Printed: 13.01.2004 14:39