IMPLEMENTATION PAPER_FUNCTIONAL

AND DEVELOPMENT
(IP_FD)

IP DATA MIGRATION ASSETS

IP-NUMBER:<NUMBER>

Document reference
Document type (e.g. GAP IP Functional X)
Owner (company)
Last edited by
Last edited on

<IP Number>_IP_FD_<IP Name>

GAP IP Functional Development
AMOS SE
GRP@AGA
<yyyy-mm-dd>

Development Functional and Technical Specification

Table of Content
1 General Information.......................................................................................................................................6
1.1 Document Change History.......................................................................................................................6
1.2 Purpose of this document.........................................................................................................................6
1.3 Business Needs and Requirements.........................................................................................................7
1.4 Open Issues.............................................................................................................................................8
2 Functional Description...................................................................................................................................9
2.1 Solution Overview....................................................................................................................................9
2.2

Legacy Asset Data Transfer..................................................................................................................10

2.2.1 Set Company Code Status....................................................................................................................10

2.2.2 Specify Sequence of depreciation areas...............................................................................................10
2.2.3 Specify Transfer Date / Last Closed Fiscal Year...................................................................................11
2.2.4 Specify Last Period Posted in Previous System (Transf. During FY)....................................................11
2.2.5 Transfer Foreign Currency Values........................................................................................................11
2.2.6 Recalculate Depreciation for Previous Years........................................................................................12
2.2.7 Set Reconciliation Accounts (Manually)................................................................................................12
2.3 Impacted business process ...................................................................................................................13
2.4 Impacted sub-process............................................................................................................................13
2.5 Data Requirements................................................................................................................................13
3. Technical Description Development Types.............................................................................................14
3.1 SAP Enhancement.................................................................................................................................15
3.1.1 Table Access Diagram..........................................................................................................................15
3.1.2 Custom Tables / Structure in SAP.........................................................................................................15
3.1.3 Data Validation......................................................................................................................................16
3.1.4 Data Flow Diagram................................................................................................................................16
3.1.5 Pseudo Code.........................................................................................................................................17
3.1.6 Technical details....................................................................................................................................17
3.2 SAP Conversion.....................................................................................................................................22
3.2.1 Data Cleaning Requirements................................................................................................................22
3.2.2 Extract Logic .........................................................................................................................................22
3.2.3 Currency and Units of Measure ............................................................................................................22
3.2.4 Language of Texts ................................................................................................................................22
IP_FD <IP Number> <IP Name>

page 2 of 80

Development Functional and Technical Specification

3.2.5 File Layout (In Sequence).....................................................................................................................23
3.2.6 Selection Screen Details (if applicable) ................................................................................................23
3.2.7 Starting Condition (Optional) ................................................................................................................23
3.2.8 Business Rules (Optional) ....................................................................................................................23
3.2.9 Table Access Diagram..........................................................................................................................23
3.2.10 Selection Criteria.................................................................................................................................24
3.2.11 Data Conversion & Interface Definition...............................................................................................24
3.2.12 Data Mapping Matrix...........................................................................................................................25
3.2.13 BDC Method........................................................................................................................................25
3.2.14 LSMW ................................................................................................................................................26
3.2.15 ALE Configuration (optional)...............................................................................................................28
3.2.16 Custom Dictionary Objects (optional)..................................................................................................30
3.2.17 File Layout...........................................................................................................................................30
3.2.18 Performance Considerations (optional)...............................................................................................30
3.2.19 Dependency........................................................................................................................................30
3.2.20 Relevant Function Modules.................................................................................................................30
3.2.21 Pseudo Code.......................................................................................................................................30
3.3 SAP Forms.............................................................................................................................................32
3.3.1 SAP Script/Forms..................................................................................................................................32
3.3.2 Execution Mode Details.........................................................................................................................32
3.3.3 Technical Details...................................................................................................................................33
3.3.4 Table Access Diagram..........................................................................................................................36
3.3.5 Custom Tables / Structure in SAP.........................................................................................................37
3.4 SAP Interface.........................................................................................................................................38
3.4.1 Interface Classification..........................................................................................................................38
3.4.2 Interface Functionalities........................................................................................................................39
3.4.3 Interface Data Requirements.................................................................................................................39
3.4.4 Table Access Diagram..........................................................................................................................42
3.4.5 Selection Criteria...................................................................................................................................42
3.4.6 SAP Requirements................................................................................................................................43
3.4.7 Middleware Solution..............................................................................................................................44
3.4.8 Legacy System Requirements...............................................................................................................44
3.4.9 Data Conversion & Interface Definition.................................................................................................46
IP_FD <IP Number> <IP Name>

page 3 of 80

Development Functional and Technical Specification

3.4.10 Data Mapping Matrix...........................................................................................................................47
3.4.11 File Layout...........................................................................................................................................48
3.4.12 Dependency........................................................................................................................................48
3.4.13 Relevant Function Modules.................................................................................................................48
3.4.14 Pseudo Code.......................................................................................................................................48
3.4.15 ALE Configuration (optional)...............................................................................................................49
3.4.16 Custom Data Dictionary Objects (Optional).........................................................................................50
3.4.17 Performance Consideration (Optional)................................................................................................51
3.4.18 Interface Controls................................................................................................................................51
3.4.19 Compliance.........................................................................................................................................53
3.4.20 Miscellaneous Data Capture (Optional)...............................................................................................54
3.5 SAP ECC Report....................................................................................................................................56
3.5.1 Technical Solution.................................................................................................................................56
3.5.2 Selection Screen...................................................................................................................................56
3.5.3 Starting Condition..................................................................................................................................58
3.5.4 Data Mapping Tables............................................................................................................................59
3.5.5 Detail Logic Diagrams...........................................................................................................................60
3.5.6 Interactive Report Flow.........................................................................................................................68
3.5.7 Sort Criteria Details...............................................................................................................................68
3.5.8 Calculations and Page Break related information..................................................................................68
3.5.9 Custom Tables / Structure in SAP.........................................................................................................69
3.5.10 Recovery and Restart..........................................................................................................................69
3.5.11 Language of texts................................................................................................................................70
3.5.12 Currency and Units of Measure...........................................................................................................70
3.6 SAP BW Report .....................................................................................................................................71
3.6.1 Report Description: ...............................................................................................................................71
3.6.2 Report Layout........................................................................................................................................71
3.6.3 Report Selections and Navigation.........................................................................................................71
3.7 SAP Workflow........................................................................................................................................73
3.7.1 SAP Workflow Diagram.........................................................................................................................73
3.7.2 Technical description.............................................................................................................................74
3.7.3 Business Object Information..................................................................................................................75
3.7.4 Workflow Definition................................................................................................................................76
IP_FD <IP Number> <IP Name>

page 4 of 80

Development Functional and Technical Specification

3.7.5 Deadline Monitoring Requirements.......................................................................................................77
3.7.6 Reporting / Form Requirements............................................................................................................77
3.7.7 Custom screen design...........................................................................................................................77
3.7.8 Custom Tables / Structure in SAP.........................................................................................................77
3.7.9 User Exit / Enhancement Detailed Description......................................................................................78
3.7.10 Configuration Information....................................................................................................................78
3.8 SAS Developments................................................................................................................................78
4. Security and Authorization Requirements..................................................................................................79
5. Attachments...............................................................................................................................................80

IP_FD <IP Number> <IP Name>

page 5 of 80

Development Functional and Technical Specification

1 General Information
This document has been created within the framework of the GRP@AGA project. According to the
Global Reporting Program (GRP) running since 2002, several GRP rollout projects have been
performed by different operational units (OE) in the past in order to enhance the reporting speed,
quality and efficiency. Currently the to-be solution is represented by the GRP kernel solution in
order to meet those targets.
The core aim of the GRP@AGA project is to deliver homogeneous system platform (SAP ERP) for
all insurance and non-insurance related finance departments at OEs belonging to AGA
INTERNATIONAL S.A. (AGA Group). This will align AGA Group with the rest of the Allianz
business globally through the implementation of a global template (GRP kernel solution).
Realisation of the project will be conducted in several steps. The GoLive of the pilot project
rollout on Mondial Assistance France (MAF) is planned for the 2012-01-01. It will be followed by
rollins on the different OEs, which will have to adhere in general to already accepted GRP solution
for MAF based on the GRP kernel solution.
In order to meet the business requirements of asset accounting there is a need to migrate the
asset master data records from the feeder systems (e.g. SERVANTISSIMO Document Change
History) to SAP CAP.

1.1

Document Change History

Date

Changed by

Chapters changed

Reason for update

08.07.2011

Yagna Reddy

All

Creation of file

18.07.2011

Michel
Schneider

1 and 2

Feedback of internal review

1.2

Purpose of this document

This document describes from a business perspective the purpose of the required migration. It
should also provide the developer with a logical overview of what data has to be migrated using
BDC/LSMW. Moreover, the document is used to provide him with all relevant details on functional
requirements (function and features), information on GAPs, and the technical description for a
development in SAP or SAS needed.
The migration focus is on asset master data. There are two different ways of migrating data from
feeder systems.
This document will discuss loading fixed assets using two methods.
IP_FD <IP Number> <IP Name>

page 6 of 80

Development Functional and Technical Specification

1. BDC recording
This is suitable for a very basic upload. If for example you are not creating fixed assets in
SAP, but rather updating one field in fixed assets which already exist in the system then
this might be the right approach. But it is not flexible enough to be used for the creation of
fixed asset data.
2. For a one-time conversion into SAP, we use LSMW tool. It allows you to leverage the full
power of ABAP while using standard SAP processing functions, yet it does a lot of the file
management and processing work automatically.
A new LSMW for AGA on client 780 will have to be written for the data migration.
Difference between LSMW and BDC are
1. LSMW is used for SAP standard applications whereas BDC is for customized
applications.
2. Standard Mapping is done in LSMW and data validation is done implicitly by SAP
whereas in BDC we have to do it explicitly.
3. For any data complexity, LSMW doesn't supports whereas in BDC, we can do it
manually.
4. LSMW internally might well in using IDOCs, Batch Input, Direct input, Recording.

1.3

Business Needs and Requirements

A fixed asset is an object, a right, or another item owned by an enterprise that is intended for longterm use and can be individually identified in the balance sheet. Maintaining fixed assets involves
creating, changing, and displaying asset master records. Please refer to IP
320336_IP_FC_WS1_Customizing_ FIAA_Fully_New for further information on the customizing of
FI-AA for AGA.
The different items of information are structured according to area of use and functions in the
system to make it easier for users to create, maintain, and evaluate master data. Each asset
master record consists of two parts that are described below.
1. General Master Data / Organizational Assignments
This part of the master record contains general information about the fixed asset.
2. Valuation Parameters
In the valuation section of an asset master record is defined, how a fixed asset is valuated for each
depreciation area.
Example: In the valuation section for a machine, it was specified to be written off in depreciation
area 20 (cost-accounting depreciation) within a period of three years. The machine is to be written
off using straight-line depreciation.

IP_FD <IP Number> <IP Name>

page 7 of 80

Development Functional and Technical Specification

1.4

Open Issues

1. Asset Master data of Allianz Global Assistance has to be provided.

2. Identifying the tool (whether LSMW or BDS) to migrate the legacy data

IP_FD <IP Number> <IP Name>

page 8 of 80

Development Functional and Technical Specification

2 Functional Description

2.1 Solution Overview

The functionality of the migration is aimed at the synchronisation of the feeder systems (e.g.
SERVANTISSIMO) with the respective master data on SAP FI module using data migration. So it
will be uploaded into SAP through flat file.
Data migration is slightly different from a normal transaction which happens in Asset accounting
module. Normally, in asset accounting the day to day transactions is posted with
values through FI bookings and at the same time the asset reconciliation is updated online
realtime. Whereas in data migration the asset master is updated with values through a transaction
code called as AS91. The reconciliation GL account is not automatically updated at this point of
time.
The reconciliation accounts are updated manually through another transaction code called OASV.
Creating a Legacy Asset needs following information to be uploaded:
1)

Asset Class: Each asset master record must be assigned to one asset class. Asset
Class can be determined based on legal or management requirements. Normally,
depreciation area and other master data are associated with the Asset Class.

2)

Company Code: One Fixed Asset is assigned to one company code.

3)

Description: Description of the Fixed Asset

4)

Manage Historically: If it is legacy Asset and using transaction AS91, then this
check box has to be checked.

5)

Capitalization Date: The capitalization date is the value date of an asset. You can
also enter this date manually when creating an asset. However, this does not lead
to the asset being capitalized, but only to this date being the default for the asset
value date when the first acquisition is posted.

6)

Cost Center: The SAP system uses the cost center assignment in the asset master
record to determine the cost center affected when fixed asset depreciation or
Gain/loss from asset sales type of postings are done.

7)

Old Fixed Asset Number: You can enter Legacy Asset number in this field to keep
a track of the old numbers.

8)

Depreciation area: An area showing the valuation of a fixed asset for a particular
purpose (for example, for individual financial statements, balance sheets for tax
purposes, or management accounting values).

IP_FD <IP Number> <IP Name>

page 9 of 80

Development Functional and Technical Specification

9)

Depreciation Key: The depreciation key (valuation key) controls the valuation of the
asset in the particular depreciation areas.

10) Take Over values: These are filled depending on the Customization and
Depreciation areas.

2.2 Legacy Asset Data Transfer

2.2.1 Set Company Code Status

Test status - We can change values by transferring asset data from a previous
system, or by posting.
Transfer status - We can enter and change values by transferring asset data
From a previous system, but posting is not possible.
Production status - The asset data transfer is complete. You can only change
values by posting. Before the system goes live, it is essential that you set the
system status to "production" (not test).
Categories of Status
0 Asset data transfer completed
1 Asset data transfer not yet completed
2 Test company code with data transfer always allowed
3 Company code deactivated - reporting allowed
Company code status is set to Test i.e 2 till asset master data is transferred using
Transaction Code AS91and balances are updated in transaction code OASV.
After completion of migration company code status must be changed to 0 to avoid
inconsistencies in depreciation calculations.
Which status will we use when?

2.2.2 Specify Sequence of depreciation areas

In this field we define the order in which you want to update depreciation areas with values
during legacy data transfer. You determine this sequence by entering a relative number in
this field.
During the transfer of legacy data, the first depreciation area to be transferred is generally
the book depreciation area.
In this step, the sequence of the depreciation areas for the data takeover transaction is
specified. If there are additional depreciation areas for local /fiscal purposes, the sequence
for the depreciation areas may be impacted.
IP_FD <IP Number> <IP Name>

page 10 of 80

Development Functional and Technical Specification

2.2.3 Specify Transfer Date / Last Closed Fiscal Year
Here we specify the transfer date for the Allianz Global Assistance asset data transfer. This
date determines the status of posting to be used for the transfer. Posting up to this date will
be included in the transfer. This specification also determines whether we want to perform
the transfer during the fiscal year (with transfer of posted transactions/depreciation in the
current fiscal year) or at the end of the fiscal year (without transactions).
If the transfer date is not the last day of the fiscal year (according to the fiscal year variant
in FI), the system interprets this as transfer during the fiscal year. The system cannot
transfer any historical transactions. It can only transfer cumulative values from the end of
the last fiscal year, and the transactions in the current fiscal year (the second is only
possible for transfer during the fiscal year).
Example: Transfer date is last day of the fiscal year

Transfer date December 31, 2011

Last closed fiscal year 2011
Specify the take over date as 31.12. 2011. The company is going live with SAP on
01.01.2012
To make it simple, the legacy data will be transferred on 31.12.2011. -> Does that
mean it will be technically migrated into SAP CAP only on the 31st December?
System will start calculating depreciation from 01.01.2012

2.2.4 Specify Last Period Posted in Previous System (Transf. During FY)
This step is only necessary if you want to perform an old assets data takeover during the
fiscal year. In this case, you must specify the period up to which depreciation was posted in
the previous system. This period refers to the posted depreciation that is to be transferred
during old assets data takeover.
Allianz Global Assistance is going live on 1st January, 2012. In this case we specify that
depreciation was posted up to 31st December 2011 in the previous (legacy) system.

2.2.5 Transfer Foreign Currency Values

This is important to that carry out this step if you manage depreciation areas in foreign
Currencies.
In this step, determine that foreign currency areas can receive values during old assets
data takeover. Then the depreciation areas are not supplied with values from another area
by the system, although they are defined as dependent areas by the Customizing settings.
This specification can only be made for areas that are managed in foreign currency.
Using this indicator, you specify that you will provide values for the foreign currency area
during the legacy data transfer. The system then does not provide values itself for the area
(by taking over values from another area, with no changes allowed) as it normally would.
We can only make an entry in this field for an area which is managed in foreign currency.

IP_FD <IP Number> <IP Name>

page 11 of 80

Development Functional and Technical Specification

For any Depreciation area with foreign currency values fixed at the Group Rate as at the
takeover date, the takeover values for this depreciation area is calculated
manually/automation tool.
Please note that if any change to depreciation area sequence is undertaken, that the
manually input flag will change position and will require updating.
Do we need to transfer assets in foreign currencies?

2.2.6 Recalculate Depreciation for Previous Years

If you need system to recalculate depreciation for the previous year up to the date of the
transfer there is an option available to calculate depreciation.
Normally this step is not done, since the depreciation calculation by SAP might differ due to
some rounding difference, timing difference as compared to the legacy system.

Is that really clear already? Up to now I thought we would load the assets data into SAP
CAP at their original value and then depreciate them in SAP using the depreciation run.
What are the consequences of using one or the other way?

2.2.7 Set Reconciliation Accounts (Manually)

This step is required for conversion purposes. Carried out directly in client during cutover.
By default the relevant GL accounts will have been created as reconciliation accounts. As
part of the conversion, the flag is removed from the GL accounts per asset class per
company code. After the balances have been loaded, the reconciliation flag is reset. OAMK
allows this to be carried out manually. Once they are set as reconciliation accounts, the
system will only post to them via Asset Accounting from this point onwards. This is
maintainable in each client except production where this step is managed by the cutover
strategy.

IP_FD <IP Number> <IP Name>

page 12 of 80

Development Functional and Technical Specification

2.3 Impacted business process
TEXT TO BE REMOVED. GUIDANCE ONLY:
< Please provide the high level description of the impacted business process
> END OF GUIDANCE TEXT
Text

2.4 Impacted sub-process

TEXT TO BE REMOVED. GUIDANCE ONLY:
< Provide the high level description of the impacted sub - business process at transaction level.
> END OF GUIDANCE TEXT

Impacted Sub-process 1
Text

Impacted Sub-process 2

Text

2.5 Data Requirements

Require flat file for migrating the data from legacy system to SAP.

FF_AA.xlsx

The format of this file needs to be described.

IP_FD <IP Number> <IP Name>

page 13 of 80

Development Functional and Technical Specification

3.Technical Description Development Types

TEXT TO BE REMOVED. GUIDANCE ONLY
< This chapter is used to describe all relevant technical details for SAS or SAP developments
implemented.
Fill in all sub chapters of the relevant development type, besides the chapters marked as optional.
In some chapters are provided examples and guidance on what content is expected.
> END OF GUIDANCE TEXT
In the following chapters are described the following (mark the line in the middle with an x) the
text in the 3rd column is a link to the chapter within the document
SAP Enhancement
SAP Conversion
SAP Forms
SAP Interface
SAP ECC Reports
SAP BW Reports
SAP Workflow
SAS Developments

IP_FD <IP Number> <IP Name>

3 SAP Enhancement
3.2 SAP Conversion
3.3 SAP Forms
3.4 SAP Interface
3.5 3.5SAP ECC Report
3.6 SAP BW Report
3.7 SAP Workflow
3.7.10 SAS
Developments

page 14 of 80

Development Functional and Technical Specification

3.1 SAP Enhancement

3.1.1 Table Access Diagram

T ab le 1 Nam e - De s cr ip tio n
KEY 1

KEY 2

KEY 3

KEY 4

KEY 5

KEY 6

KEY 7

FIELD 1 FIELD 2

FIELD 3

FIELD 4 FIELD 5

FIELD 6 FIELD 7

FIELD 8

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/LenTy pe/LenTy pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/Len

T ab le 2 Nam e - De s cr ip tio n

T ab le 3 Nam e - De s cr ip tio n

T ab le 4 Nam e - De s cr ip tio n

T ab le 5 Nam e - De s cr ip tio n

KEY 1

KEY 2

FIELD 1

KEY 1

KEY 2

FIELD 1

KEY 1

KEY 2

FIELD 1

KEY 1

KEY 2

FIELD 1

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Ty pe/Len Ty pe/Len Ty pe/Len

Ty pe/LenTy pe/Len Ty pe/Len

s y -f ield

s y -f ield

Ty pe/Len Ty pe/Len Ty pe/Len

s y -f ield

Ty pe/LenTy pe/Len Ty pe/Len

s y -f ield

3.1.2 Custom Tables / Structure in SAP

TEXT TO BE REMOVED. GUIDANCE ONLY:
< This section should detail the attributes of any custom table used, and the properties of its fields.
NB: Existing SAP Data Elements and/or Domains should be used whenever possible when
creating custom table fields, in order to avoid unnecessary typos. In this instance, the data table
row for that field should not be completed beyond Domain, as the remaining attributes will be
default values for the selected Domain.
>END OF GUIDANCE TEXT
Table Name
Short text
Size category

IP_FD <IP Number> <IP Name>

page 15 of 80

Development Functional and Technical Specification

Table maintenance
allowed
Data class
Buffering
Table maintenance
generation
Authorization Group
Field
Name

Data
Element

Domain Type

Length Check
TableField

Key
Field

Foreign Description
Key

Comments

3.1.3 Data Validation

TEXT TO BE REMOVED. GUIDANCE ONLY

< Provide the data validation rules

> END OF GUIDANCE TEXT
Table Field Name

Validation Rule

3.1.4 Data Flow Diagram

IP_FD <IP Number> <IP Name>

page 16 of 80

Development Functional and Technical Specification

3.1.5 Pseudo Code

TEXT TO BE REMOVED GUIDANCE ONLY <

Pseudo-code should describe the main steps that will be performed in a program with easy to
follow logic and select statements.

Logic should be detailed enough so that any developer can be able to code the object without
significant effort on logic redesign.

Data declarations should not be included in pseudo-code, unless the data declaration will
impact the logic.

Format the pseudo-code into logical processing units.

Begin each section of pseudo-code with a heading that clearly describes the logic to follow.
(i.e. Validate user input, gather the inventories)

Each main step needs to start with description of the process, in functional language.

All major checking should be specified, such as whether the internal table is empty, or if SYSUBRC is equal to zero.
> END OF GUIDANCE TEXT

3.1.6 Technical details

TEXT TO BE REMOVED GUIDANCE ONLY <

IP_FD <IP Number> <IP Name>

page 17 of 80

Development Functional and Technical Specification

All chapters are optional, only those ones which are needed needs to be filled in. For all chapters
below also separate Excel sheets can be attached per chapter
> END OF GUIDANCE TEXT

3.1.6.1 SAP User-Exits

Enhancement

Main Program

Includes

Form Routines

3.1.6.2 Function Exits

Project

Enhancement

Component

Main Program
Logical trigger
Point

Function
Module Name

Includes

3.1.6.3 Field Exits

Enhancement

Main
Program
Name

Function
Module
Name

Field Exit Id

Screen
Number

Screen
Field
Name

Conditions for
execution

3.1.6.4 Menu Exits

Enhancement

Menu/Path

Function/Transaction Code

3.1.6.5 Screen Exits

Enhancement

Main Program Name

Screen
Number

Program Name & Sub-Screen Number

3.1.6.6 Search Help Exits

Field
Name

Field Description

IP_FD <IP Number> <IP Name>

Import /
Export

Key
Field

Data
Element

Type
(CHAR,

Length

Default
Value

page 18 of 80

Development Functional and Technical Specification

(I/E)

(Y/N)

NUMC)

3.1.6.7 Search Help Assignment

Standard Search Help

Collective Search Help

Elementary Search Help

3.1.6.8 BADI
BADI Definition

Implementation name

Methods

Comments

3.1.6.9 Custom Transaction

TEXT TO BE REMOVED. GUIDANCE ONLY

< Functional details of custom transaction can be incorporated here: Number of screens required
and flow diagram can be included and provide the selection screen screen shot along with the
table name and field name and screen shot for the required output.
> END OF GUIDANCE TEXT
3.1.6.10

Requirement routine

Menu/Submenu
Routine number
Business logic required

3.1.6.11

Business Transaction event

TEXT TO BE REMOVED. GUIDANCE ONLY

< Provide the details of the Business transaction Event if some specific config required that can be
mentioned here
> END OF GUIDANCE TEXT
3.1.6.12

Substitution

TEXT TO BE REMOVED. GUIDANCE ONLY

<For FI related transaction specifically
> END OF GUIDANCE TEXT
IP_FD <IP Number> <IP Name>

page 19 of 80

Development Functional and Technical Specification

Validation
Description

Fields required for

validation

Point of
Validation

Substituted
Field

Derived from Field

Table used in Substitution

3.1.6.13

Table used
in validation

Business Rules

Business Rules

Screen Details

Screen Number:
Screen Layout: (type or attach details of screen layout)

Screen Field Mapping:

Fie
ld
#*

Field
Descrip
tion

Fiel
d
Typ
e

SAP
Refere
nce
Field

Scr
een
Fiel
d
Len
gth

Inp
ut/
Out
put
Fiel
d

Mand
atory/
Optio
nal

Defau
lt
value
s

Get Value
(G)
Set Value
(S)
Or Both
(B))

Match
codes
used
(if any)

Other field
formatting
requirement
s **

* Number the fields sequentially for referencing.

** Other formatting requirements left or right justification, padding requirements, invisible / visible, bright,
etc.

Necessary field validations and sorting logic, (if any)

Processing Functionality

IP_FD <IP Number> <IP Name>

page 20 of 80

Development Functional and Technical Specification

Pre-screen display processing:

Screen Processing Pseudo code:

Screen Flow Diagram

IP_FD <IP Number> <IP Name>

page 21 of 80

Development Functional and Technical Specification

3.2 SAP Conversion

3.2.1 Data Cleaning Requirements

TEXT TO BE REMOVED. GUIDANCE ONLY
< Specify how data cleansing will be handled. Identify the key contacts responsible for this
process.
> END OF GUIDANCE TEXT

3.2.2 Extract Logic

TEXT TO BE REMOVED. GUIDANCE ONLY
< Describe the extract logic: filtering (e.g. active vendors only, last two fiscal years), summarizing
(e.g. monthly balances, size of the documents)
> END OF GUIDANCE TEXT

3.2.3 Currency and Units of Measure

TEXT TO BE REMOVED. GUIDANCE ONLY
< Are all the units of measure and currency details in the data mapping tables correct? Will the
report work for different currencies? What about the EURO? What happens to the report if the
common measure of weight used on clients sites is changed to tones instead of kilograms? Or to
stones and pounds?
> END OF GUIDANCE TEXT

3.2.4 Language of Texts

TEXT TO BE REMOVED. GUIDANCE ONLY:
< The texts of the report may be different in different countries. What language should be used to
derive these texts? The login language or another?
> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 22 of 80

Development Functional and Technical Specification

3.2.5 File Layout (In Sequence)

3.2.6 Selection Screen Details (if applicable)

TEXT TO BE REMOVED. GUIDANCE ONLY:
< Detail exactly what is needed at the selection screen by using this table. The programmer will be
able to construct the screen directly from the details in this table. Some SAP technical knowledge
will be needed for the complete production of this table.
> END OF GUIDANCE TEXT
Name

Table-Field /
Check Box /
Radio Button
with group

Parameter
(P) / Selectoption (S)

Comments (Range,
Single/Multiple
selection, Patterns,
Mandatory etc.)

Default Value

Desired screen design (selection possibilities):

(use attachment if possible):

3.2.7 Starting Condition (Optional)

TEXT TO BE REMOVED. GUIDANCE ONLY:
< When should the conversion be run? Does another conversion need to be run before this one is
triggered? Should it be a batch only program (with added security) or is it needed on-line as well?
Will the program automatically start a batch session or should someone be in place to trigger
these?
> END OF GUIDANCE TEXT

3.2.8 Business Rules (Optional)

TEXT TO BE REMOVED. GUIDANCE ONLY
< Provide any business rules that are applicable for the transformation. You can also add a
separate spreadsheet
> END OF GUIDANCE TEXT

3.2.9 Table Access Diagram

TEXT TO BE REMOVED. GUIDANCE ONLY
<Table Access Diagram with primary key relationships between tables. Not necessary if calling
transaction(s) to update SAP tables
IP_FD <IP Number> <IP Name>

page 23 of 80

Development Functional and Technical Specification

(Table access diagram to be attached)

Insert Image Here - To insert TAD (or other OLE object):
1. Open your previously created Excel TAD spreadsheet from disk and select the area covered
by the TAD.
2. Press Ctrl-C to copy TAD to clipboard.
3. Without closing Excel, switch back to this word document and position cursor where you'd like
to insert the TAD.
4. From the menu, select TDS Insert TAD (do not use standard paste)
5. Resize the diagram.
6. Delete these instructions, example, and extra lines in this section to avoid printing an extra
page.
7. You're done!
Note: If you create your TAD in an embedded excel spreadsheet and then copy and paste from
the embedded object and not from an excel spreadsheet on disk, Word may insert the
spreadsheet as a protected object. You will not be able to edit or delete it. You should create your
TAD excel files on disk and not as embedded icon files.
To insert graphics within the document (non-OLE objects):
1. Copy the bitmap image to the clipboard
2. From the menu, select TDS Insert Graphic (do not use standard paste)
3. Resize the image.
4. Delete these instructions and extra lines in the section.
5. You're done!
> END OF GUIDANCE TEXT

3.2.10 Selection Criteria

Name

Table Field/
Check box/
Radio button

Select-option (S)
or Parameter (P)

Comments (Range,
Single/Multiple
Selection, Patterns,
Mandatory, etc.)

Default Value

S or P

Variants:
Attach selection screen shot here

3.2.11 Data Conversion & Interface Definition

TEXT TO BE REMOVED GUIDANCE ONLY

IP_FD <IP Number> <IP Name>

page 24 of 80

Development Functional and Technical Specification

< For inbound interfaces, indicate any relevant transaction codes and a description of the dynamic
transaction call (i.e. for materials, if the material exists, MM02 is called, whereas for materials not
already established in SAP, MM01 is called).
> END OF GUIDANCE TEXT

File
Name

Inbound /
Outbound
I/O

File Type
(ASCII,
EBCDIC, Excel
file, etc.)

Location

Source System:

Target System:

Description

Logical
File
Name

File
Delimiter

Comments

System Diagram:

3.2.12 Data Mapping Matrix

3.2.13 BDC Method

Batch Data Communication or BDC is a batch interfacing technique that SAP developed. It is a
common data transportation method and is especially useful in large data communication
scenario. There are two methods to run BDC program. One is using statement Call Transaction
directly. In this method, the screen is simulated directly but difficult for error processing. The other
method is to create a BDC session. Actual data transportation is executed when running this BDC
session.
The migration consists of seven steps in BDC
1. Creation of flat file
2. Mapping fields of the flat file to SAP asset master record fields
3. Call the transaction of Asset master AS91
4. Trap all the errors in the program
5. Rectify the errors if found and same process will follow.

IP_FD <IP Number> <IP Name>

page 25 of 80

Development Functional and Technical Specification

3.2.13.1

For BDC/Call Transaction

DMM for BDC Call

Transaction.xls

This file is not filled.

3.2.14 LSMW
The migration of data using LSMW consists of following steps
SAP provides Standard LSMW to upload legacy Fixed Assets as a whole or its parts (Sub Numbers). This program copies the Asset master data and asset transaction in FI Asset
Accounting systems.
The steps

1)

Maintain Object attributes

Object - 0160
Method - 0001 (Batch Input)

2)

Create a flat structure for input data in step 2.

3)

Maintain fields in step 3 for the input structure.

Most of the fields are available in header structure provided by SAP.

While running the transaction online, SAP automatically fills the Depreciation areas based on the
Asset Class. But with this program, Depreciation Area and Depreciation Keys MUST be provided.
In addition to this, if you want to change the Useful life in Years/Periods, please include them in
the source fields as well.
The field for Depreciation Key is AFASLXX. 'XX' depends on how many depreciation areas. For
e.g. AFASL01 for Book Depreciation, AFASL02 for Group Depreciation etc. Similarly, field for
Depreciation Area is AFABEXX.
Take Over values are also present in the header structure and should be mapped with
Depreciation areas.
E.g. of source structure is as shown below:

IP_FD <IP Number> <IP Name>

page 26 of 80

Development Functional and Technical Specification

4) Maintain structure relations: Since we have a flat structure, relate only header level to input
structure.
5) Maintain Field mapping and conversion rules: create the source fields for all target fields and
give transaction as constant 'AS01'.
6)

Specify Files: provide the path of the file in this step.

7)

Assign files to the target structure

8)

Read file

9)

Convert File

10) Create Batch Input session: Normally, this step creates a batch input session which can run
using SM35. But, this is the case with this LSMW program.

IP_FD <IP Number> <IP Name>

page 27 of 80

Development Functional and Technical Specification

3.2.15 ALE Configuration (optional)

TEXT TO BE REMOVED GUIDANCE ONLY
< The following tables should be used to document all ALE/EDI configurations. If Configuration
exists in more than one SAP system, then the information in the following section should be
repeated in multiple tables.
> END OF GUIDANCE TEXT

3.2.15.1

For ALE/IDOC/BAPI/Direct Input

DMM For ALE/IDOC/

BAPI/Direct Input

Source System
System name

&

Client

or

Logical

Partner Profile
Target System & Client or Logical System
Name
Message Type
Basic IDoc Type
IDoc Extension
Business Object / Methods
Process Code / Function Module
1. IDoc Type Structure
TEXT TO BE REMOVED GUIDANCE ONLY
IP_FD <IP Number> <IP Name>

page 28 of 80

Development Functional and Technical Specification

< This table documents the exact IDoc type structure of a customized IDoc
> END OF GUIDANCE TEXT
SAP IDoc Type:
IDoc Extension:
Parent Segment:
New Child Segment:
IDoc Field
Field
Name

Data
Element/Type

Format/Length

Comments

2. Assignment of FM to Logical message and IDoc type

Function Module

FctTyp

BasicTyp

Log message type

Obj type

Directn

Extension

MsgCode

MsgFunct

3. Characteristics of inbound function modules

Function Module

Input type

Dialog allowed

4. Inbound process codes

Process Code

Process Code description

5. Link type and serialisation type of message type

Message type

Serialisation object type

Object type link

6. Workflow event linkages to be activated

Object type

IP_FD <IP Number> <IP Name>

Event

Receiver type

page 29 of 80

Development Functional and Technical Specification

3.2.16 Custom Dictionary Objects (optional)
TEXT TO BE REMOVED GUIDANCE ONL
< Use an appropriate attachment. Table-View Structure and Search Help to be attached
> END OF GUIDANCE TEXT

3.2.17 File Layout

Input / Output File
Name
Ref. Field Name

Field
Type

Starting
Position /
Delimiter

Length

Decimal

Format

Mandatory (M) /
Optional (O)

1.
2.
3.
Volume of data:

3.2.18 Performance Considerations (optional)

TEXT TO BE REMOVED. GUIDANCE ONLY
<Performance considerations (if any), else write N/A>
END OF GUIDANCE TEXT

3.2.19 Dependency
TEXT TO BE REMOVED. GUIDANCE ONLY
<Dependency on other programs / external applications (if any)>
END OF GUIDANCE TEXT

3.2.20 Relevant Function Modules

TEXT TO BE REMOVED. GUIDANCE ONLY
<List the function modules used in the program>
END OF GUIDANCE TEXT

3.2.21 Pseudo Code

TEXT TO BE REMOVED GUIDANCE ONLY
<

IP_FD <IP Number> <IP Name>

page 30 of 80

Development Functional and Technical Specification

Pseudo-code should describe the main steps that will be performed in a program with easy to
follow logic and select statements.

Logic should be detailed enough so that any developer can be able to code the object without
significant effort on logic redesign.

Data declarations should not be included in pseudo-code, unless the data declaration will
impact the logic.

Format the pseudo-code into logical processing units.

Begin each section of pseudo-code with a heading that clearly describes the logic to follow.
(i.e. Validate user input, gather the inventories)

Each main step needs to start with description of the process, in functional language.

All major checking should be specified such as whether the internal table is empty, or if SYSUBRC is equal to zero.

All parameters of a function call should be specified

> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 31 of 80

Development Functional and Technical Specification

3.3 SAP Forms

3.3.1 SAP Script/Forms

Customizing requirements for the form have to be added to the customizing chapter of this
template.
3.3.1.1 Printing Existing Solution

Menu Path for transaction:

Values to be used and output
type:
Actions to be taken:

3.3.1.2 Desired functionality

Output type(s):
Form Types:
Transmission medium:
Legal requirements:
Type of printer:
Paper Size:
Orientation:
Portrait/Landscape:
Special stationary to be used:

3.3.2 Execution Mode Details

TEXT TO BE REMOVED GUIDANCE ONLY
< Specify the execution mode details whether the execution mode is transactional or stand alone
mode
> END OF GUIDANCE TEXT
Transactional:

Output Determination:

Output Type

Print Program

Layout Set

Navigation Path:

IP_FD <IP Number> <IP Name>

page 32 of 80

Development Functional and Technical Specification

Batch Job Name:

Stand Alone:
Select-Options:

Name

Table Field/
Check box/
Radio button

Select-option (S)
or Parameter (P)

Comments (Range,
Single/Multiple Selection,
Patterns, Mandatory, etc.)

Default Value

S or P
Selection Screen Layout: (insert attachment if applicable):

3.3.3 Technical Details

TEXT TO BE REMOVED. GUIDANCE ONLY
< Mention the technical details of the development. Fill the appropriate section
> END OF GUIDANCE TEXT

3.3.3.1 Flow Diagrams

TEXT TO BE REMOVED GUIDANCE ONLY

< Logical flow of the execution of the form
> END OF GUIDANCE TEXT
3.3.3.2 Pseudo Code

TEXT TO BE REMOVED GUIDANCE ONLY

< Pseudo-code should describe the main steps that will be performed in a program with easy to
follow logic and select statements.

Logic should be detailed enough so that any developer can be able to code the object without
significant effort on logic redesign.

Data declarations should not be included in pseudo-code, unless the data declaration will
impact the logic.

Format the pseudo-code into logical processing units.

Begin each section of pseudo-code with a heading that clearly describes the logic to follow.
(i.e. Validate user input, gather the inventories)

Each main step needs to start with description of the process, in functional language.

All major checking should be specified, such as whether the internal table is empty, or if SYSUBRC is equal to zero.
> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 33 of 80

Development Functional and Technical Specification

3.3.3.3 Form Layout

TEXT TO BE REMOVED. GUIDANCE ONLY

< Attachment giving the look of the layout of the form to be developed
> END OF GUIDANCE TEXT
3.3.3.4 Print Program

TEXT TO BE REMOVED. GUIDANCE ONLY

< Details of custom print program can be incorporated here. If it is a SAP print program add
the information what the print program does
> END OF GUIDANCE TEXT
3.3.3.5 SAP script

TEXT TO BE REMOVED. GUIDANCE ONLY

< Details of SAP script can be incorporated here.
> END OF GUIDANCE TEXT
3.3.3.6 Smart form

TEXT TO BE REMOVED. GUIDANCE ONLY

< Details of Smart form can be incorporated here.
> END OF GUIDANCE TEXT
3.3.3.7 Windows

TEXT TO BE REMOVED. GUIDANCE ONLY

<Details of the windows used in the layout
> END OF GUIDANCE TEXT
Reference
W1

Print on page
All Pages

Label Position
X
Y

......
WN

3.3.3.8 Standards Texts / Text Modules

Reference

Text / Field
Name

Print on
page

Label
Position

Font

Output
Format

Font
Format

If a logo is to be printed, specify the standard text ID in the Standard/Application Text(s) table
above.
IP_FD <IP Number> <IP Name>

page 34 of 80

Development Functional and Technical Specification

Logo: Yes/No
Barcodes Yes / No
Barcode Field Name:
Verification of Barcode Printing Capability:
3.3.3.9 Field Mapping

Field

Field
Description

Functionality

3.3.3.10

Reference

Print on
page

Font

Font
Format

Window

Translation

Description of use
(in Language1)

3.3.3.11

Logic

Description of
use (in
Language2)

Description of
use (in
Language3)

Text
module
Name

Notes

Layout Details

Position of Left Margin

(Specify Unit)
Position of Right Margin
(Specify Unit)
Position of Logo
(Specify Unit)
Logo
(Specify Logo)
Position of Main Window
(Specify Unit)

3.3.3.12

Styles

TEXT TO BE REMOVED. GUIDANCE ONLY

< Provide styles used
> END OF GUIDANCE TEXT
3.3.3.13

Paragraph formats

TEXT TO BE REMOVED. GUIDANCE ONLY

< Provide Paragraph formats used
IP_FD <IP Number> <IP Name>

page 35 of 80

Development Functional and Technical Specification

> END OF GUIDANCE TEXT
Paragraph
Format

Description

3.3.3.14

Indents and
spacing

Font

Tabs

Numbering and
outline

Character formats

TEXT TO BE REMOVED. GUIDANCE ONLY

< Provide Character formats used
> END OF GUIDANCE TEXT
Character
format

Description

Standard settings

Font

3.3.4 Table Access Diagram

T ab le 1 Nam e - De s cr ip tio n
KEY 1

KEY 2

KEY 3

KEY 4

KEY 5

KEY 6

KEY 7

FIELD 1 FIELD 2

FIELD 3

FIELD 4 FIELD 5

FIELD 6 FIELD 7

FIELD 8

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/LenTy pe/LenTy pe/Len Ty pe/Len Ty pe/Len Ty pe/Len Ty pe/LenTy pe/Len Ty pe/Len

T ab le 2 Nam e - De s cr ip tio n

T ab le 3 Nam e - De s cr ip tio n

T ab le 4 Nam e - De s cr ip tio n

T ab le 5 Nam e - De s cr ip tio n

KEY 1

KEY 2

FIELD 1

KEY 1

KEY 2

FIELD 1

KEY 1

KEY 2

FIELD 1

KEY 1

KEY 2

FIELD 1

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Des c

Ty pe/Len Ty pe/Len Ty pe/Len

s y -f ield

IP_FD <IP Number> <IP Name>

Ty pe/LenTy pe/Len Ty pe/Len

s y -f ield

Ty pe/Len Ty pe/Len Ty pe/Len

s y -f ield

Ty pe/LenTy pe/Len Ty pe/Len

s y -f ield

page 36 of 80

Development Functional and Technical Specification

3.3.5 Custom Tables / Structure in SAP
TEXT TO BE REMOVED. GUIDANCE ONLY:
< This section should detail the attributes of any custom table used, and the properties of its fields.
NB: Existing SAP Data Elements and/or Domains should be used whenever possible when
creating custom table fields, in order to avoid unnecessary typos. In this instance, the data table
row for that field should not be completed beyond Domain, as the remaining attributes will be
default values for the selected Domain.
>END OF GUIDANCE TEXT
Table Name
Short text
Size category
Table maintenance
allowed
Data class
Buffering
Table maintenance
generation
Authorization Group
Field
Name

Data
Element

Domain Type Length Check

TableField

Key
Field

Foreign Description
Key

Comments

IP_FD <IP Number> <IP Name>

page 37 of 80

Development Functional and Technical Specification

3.4 SAP Interface

3.4.1 Interface Classification

TEXT TO BE REMOVED. GUIDANCE ONLY
< Enter the requested information and type one X in each checkbox group.
> END OF GUIDANCE TEXT
Interface
Number

<Interface Number>

Interface
Name

<Interface Name>

Direction
(with respect
to SAP R/3)

Interface
Type

Interface
Frequency

Type of
Records
Sent

Volume
(per single
execution)

Inbound
Outbound
Other

Interface data flows inbound to SAP R/3

Interface data flows outbound from SAP R/3
Specify:

Batch
One-way transfer of accumulated data set; Usually done by
scheduled file transfer.
Near Real-Time One-way message-based transfer of data; Usually triggered by
event.
Real-Time
Immediate transfer of small data set; Usually triggered by
event.
Excel Upload
Manually invoked from SAP session; Local spreadsheet file
uploaded from PC.
Other
Specify:

Hourly
Daily
Weekly
Monthly
Quarterly
Yearly
On-Demand
Other

Details:
Details:
Details:
Details:
Details:
Details:
How often:
Specify:

Full record load Send all records every time interface is executed
Delta full records Only send records where one or more fields have changed
since previous execution
Delta records
Only send fields (and keys) that changed since previous
interface execution
Other
Specify:

Average Volume:
Peak Volume:

IP_FD <IP Number> <IP Name>

<Volume> records per interface execution

<Lower Volume Upper Volume>

page 38 of 80

Development Functional and Technical Specification

3.4.2 Interface Functionalities

3.4.2.1 Data Filter Rules

TEXT TO BE REMOVED. GUIDANCE ONLY

< Describe any filtering rules that may apply for this Interface
> END OF GUIDANCE TEXT

3.4.2.2 Other Business Rules

TEXT TO BE REMOVED. GUIDANCE ONLY

< Provide any business rules that are applicable for the transformation between the source and the
target. You can also attach a separate spreadsheet.
> END OF GUIDANCE TEXT

3.4.2.3 Process Flow / Data Flow

TEXT TO BE REMOVED. GUIDANCE ONLY

< Capture the interface process flow and/or data flow. Include not only interface steps, but also the
steps immediately before and/or after the interface to establish context. Include diagram(s) if it will
help the explanation, and clearly indicate scope of the interface within the flow. For the steps that
occur within the interface scope indicate who does what, when, how, and all related error
conditions.
> END OF GUIDANCE TEXT

3.4.3 Interface Data Requirements

3.4.3.1 Source Interface Data Layout

TEXT TO BE REMOVED. GUIDANCE ONLY:

< List the data elements that will be provided by the source system for this interface. Do not make
any assumptions about how the data will be accessed, and instead provide all methods that are
available to access the data. For example, your data may be available from both a database and a
file.
> END OF GUIDANCE TEXT
Source data is available as (Type X for all that apply):

IP_FD <IP Number> <IP Name>

page 39 of 80

Development Functional and Technical Specification

Database
File

Table
Name(s):
Type:

Procedure Name:
Method:
Other

< Provide Table Name>

<e.g. Comma Delimited, Fixed Position, Excel> XML file
<List function, transaction, or other procedure call that can provide this
data set>

If indicated Database above, provide the table columns necessary for this interface:
Table

Column

Element Description

Data Type

Length

If indicated File above, provide the fields here (preserve order):

Field #

Field Description

Data Type

Length

If indicated Procedure above, provide the fields of the result set here:
Field Name

Field Description

Data Type

Length

If indicated Other above, list field detail here:

If you have preferences or concerns on the information in this section, mention them here:

3.4.3.2 Target Interface Data Layout

TEXT TO BE REMOVED. GUIDANCE ONLY:

< List the data elements that are required by the target system for this interface. Do not make any
assumptions about how the data will be delivered, and instead provide all methods that are
available to accommodate the data. For example, your data may be deliverable as both a file and
a transaction call.
> END OF GUIDANCE TEXT
Target data can be delivered as (Type X for all that apply):
Database
File

Table
Name(s):
Type:

Procedure Name:
Method:
Other

IP_FD <IP Number> <IP Name>

<e.g. ABC0001, VENDOR Number>

<List function, transaction, or other procedure call that can provide this
data set>
Development team will decide

page 40 of 80

Development Functional and Technical Specification

If indicated Database above, provide the table columns necessary for this interface:
Table

Column

Element Description

Data Type

Length

If indicated File above, provide the fields here (preserve order):

Field #

Field Description

Data Type

Length

If indicated Procedure above, provide the fields of the result set here:
Field Name

Field Description

Data Type

Length

If indicated Other above, list field detail here:

If you have preferences or concerns on the information in this section, mention them here:

3.4.3.3 Source / Target Data Mapping

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Complete the list. Other mapping documents can be attached in this section as supporting
documentation, but this MUST be populated with all of the data elements used in this interface.
> END OF GUIDANCE TEXT
Source
Element

Transformation

Target
Element

Comments

3.4.3.4 Sample Data

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Provide two attachments of sample source data with the expected target data after this interface
is executed. Supply the sample data in the native format or .csv, and preferably zipped.
> END OF GUIDANCE TEXT

3.4.3.5 Data Retention

TEXT TO BE REMOVED. GUIDANCE ONLY:

IP_FD <IP Number> <IP Name>

page 41 of 80

Development Functional and Technical Specification

< In file based interfaces a backup copy of interface data can be retained in the middleware for
each execution. This can be useful for reconciliation purposes. Indicate the retention period for this
interface. If not file based, then the source or target system must fill any data retention
requirements.
> END OF GUIDANCE TEXT
None
7 days
15 days
30 days
Other

Data retention is not necessary for this interface

(default)
Specify
:

3.4.3.6

Special Case: Bi-Directional Real Time Interface

TEXT TO BE REMOVED. GUIDANCE ONLY:

< If you know this interface will be a bi-directional real-time interface (i.e. the Source system
sends and receives data in the same execution), then a second data mapping is required. If
applicable, duplicate the table from section (insert source link) and capture the return data
mapping rules for the Source system.
> END OF GUIDANCE TEXT

3.4.4 Table Access Diagram

TEXT TO BE REMOVED. GUIDANCE ONLY
<Table Access Diagram with primary key relationships between tables. Not necessary if calling
transaction(s) to update SAP tables
> END OF GUIDANCE TEXT

3.4.5 Selection Criteria

Name

Table Field/
Check box/
Radio
button

Select-option (S) or Comments (Range,

Parameter (P)
Single/Multiple
Selection, Patterns,
Mandatory, etc.)
S or P

Default Value

Variants:
Attach selection screen shot here

IP_FD <IP Number> <IP Name>

page 42 of 80

Development Functional and Technical Specification

3.4.6 SAP Requirements
3.4.6.1 Interface Trigger in SAP and/or Middleware

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Describe what initiates the execution of this interface. >
> END OF GUIDANCE TEXT
3.4.6.2 SAP Transaction

If the interface uses an SAP transaction to extract or insert data, capture the details here.
Custom SAP Transaction (New)
Custom SAP Transaction (Existing)
Standard SAP Transaction
None

3.4.6.3

Name:
Name:
Name:

ALE and IDOC specific information ( if any )

Field/Parameter
Source System & Client
or Logical System Name

Values

Target System & Client

or Logical System Name
Sender Partner Number
Sender Partner Type
Receiver Partner
Number
Receiver Partner Type
Message Type
IDoc Type
Extension Name
Business Object

3.4.6.4

SAP Scheduling / Performance Requirements / Service Level Agreement

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Describe any requirements around the timing of this interface.
> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 43 of 80

Development Functional and Technical Specification

3.4.6.5

SAP Special Requirements

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Provide any system requirements that are applicable for SAP. Information like data retrieval
logic, detail functionality, data retrieval logic diagram can be mentioned here.
> END OF GUIDANCE TEXT

3.4.7 Middleware Solution

3.4.7.1

Solution Description

TEXT TO BE REMOVED. GUIDANCE ONLY:

<This section should contain an outline of the chosen middleware solution and the processes
involved.
> END OF GUIDANCE TEXT
3.4.7.2

Mapping Rules & Conversion Criteria

TEXT TO BE REMOVED. GUIDANCE ONLY:

< This section should contain a high level outline of the mapping rules and conversion criteria.
> END OF GUIDANCE TEXT

3.4.8 Legacy System Requirements

3.4.8.1

Legacy System Details

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Provide the following information on the Legacy System.
> END OF GUIDANCE TEXT
Application Name

<Application Name>

Name Abbreviation
Primary Contact

Legacy
Application
Conversion
Strategy

SAP Values
All historical data will be converted to or is already
compatible with SAP values
Legacy ValuesApplication will not be converted and requires ongoing
translation to SAP values
Mixture
Specify: <e.g. SAP Cost Centers, Legacy Employee
Numbers>
Other
Specify: Conversion of customer number from Legacy to SAP. Business
Team will be responsible for one time update. <Project > team is responsible for providing full file of
all partner types and the SAP customer with reference to legacy customer number.

IP_FD <IP Number> <IP Name>

page 44 of 80

Development Functional and Technical Specification

Legacy
Application
Decommission

None
application
<Project>
<Project >:
Date
Fall 2007, >
Other

There are currently no plans to decommission this

This application will be decommissioned after go-live
<N>
This application will be decommissioned in <e.g. Q4 2006,
Specify:

What system will replace the legacy functionality after it is

decommissioned?

Test

Applications
Relationship
To Interface

Source
Target
elsewhere
Both
application
Other

Interface data is communicated both to and from this

Specify:

Server / IP

<Provide the server /IP details>

Directory

Same as above

Database

Same as above
Test environment passwords have been emailed to <mail Id> mailbox
Test environment is N/A Reason:

Password
Capture

Prod

Interface data originates from this application

Interface data is delivered to this application from

Server / IP

<Provide the server /IP details>

Directory

Same as above

Database

Same as above
Prod environment passwords have been emailed to <mail Id> mailbox
Prod environment is N/A Reason:

Password
Capture

3.4.8.2

Interface Trigger on Legacy System

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Describe what initiates the execution of this interface. If time-based, capture the day and time
requirements.
> END OF GUIDANCE TEXT
3.4.8.3

Legacy Scheduling / Performance Requirements / Service Level Agreement

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Describe any requirements around the timing of this interface.

> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 45 of 80

Development Functional and Technical Specification

3.4.8.4

Legacy Special Requirements

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Provide any system requirements that are applicable for the legacy system.
> END OF GUIDANCE TEXT
3.4.8.5

Legacy Initial Processing

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Describe any pre-processing the legacy system must perform on interface data before loading.

> END OF GUIDANCE TEXT

3.4.9 Data Conversion & Interface Definition

TEXT TO BE REMOVED GUIDANCE ONLY
<For inbound interfaces, indicate any relevant transaction codes and a description of the dynamic
transaction call (i.e. for materials, if the material exists, MM02 is called, whereas for materials not
already established in SAP, MM01 is called).
> END OF GUIDANCE TEXT

File
Name

Inbound /
Outbound
I/O

File Type
(ASCII,
EBCDIC,
Excel etc.)

Location

Source System:

Target System:

Description

Logical
File
Name

File
Delimiter

Comments

System Diagram:

IP_FD <IP Number> <IP Name>

page 46 of 80

Development Functional and Technical Specification

3.4.10 Data Mapping Matrix
3.4.10.1

For BDC/Call Transaction

DMM for BDC/Call

Transaction
3.4.10.2

For ALE/IDOC/BAPI/Direct Input

DMM For ALE/IDOC/

BAPI/Direct Input
3.4.10.3

For LSMW

TEXT TO BE REMOVED. GUIDANCE ONLY

< This section needs to be filled if the development is of type LSMW. Write the Objects Attributes,
Source Structures, Source Fields, Structure Relations here
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
IP_FD <IP Number> <IP Name>

page 47 of 80

Development Functional and Technical Specification

Input files

Source structure

STEP 9: Read Data

STEP 10: Display read data

STEP 11: Convert Data

STEP 12: Display converted data

etc.
> END OF GUIDANCE TEXT

3.4.11 File Layout

Input / Output File
Name
Ref.
Field Name Field
Type

Starting
Position /
Delimiter

Length

Decimal

Format

Mandatory (M) /
Optional (O)

1.
2.
3.
Volume of data:

3.4.12 Dependency
TEXT TO BE REMOVED. GUIDANCE ONLY
<Dependency on other programs / external applications (if any)
> END OF GUIDANCE TEXT

3.4.13 Relevant Function Modules

TEXT TO BE REMOVED. GUIDANCE ONLY
<List the function modules used in the program
> END OF GUIDANCE TEXT

3.4.14 Pseudo Code

TEXT TO BE REMOVED GUIDANCE ONLY
<
IP_FD <IP Number> <IP Name>

page 48 of 80

Development Functional and Technical Specification

Pseudo-code should describe the main steps that will be performed in a program with easy to
follow logic and select statements.

Logic should be detailed enough so that any developer can be able to code the object without
significant effort on logic redesign.

Data declarations should not be included in pseudo-code, unless the data declaration will
impact the logic.

Format the pseudo-code into logical processing units.

Begin each section of pseudo-code with a heading that clearly describes the logic to follow.
(i.e. Validate user input, gather the inventories)

Each main step needs to start with description of the process, in functional language.

All major checking should be specified such as whether the internal table is empty, or if SYSUBRC is equal to zero.

All parameters of a function call should be specified

> END OF GUIDANCE TEXT

3.4.15 ALE Configuration (optional)

TEXT TO BE REMOVED GUIDANCE ONLY
< The following tables should be used to document all ALE/EDI configurations. If Configuration
exists in more than one SAP system, then the information in the following section should be
repeated in multiple tables.
> END OF GUIDANCE TEXT
Source System
System name

&

Client

or

Logical

Partner Profile
Target System & Client or Logical System
Name
Message Type
Basic IDoc Type
IDoc Extension
Business Object / Methods
Process Code / Function Module
1. IDoc Type Structure
TEXT TO BE REMOVED GUIDANCE ONLY
< This table documents the exact IDoc type structure of a Customized IDoc
> END OF GUIDANCE TEXT
SAP IDoc Type:
IDoc Extension:
Parent Segment:
IP_FD <IP Number> <IP Name>

page 49 of 80

Development Functional and Technical Specification

New Child Segment:
IDoc Field
Field
Name

Data
Element/Type

Format/Length

Comments

2. Assignment of FM to Logical message and IDoc type

Function Module

FctTyp

BasicTyp

Log message type

Obj type

Directn

Extension

MsgCode

MsgFunct

3. Characteristics of inbound function modules

Function Module

Input type

Dialog allowed

4. Inbound process codes

Process Code

Process Code description

5. Link type and serialization type of message type

Message type

Serialisation object type

Object type link

6. Workflow event linkages to be activated

Object type

Event

Receiver type

3.4.16 Custom Data Dictionary Objects (Optional)

TEXT TO BE REMOVED GUIDANCE ONLY
< Use an appropriate attachment
IP_FD <IP Number> <IP Name>

page 50 of 80

Development Functional and Technical Specification

> END OF GUIDANCE TEXT

3.4.17 Performance Consideration (Optional)

TEXT TO BE REMOVED. GUIDANCE ONLY
<Performance considerations (if any), else write N/A
> END OF GUIDANCE TEXT

3.4.18 Interface Controls

3.4.18.1

Completeness Control

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Interface functionality includes automated processes or manually captured results that will occur
for each execution that verify all the data transmitted by the source system has been uploaded to
the receiving system. Example controls:
How will the receiving system ensure that they have received all the data intended for their
application?
Is a trailer record expected? If yes, what values are expected in the trailer record?
Are interface hash totals expected?
How will completeness be verified and validated?
> END OF GUIDANCE TEXT
Control

3.4.18.2

Control Addressed

Accuracy Control

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Interface functionality includes automated processes or manually captured results that will occur
for each execution that verify the data uploaded to the receiving system is the same data that was
transmitted by the source system. Example controls:
How will the receiving system ensure they have the complete data values?

How will the receiving system ensure that source records were accurately converted or
transformed?
> END OF GUIDANCE TEXT
Control

IP_FD <IP Number> <IP Name>

Control Addressed

page 51 of 80

Development Functional and Technical Specification

Control

3.4.18.3

Control Addressed

Duplicate Records Control

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Interface functionality includes processes to handle duplicate records.
If the receiving system cannot handle duplicate records, this interface includes a process to
insure that duplicate records are not transmitted to the receiving system.
If the receiving system can handle duplicate records, the logic exists to process duplicate records
appropriately (i.e. Initiating an update, discard process etc.
Are corresponding key values available in the source system and the receiving system to insure
that duplicates do not occur?
Does the receiving system have logic in place to avoid duplicate records from being processed?
If no, are duplicate records possible from the sending system? If yes, does this interface require
the logic to process duplicate records according to receiving system business rules?
> END OF GUIDANCE TEXT
Control

Control Addressed

3.4.18.4

Error Detection and Communication Control

3.4.18.5

Integrity of Data Transformation Control

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Automated processes or manual result procedures that will execute for each interface execution
will be used to verify that the data that is summarized, translated, reformatted, or converted
remains accurate and complete during processing. Example controls:
What source values are transformed by Middleware?
How will the validation between the source and receiving system values occur to insure
success?
Are cross reference tables used in this interface? How will this transformation be validated?
> END OF GUIDANCE TEXT
Control

IP_FD <IP Number> <IP Name>

Control Addressed

page 52 of 80

Development Functional and Technical Specification

3.4.18.6

Standard File Format Control

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Automated processes or manual result procedures that will be executed for each interface
execution to verify that the data being transmitted by the source system and uploaded to the
receiving system is accomplished by using a defined file layout that is not intended to be changed
each time the interface is run. Example controls:
What is the format of the data that is sent from the sending system to the receiving system?
How is this format insured?
> END OF GUIDANCE TEXT
Control

3.4.18.7

Control Addressed

Interface Data Security

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Automated processes or manual result procedures that will be executed for each interface
execution to verify that the path used to transmit data from the source system to the receiving
system either cannot be accessed other than by certain electronic means (i.e. programs,
transactions, etc.) or that access path is limited to a few appropriate people. Example controls:
What controls the data security?
How is the security defined?
What enforces this security?
> END OF GUIDANCE TEXT
Control

Control Addressed

3.4.19 Compliance
3.4.19.1

Compliance Team Classification

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Indicate which Compliance Team member has determined the relevance of this interface.
> END OF GUIDANCE TEXT
Determined by:
Not yet determined
IP_FD <IP Number> <IP Name>

page 53 of 80

Development Functional and Technical Specification

3.4.19.2

Relevant Regulations

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Indicate any regulations that govern the design and execution of this interface.
> END OF GUIDANCE TEXT
SOX
HIPAA
Other

Why?:
Why?:
Specify
:

3.4.19.3

Other Regulatory Requirements

TEXT TO BE REMOVED. GUIDANCE ONLY:

< Describe any additional regulatory requirements (e.g. non-HIPAA, non-SOX). Also include
original text from requirement. This ensures that everyone will read the same version of the
requirement, even if the official requirement changes over time.
> END OF GUIDANCE TEXT

3.4.20 Miscellaneous Data Capture (Optional)

3.4.20.1

Interface referring Report Definition Document(s)

TEXT TO BE REMOVED. GUIDANCE ONLY:

< List the report specification numbers that define the non-interactive reports used for monitoring,
reconciliation, or logging purposes. Reports necessary to support this interface for monitoring,
reconciliation, or logging will require a report specification to be populated. NOTE: The same
report can satisfy the requirements for more than one interface specification.
> END OF GUIDANCE TEXT
Report Specification Number

3.4.20.2

Description

Other Pertinent Details

TEXT TO BE REMOVED. GUIDANCE ONLY:

< If you feel that there is something that needs to be communicated or documented that you are
unable to find the proper location in the above template, document it here.
> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 54 of 80

Development Functional and Technical Specification

Item

IP_FD <IP Number> <IP Name>

Description

Reported By

Date

page 55 of 80

Development Functional and Technical Specification

3.5 SAP ECC Report

3.5.1 Technical Solution

TEXT TO BE REMOVED. GUIDANCE ONLY:
< This section highlights the key design issues. A series of bullet points summarizes the logic
chosen for the program and the main technical difficulties.
For Example:
What assumptions are made in the technical specification and what they entail in technical
terms.
Key process steps.
Why a particular function module was chosen.
Why use multiple selects than just one.
Why use a particular kind of logic for the main processing.
What were the major technical problems with the design of the program.
Etc.
> END OF GUIDANCE TEXT

3.5.2 Selection Screen

3.5.2.1 Extract Data Relationship Diagram

TEXT TO BE REMOVED. GUIDANCE ONLY:

IP_FD <IP Number> <IP Name>

page 56 of 80

Development Functional and Technical Specification

< The purpose of the diagram is to show the database tables that contain the relevant data for the
report and the relationships between them. Drawing the diagram removes out many of the main
design issues of the program at both the business and the technical levels.
Diagram Guidelines

The diagram should show all the SAP tables that the program will extract data from.

The relationships between tables should also be illustrated in the form of crows feet (one to
one, one to many etc.) This is useful as it will show the developer whether they are
expected to have multiple or single records for a chosen related record.

Database tables using keys F1 and F9.) Note when structures are included in the
diagram, the notes section will become much more complicated.

> END OF GUIDANCE TEXT

3.5.2.2 Selection Prototype

TEXT TO BE REMOVED. GUIDANCE ONLY:

< A screen dump of a prototype of the selection screen should be included, showing the way the
fields are ordered, frames, titles, etc. This will allow QA review at an early stage.
> END OF GUIDANCE TEXT
For Example:

IP_FD <IP Number> <IP Name>

page 57 of 80

Development Functional and Technical Specification

3.5.2.3 Details

TEXT TO BE REMOVED. GUIDANCE ONLY:

< In this section, all the error messages (ID and Classes) prompted by the validations executed at
the selection screen will be detailed
For Example:

If an invalid Company Code is entered on the selection screen the message E001(ZF)
Company Code & is not valid should appear and the field is left open for input.

Etc.

> END OF GUIDANCE TEXT

3.5.3 Starting Condition

TEXT TO BE REMOVED. GUIDANCE ONLY:
< When should the report be run? Does an interface need to be run before the report is valid, and
(more commonly), should it be a batch only program (with added security) or is it needed on-line
as well?
Eg This program will be run after month-end billing.
Eg This program will be run each time a sales order is saved
> END OF GUIDANCE TEXT
IP_FD <IP Number> <IP Name>

page 58 of 80

Development Functional and Technical Specification

3.5.4 Data Mapping Tables
TEXT TO BE REMOVED. GUIDANCE ONLY:
< List of all the fields along with their details are to be mentioned here. Look and feel wise, a
desired report design can also be specified here.
> END OF GUIDANCE TEXT
Field Name

Field Desc

3.5.4.1

Output Output Format Position SAP screen No./ field

Length Type
name

Desired Report Design/Layout

Use screen shot if possible

3.5.4.2

Report Example

Use screen shot if possible

IP_FD <IP Number> <IP Name>

page 59 of 80

Development Functional and Technical Specification

3.5.5 Detail Logic Diagrams

TEXT TO BE REMOVED. GUIDANCE ONLY:
< The diagrams, along with the notes associated to them should be the main structure of
the program. They should include critical decision logic, the database selects, complex
conversions, calculations, and formatting and output.
High Level Overview
< P ro g ra m n a m e >

S E L E C T I0 O N
SC R EEN
P R O C E S S IN G

M A IN
P R O C E S S IN G

F IN A L
P R O C E S S IN G

> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 60 of 80

Development Functional and Technical Specification

3.5.5.1 Selection Screen

TEXT TO BE REMOVED. GUIDANCE ONLY:

< The diagram should show the processing triggered by the selection screen.
Example:

S e l e c t io n S c r e e n P r o c e s s i n g

P_C O M P

R B_TES T

Is c o m p a n y
c o d e v a li d ?

N o

Is s u e e r ro r
m e s s a g e to
s c r e e n . L e a v e fi e l d
o p e n fo r i n p u t

Is T e s t
R a d i o b u t to n
s e le c te d

Yes

Yes

A ccept com pany

code

S e t p ro g ra m m o d e
t o te s t

N o

S e t p ro g ra m m o d e
to l i v e

> END OF GUIDANCE TEXT

3.5.5.2 Main Processing

TEXT TO BE REMOVED. GUIDANCE ONLY: <

Detail logic diagrams will amalgamate the data relationship diagram and the report (or file)
layout diagram from the functional specification to illustrate the flow of the program. They
should link the input and output format to the data.

Each database table will roughly equate to each subroutine.

The file layout diagram will roughly equate to the final output internal table to be created in
the code.

The diagram should not be a simple copy and paste of the diagrams from the function
specification. The programmer should investigate efficient ways of coding the program. For
example, often it is more efficient to perform selects on a database table from the data
relationship diagram in the final part of the processing where the output is formatted. Eg
you are to produce a customer report for all the customers that have outstanding invoices
for over 30 days. Through program validations and calculations the number of valid
customers is greatly reduced. Only at this point would you retrieve the customer details
from the database to be displayed.

The data relationship should be considered in two ways in this diagram. If a many to one
relationship exists between two tables because of the program flow (but does not appear in
the functional specification as the database relationship is only one to one or one to
many). This should be illustrated, as it will have an impact on where the selects in the code

IP_FD <IP Number> <IP Name>

page 61 of 80

Development Functional and Technical Specification

appear. For example, the functional specification may state that document headers are
selected first and then the subsequent item lines are then selected afterwards. However it
may prove to be more efficient to select the item lines first and then get the corresponding
header lines due to the information that the program has already accumulated.

Direction arrows should be included in the diagram, but it should not be a full on logic-flow
diagram to avoid over complication. There should be no decision logic included in the
diagram unless this impacts upon where the data is taken from or what the overall output
is.

Example:

> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 62 of 80

Development Functional and Technical Specification

IP_FD <IP Number> <IP Name>

page 63 of 80

Development Functional and Technical Specification

IP_FD <IP Number> <IP Name>

page 64 of 80

Development Functional and Technical Specification

2

M A IN P R O C E S S IN G

Is R B _ O P E N
s e le c te d ?

N o

Y es

N o te 1

B S ID

BS A D

K N A 1

R e p o rt ta b le

N o te 2

N o te 3

N o te 4

3.5.5.3 Final Processing

TEXT TO BE REMOVED. GUIDANCE ONLY:

< The final processing section will differ depending on the type of program being designed. A
report/outbound program should illustrate the final output of the program (example 1) while an
inbound program should show the screens that are processed and the function codes that
navigate between them (example 2).
Example 1:

IP_FD <IP Number> <IP Name>

page 65 of 80

Development Functional and Technical Specification

R e p o rt to b e
s e n t to th e
s p o o l?

F IN A L P R O C E S S IN G

I_ O U T P U T

Yes

S e t p rin t
p a r a m e te r s

H eader

D e ta il L in e s

S u m m a rie s

C om pany

C u s to m e r

A c c o u n tin g
C le rk

A c c o u n ti n g
C le rk

D ocum ent
N um ber

C om pany

A m ount

D ays
O v e rd u e

IP_FD <IP Number> <IP Name>

page 66 of 80

Development Functional and Technical Specification

Example 2:

> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 67 of 80

Development Functional and Technical Specification

3.5.5.4 Detail Logic Notes

TEXT TO BE REMOVED. GUIDANCE ONLY:

< The notes should complement the detail logic diagrams.
They should include all the error messages (ID and Class), as well as the complete SQL
statements (all fields and selection criteria) and the function modules used. Details of calculations
or particular formatting should also be included here.
Example:

Note 1

Retrieve the following fields from BSID (Customer open documents table)
BUKRS (Company Code)
BELNR (Document Number)
KUNNR (Customer Number)
DMBTR (Amount in local curreny)
BLDAT (Document Date)
By the following key
BUKRS (Company Code)

P_COMP

If no records are found issue an error message to the screen: E012(ZF) No records found for
company code P_COMP and return to the selection screen.

Note 2

Etc
> END OF GUIDANCE TEXT

3.5.6 Interactive Report Flow

TEXT TO BE REMOVED. GUIDANCE ONLY
< If the report is an interactive report, mention the flow of the navigation in details
> END OF GUIDANCE TEXT

3.5.7 Sort Criteria Details

TEXT TO BE REMOVED. GUIDANCE ONLY
< Mention the sorting criteria of the Report Output. Specify the field name at different level of
sorting.
> END OF GUIDANCE TEXT

3.5.8 Calculations and Page Break related information

TEXT TO BE REMOVED. GUIDANCE ONLY
< Mention the calculation logic in detail and the Page break information
IP_FD <IP Number> <IP Name>

page 68 of 80

Development Functional and Technical Specification

Example:
Calc 1 Expected Production Cases
This field is calculated by converting the number of Lals in the Actual Syrup Used Lals field to
cases based on the alternative unit of measure that has been set up for the material. The
CF_UT_UNIT_CONVERSION function module can be used to calculate this value.
> END OF GUIDANCE TEXT

3.5.9 Custom Tables / Structure in SAP

TEXT TO BE REMOVED. GUIDANCE ONLY
< This section should detail the attributes of any custom table used, and the properties of its fields.
NB: Existing SAP Data Elements and/or Domains should be used whenever possible when
creating custom table fields, in order to avoid unnecessary typos. In this instance, the data table
row for that field should not be completed beyond Domain, as the remaining attributes will be
default values for the selected Domain
> END OF GUIDANCE TEXT
Table Name
Short text
Size category
Table maintenance
allowed
Data class
Buffering
Table maintenance
generator
Authorization Group
Field
Name

Data
Element

Domain Type Length Check

TableField

Key
Field

Foreign Description
Key

Comments

3.5.10 Recovery and Restart

TEXT TO BE REMOVED. GUIDANCE ONLY

IP_FD <IP Number> <IP Name>

page 69 of 80

Development Functional and Technical Specification

< If the program fails half way through will this have an impact on any programs to be run after its
completion? Who will re-run the report if it does not function properly? Should anyone be alerted if
certain validations fail?
> END OF GUIDANCE TEXT

3.5.11 Language of texts

TEXT TO BE REMOVED. GUIDANCE ONLY:
< The texts of the report may be different in different countries. What language should be used to
derive these texts? The login language or another?
> END OF GUIDANCE TEXT

3.5.12 Currency and Units of Measure

TEXT TO BE REMOVED. GUIDANCE ONLY:
< Are all the units of measure and currency details in the data mapping tables correct? Will the
report work for different currencies? What about the EURO? What happens to the report if the
common measure of weight used on clients sites is changed to tonnes instead of kilograms? Or to
stones and pounds?
> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 70 of 80

Development Functional and Technical Specification

3.6 SAP BW Report

3.6.1 Report Description:

Who
Why
What
When

3.6.2 Report Layout

Original Layout
(Original File to be attached)
Data model to retrieve the above spreadsheets follows:
Row

Column

Description/Formula

Description/Formula

Characteristic

Characteristic
Value

Key
figure

Characteristic

Characteristic
value

Key
figure

Notes (if any):

3.6.3 Report Selections and Navigation

3.6.3.1 Report Selections (Filters)

Field Name

IP_FD <IP Number> <IP Name>

Other Selection Information

page 71 of 80

Development Functional and Technical Specification

3.6.3.2 Report Navigation (Free Characteristics)

Field Name

IP_FD <IP Number> <IP Name>

Other Navigation Information

page 72 of 80

Development Functional and Technical Specification

3.7 SAP Workflow

3.7.1 SAP Workflow Diagram

TEXT TO BE REMOVED. GUIDANCE ONLY:
< Show the technical workflow diagram
(One can use Visio or can even paste the diagram from the downloaded file from the workflow
builder Menu options: Workflow Print Graphic)

SAP Workflow Process Steps:

Business Process Trigger:
The process steps should describe the technical implementation done in the workflow template.
There should be a one to one match between the process step & the workflow diagram. Thus if the
workflow diagram had 12 boxes and each numbered from 1 to 12 then there should be 12
process steps describing each step in the diagram.
See below for sample pseudo-code:
1. Workflow is started via transaction XYZ.
2. Condition Step: Describe the condition.
3. Container Operation: Describe the operation taking place in the container.
3A.Background Step: Describe the step; for example: the date after eight business days is
calculated. This date will be used to send a notification to the supervisor of Approver#1 is
no action was taken by Approver#1 for three business days.
4. Background Step: Approver#1 is determined.
5. Activity (Dialog) Step: The work item is presented to the approver for necessary action
(Approve/ Reject).
Approve Path
6. Container Operation: The status container is set to A.
7. Container Operation: The name of approver is added to a multi line container.
Reject Path
8. Activity (Dialog) Step: A window is presented to approver to enter the rejection comments.
9. Background Step: The document is reverted back to the original status.
10. Background Step: A mail is sent to the initiator informing him/her about the rejection.
11. Process Control Step: The workflow instance is terminated.
12. The workflow ends.
Exception Handling
13. Background Step: A mail is sent to the workflow administrator.
14. Background Step: A mail is sent to the approver stating that the work item will be presented
again for approval.
Escalation Handling
IP_FD <IP Number> <IP Name>

page 73 of 80

Development Functional and Technical Specification

14A. Background Step: Supervisor of Approver#1 is determined.
14B. Background Step: A mail is sent to the Supervisor of Approver#1 informing
that no action was taken by Approver#1.
15. Loop: If the status container is not equal to A (Approved); the work item is routed back to
the approver; else the workflow continues to the next approver.
> END OF GUIDANCE TEXT

3.7.2 Technical description

Enter the requested information and type one X in each checkbox group
Trigger mechanism

Start Condition

(Mention the start condition for the workflow, e.g. on creation

of a purchase document, batch program etc)
Example The workflow should start only for certain
document type , work flow should start only if credit amount is
greater than 250000 etc

SAP business Object

(Mention the SAP business object, if possible. Otherwise

indicate the object in general terms (e.g., Purchase
Requisition)

SAP Standard Workflow

Task/Template

In case of enhancement required for SAP delivery workflow is

required

Level of approval required

Agent determination
technique

Role
Security Role
Org Unit
HR org structure.
Custom Table Agents maintained in custom table
Distribution lists
Unspecified To be decided in technical design; Will
provide
detailed requirements in this doc.
Other
Specify:
If the agent determination technique is different for each foreground
step then repeat this section.

Mention logic for agent

determination (if any)
Notification destination

Internal SAP user SAP Inbox

External E-mail Id Example Lotus notes

Workflow notifications text

If any specific work item text/work item subject to be used

Escalation handling (if any)

If any deadline monitoring is to be done. Example: If approver does

not approve for 3 business days notify his supervisor

Integration with portal

Configuration
dependencies

IP_FD <IP Number> <IP Name>

(Example setting up a new organization structure)

page 74 of 80

Development Functional and Technical Specification

Error handling (if any)

An exception situation could occur if workflow routes to

a one position is vacant/not available (i.e. no user is
assigned to that position.)
If a specific report or additional information is required.
Add attachment if necessary.

Substitution

3.7.3 Business Object Information

Object Type:
Description:
Short Description:
Program:
SuperType:
Application

Key Fields
Element

Description

Dictionary Field

Attributes (only mention those used in the workflow template)

Element

Description

Source

Attribute Property

Dictionary Field

Pseudo
logic
Ref

Virtual
Database

Multiline
Mandatory
Instanceindependent

A1

Virtual
Database
Obj Status

Multiline
Mandatory
Instanceindependent

A2

Pseudo logic : Mention Logic for custom attributes only.

A1:
A2:

Method (only mention those used in the workflow template)

Name

Description

IP_FD <IP Number> <IP Name>

Source
Dialog
Synchronous
Result
parameter
Instance
independent

Result Type

ABAP
Function
Module
API
Transaction
Dialog
Module
Reports
Others

Pseudo logic Ref

M1

page 75 of 80

Development Functional and Technical Specification

Key Fields
Element

Description

Dictionary Field
Dialog
Synchronous
Result
parameter
Instance
independent

Function
Module
API
Transaction
Dialog
Module
Reports
Others

M2

Pseudo logic: Mention Logic for custom methods only.

M1 Pseudo logic:
Imp

EXP

Parameter List

Mutiline

Imp

EXP

Parameter List

Mutiline

Parameter List

Exception
M2 Pseudo logic:

Parameter List

Exception

Event (only mention those used in the workflow template)

Name

Description

Parameter List

Import

Export

3.7.4 Workflow Definition

Abbreviation:
Name:
Triggering Events:
Object Type:
Event:

Number:

Workflow Container:
Element

Description

IP_FD <IP Number> <IP Name>

Import
(Y/N)

Export
(Y/N)

Multiple
Values
(Y/N)

Mandatory
(Y/N)

Dictionary
Field

Object
Type

page 76 of 80

Development Functional and Technical Specification

Binding Workflow Container/Event Container: (Indicate in the middle column below as to the
direction of the parameters - or )
Workflow Container Element

Event Container Element

Responsibility Agents:
Task Name

Agent

Deadline

Notification

3.7.5 Deadline Monitoring Requirements

Task Name

Deadline Time

Agent

Type

3.7.6 Reporting / Form Requirements

Description

SAP Tool

Report Name

Custom Requirements

3.7.7 Custom screen design

TEXT TO BE REMOVED. GUIDANCE ONLY
< Technical details of custom screen can be incorporated here. Number of screens required and
flow diagram can be included and provide the selection screen screen shot along with the table
name and field name and screen shot for the required output.
> END OF GUIDANCE TEXT

3.7.8 Custom Tables / Structure in SAP

Table Name
Short text
Size category
Table
maintenance
allowed
Data class
Buffering
Table
maintenance
generator
Authorization
IP_FD <IP Number> <IP Name>

page 77 of 80

Development Functional and Technical Specification

Group
Field
Data
Name Element

Domain

Typ
e

Length

Check
TableField

Key
Field

Foreig
n Key

Descriptio
n

Comments

3.7.9 User Exit / Enhancement Detailed Description

TEXT TO BE REMOVED. GUIDANCE ONLY
< If workflow to be triggered from user exit or if any modification required using user exit.
> END OF GUIDANCE TEXT

3.7.10 Configuration Information

TEXT TO BE REMOVED. GUIDANCE ONLY
< List the configuration/custom objects that need to be maintained for this workflow to function.
Some commonly used examples are listed below
> END OF GUIDANCE TEXT

Server:
Activity

Client:
T-Code

Screen shot

3.8 SAS Developments

Text

IP_FD <IP Number> <IP Name>

page 78 of 80

Development Functional and Technical Specification

4.Security and Authorization Requirements

TEXT TO BE REMOVED. GUIDANCE ONLY:
< Define the role matrix related with the objects and processes for the authorization objects. List
Segregation of duty requirements.
> END OF GUIDANCE TEXT

IP_FD <IP Number> <IP Name>

page 79 of 80

Development Functional and Technical Specification

5.Attachments

IP_FD <IP Number> <IP Name>

page 80 of 80