Functional and Technical Design

Specification
Add Warrior Customer Number to the
Customer Master

Prepared by: SD Team

FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master

Page 1 of 25

Document Information
Document
Name:

FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master

Document
Author/Owner:
Author/Owner
Contact Info
Electronic
Location:

Document Revision History

Document
Version #

Revision Date

Author

Revision Description

1.0

Functional Specification Acceptance Sign-off

Role:

Name:

Signature/Electronic Reference

Business Process
Owner/ Requestor
Functional Team
Lead
Technical Lead
PMO

Table of Contents
FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master

Page 2 of 25

Date

Attributes

2
2.1
2.2
2.3
2.4
2.5
3

Business Requirements
6
Overview
6
Business Users (requested by) 6
Benefits / Alternatives/ Assumptions
Comments
6
Related Documents (Ref BPDD No.)

3.1.5
3.1.6
3.1.7
3.1.8
3.1.9
3.1.10
3.1.11
3.1.12
3.1.13
3.1.14
3.1.15
5

6
6

Functional Specifications
7
3.1 Functional Design
7
3.1.1 Reference the existing WRICEF 7
3.1.2 Real Time / Batch / FTP and Frequency 9
3.1.3 Dependencies 9
3.1.4 Classification of Object Development
9
3.1.4.1
3.1.4.2
3.1.4.3
3.1.4.4
3.1.4.5
3.1.4.6

Reports and Forms

Interfaces
9
Conversions9
Enhancement
9
Workflows
9
WebDynpros
9

Field Validations
9
Data Sources and Selection Criteria
9
Logic Flow / Processing Required
9
Calculations / Formulae against the fields if required
Sort/Control and Report Totals 10
Output Fields/ Report Layout
10
Interactive Report/Drilldown Processing 10
Data Volume 10
Error Handling 10
Security
10
Comments
10

Business Requirements Testing

11

Technical Documentation
12
5.1 Documentation of the Development Objects
5.1.1 Overall Design Strategy 12
5.1.2 Performance Considerations
12
5.1.3 Recovery Procedures 12
5.1.4 Special Considerations / Exceptions
5.1.5 Set up / Operating Procedures 12
5.1.6 General Program Objects Created
5.1.7 SAP Objects Modified 13
5.1.8 New Development Object Attributes

12

12
12
13

Technical Documentation - Report

14
[Appendix A refers to the objects which wont be used regularly. If the type of application is not listed
here, check the appendix A and update the required information.]
14
6.1 Documentation of Report
14
6.1.1 Report Overview
14
6.1.2 Selection Screen
14
6.1.3 Data Selection 14
6.1.4 Screen Flow
15
6.2 Technical Assumptions 15
6.3 Function Group and Modules
15
6.4 Data Dictionary Objects 16
6.5 FORMS
17
6.6 Message Types 17
6.7 Message Class and Texts
18

FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master

Page 3 of 25

6.8 Pseudo Code 19

Program Structure
7

8
9

19

Error Handling, Security.

20
7.1 Documentation of Error Handling, Security.
7.1.1 Error Handling 20
7.1.2 Security
20

20

Development Unit Testing (please include the negative test cases also)
Post Production Modifications
22
9.1 <Date of Change> Change Request 9999 <brief description>

22

Appendix A Object Templates 23

FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master

Page 4 of 25

21

Attributes

System(s)
Impacted

ECC 6.0
BI 7.0

Program type:

Conversion
Enhancement
EDI

Priority

High/Mandatory

Complexity
ROM

Page 5 of 25

Low (<2wks)

EP 7.0
Other: _________________
Interface
Form
Other R/3 Dev

Report
Workflow
Legacy / Bolt-On

Medium/Recommended
Medium (3-5wks)

Rough Order of Magnitude = ______ days

Low/Optional

High (6-8wks)

Very High (>9wks)

2 Business Requirements
2.1

Overview

Warrior is an external sytem that handles the Accounts Receivable aging and cash
application functionality for all the OneSAP Lear plants. It is required to capture the Warrior
Customer Number in SAP on the customer master record of the corresponding sold-to/bill-to
customers. This field will serve as a cross reference when SAP transmits Accounts
Receivable (Invoices, CM/DMs, etc.) data to Warrior via an interface.
The Warrior customer number is required to be mandatory field only for the account groups
Sold-to & Bill-to customers in SAP.

2.2 Business Users (requested by)

Accounting and Corporate Warrior Team

2.3 Benefits / Alternatives/ Assumptions

Benefits:

Cross reference between Warrior and SAP Customers for required interfaces.

Alternatives:

None.

Assumptions:

Only one customer number exists in warrior for each sold-to or bill-to in SAP.
The Warrior customer number is a 14 char value.

2.4 Comments

2.5 Related Documents (Ref BPDD No.)

http://ssd-eu/na/erp_project/NA/300_SD/SD/BPDDs/SD001_Customer%20Master%20Data.docx

Page 6 of 25

3 Functional Specifications
3.1 Functional Design
A custom field will be added to the customer master general data. This field will be populated with the
Warrior Customer number on the corresponding sold-to/bill-to customers in SAP.
Development Task:
Create an enhancement to add the custom field on the customer master General Data tab. This field will
be mandatory.

Screen Field Name

Warrior Customer No.

Field Title

ZSDWARRIOR

T
y
p
e
*

Size

14

Mandatory

Wild

Range

Cards?

Required?

Yes
Conditional
(See below)

SAP Source Field

Zsdwarrior

Check for the account group of the customer in table KNA1 if it is a sold-to or bill-to.
o If KNA1-KTOKD = Z001 or Z004, then make this entry as mandatory else optional.
Always make the value in the field right justified with leading zeroes. Example below.
Ex: User enter 123456789, update the field as 00000123456789
User enters 00000123456789, do nothing.

3.1.1 Reference the existing WRICEF

The Warrior Customer Number will be maintained in the customer master general data under Warrior No task icon.
Sample screen shown below.

Page 7 of 25

table 3-1

If T Code exist, please specify below.

Transaction Code (Existing
Report)

Report Name

New Transaction Code

XD01, XD02

3.1.2 Real Time / Batch / FTP and Frequency

This field gets populated with the Warrior Customer Number via the initial customer master upload and
also on an ad-hoc basis post go-live.

3.1.3

Dependencies
None

3.1.4

Classification of Object Development

3.1.4.1

Reports and Forms

N/A

3.1.4.2

Interfaces
N/A

3.1.4.3

ConversionsN/A

Page 8 of 25

3.1.4.4

Enhancement

3.1.4.5

Workflows
N/A

3.1.4.6

3.1.5

WebDynpros

Field Validations
There will be no validation of this field in SAP. User may enter any value.

3.1.6

Data Sources and Selection Criteria

3.1.7 Logic Flow / Processing Required

N/A
3.1.8 Calculations / Formulae against the fields if required
N/A
3.1.9 Sort/Control and Report Totals
N/A
3.1.10Output Fields/ Report Layout
N/A
3.1.11Interactive Report/Drilldown Processing
N/A
3.1.12Data Volume
N/A
3.1.13Error Handling
3.1.14Security
N/A
3.1.15 Comments
N/A

Page 9 of 25

4 Business Requirements Testing

Detail the specific business scenarios that should be tested as a part of this Development. Detail what the
expected result of each scenario is.

Business Test Scenario

Page 10 of 25

Expected Result

5 Technical Documentation
5.1

Documentation of the Development Objects

5.1.1

Overall Design Strategy

This is a object needs to be enhanced on customer master transaction screen.

5.1.2

Performance Considerations
Note here anything that may impact on the performance of the program or which is
relevant to performance in general. If a particular option to improve performance was
considered, yet proved ineffective, describe this here. This will ensure that other
programmers do not waste time going down the same track at a later date. Use the
runtime analysis and SQL trace features of SAP to check and compare the performance of
the program.

5.1.3

Recovery Procedures
This section MUST be completed. It is most important for any programs that update SAP.
Outline the procedure that must be followed in the even of program failure {Example:
what happens if the program terminates or is cancelled midway through?}. Recovery
Procedures must also be added to on-line documentation. If the program is just a report,
simple state that This program is only a report and can be cancelled during processing if
required

5.1.4

Special Considerations / Exceptions

List anything that should be taken into consideration when executing this program. Eg.
report cannot be run in background, screen size must be set to a special size, hard
coding of values etc.

5.1.5

Set up / Operating Procedures

Describe how the development should be run. Describe any procedures that must be
completed before running the program and any general cautions and warnings that apply
to the task.

5.1.6

General Program Objects Created

Document all objects that you created for this Development. If the SAP Object type is not
included in the table below, add in a new row. Some additional objects that may need to
be added include Searchhelps, Lock Objects, Enhancement Project Names, Number
Ranges, GUI Titles, Parameter IDs, Data Elements and Domains. To obtain a complete
list of the objects you created, look in the object list of the transport.

Page 11 of 25

SAP Objects

Name

Description

Programs
Include Files
Functions
Layout Set
Menus
Transaction Code
Tables
Structures
View
Authorization
Object Used

5.1.7

SAP Objects Modified

General Information

Description

Object Name
Object Type
Object Description
Purpose
Description of Change
Add additional entries depending on the
object created

5.1.8

New Development Object Attributes

Data Descriptions: Describe the attributes of programming objects such as reports, functions, and ABAP OO, etc.
and attributes of data dictionary objects such as tables, structures, domains, data elements, etc. and changes to the
existing repository objects. If you have multiple objects of one type than copy the appropriate table as many times as
needed.

Please refer to the object templates in the Object Templates for Programs, Forms, Transactions,
Screens, GUI Title, Screen Status, Function Group, Function Module, ABAP Class, ABAP Method,
Message Class, LSMW, Tables and Structures, Views, Domains, Data Elements, Lock Objects,
Search Helps, and many other objects.

Page 12 of 25

6 Technical Documentation - Report

[Appendix A refers to the objects which wont be used regularly. If the type of application is not listed here,
check the appendix A and update the required information.]

6.1

Documentation of Report
6.1.1

Report Overview
REPORT SECTION:

For Report Only

Provide all requested information and check all attributes that apply
Name of Report:
Assigned Transaction:
Interactive Report:

Yes

No

Report Layout:

No

Yes Filename:______________

Run Mode:

Foreground

The report will be created via:

Report Painter
ABAP Program

Data Volume (Records):

6.1.2

Background
Report Writer
Info System

Both
ALV
Other: __________

Date test data is to become available:

Selection Screen

Selection Screen: Describe the selection screen of the program. Specify fields for selection and what
checks are needed after the user has entered their criteria
Screen Name/Number
Select Options /
Parameters / Radio
Buttons/ Check Boxes

Field name

Default Values
From To

Validation
(Required / Optional)

Note: All the selection screen fields should be checked against the check tables where exist. Also, make
sure if it has F1 help. If not, make sure to verify with Functional team if any process on help required.
6.1.3

Data Selection

Data Selection: Identify the data the report should select only. Remaining pseudo code should be
written in section 6.1.6 Include tables, join conditions, etc.

Page 13 of 25

6.1.4

Screen Flow

Screens and Screen Flow: Describe the screens and the screen flow. Insert screen prints and flow of
screens, if applicable. This is important when you have an interactive report that allows you to see the
report from different angles and different hierarchy levels.

6.2 Technical Assumptions

1.3 Technical Assumptions: Describe special issues and assumptions, which might impact the overall
design or implementation of the software. Include any business product line considerations that will
impact the manner in which the software is to be designed, implemented or tested.

6.3 Function Group and Modules

This should be 6.2
Function Group Attributes: Provide relevant attributes for function group
Name
Description
Development Package

Function Module Attributes: Provide relevant attributes for the function module
Name
Function Group
Description
Processing Type
Update mode (if
applicable)
Import Parameters: Provide the required attributes for functions import parameters. Insert more lines into
table when needed

Page 14 of 25

Parameter
Name.

Typing

Associated
Type

Default
Value

Optional
(Y/N)

Pass
Value
(Y/N)

Description

Note: Specify the parameters starting im_ ex_, t_ for import, export and tables parameters.

BADIs or Enhancements

OO ABAP ClassUserExit Attributes: Provide relevant attributes for the OO ABAP Class/Interface
Name
Description
Development Package
Interface

Yes

No

Final

Yes

No

Only Modeled?

Yes

No

Instantiation
Class Type

Super Class
Interface: Provide the required attributes for class interface definitions. Insert more lines into table when
needed
Interface

Abstract
(Y/N)

Final
(Y/N)

Modeled
only
(Y/N)

Description

Enhancements: Provide the required information for User Exits.

Enhancement Function
Module

Type

Project

Description

6.4 Data Dictionary Objects

Table/Structure Attributes:
Name:

ZZWARRIOR1

Short Text:

Warrior Number

Type
Development Package
Delivery Class:
Page 15 of 25

Transparent
Structure
ZSDPK

Pooled
APPEND

Cluster
CI Customer include

Table Maintenance:
Data Class:
Size:
Buffering:
Table Locking:
Authorization Group:
Tables and Structures Fields: The following structure will be appended to KNA1 table.
Table/Structure:

Expected Size:

Field Name

Data Element

ZZWARRIOR_NO

ZWARRIORC

Domain

Description (Change, Add,

Delete, Key, etc)

ZWARRIOR

6.5 FORMS

Form Attributes: Provide relevant attributes based on form type

Name
Description
Development Package
Page Format:

DIN A4

Letter

Other ________________

Languages

English

French

Other ________________

6.6 Message Types

OO ABAP ClassUserExit Attributes: Provide relevant attributes for the OO ABAP Class/Interface
Name
Description
Development Package

6.7 Message Class and Texts

Message Class Attributes: Provide relevant attributes for the message class
Message Type
Idoc Type
enhancement of
segments
Page 16 of 25

Inbound/Outbound
Partner Type
Receiving & Sending
System
Process Code
Change Pointers (if
applied any)
Customer Distribution
Model
Filters (if created any)
Specify the field &value

6.8

Pseudo Code

Program Structure
Program Structure and processing pseudo-code (if required): Describe the program structure and how
it selects, processes, and outputs the data. (Add additional rows to table if text becomes too long or to
separate different development objects)
1.

Create the structure ZWARRIOR1 and append to the table KNA1 with field zzwarrior_no with the data
element ZWARRIORC and with the domain ZWARRIOR,which has the length of 14 character size.
2. Create a new custom Customer Screen Group with name SK under SPRO-logistics general-Business
Partners-Customers-Adoptations of Customers Own Master Data fields- Prepare Modification-Free
Enhancement of Customer Master Record.
3. Assign the screen no. as 65.
4. Implement the BADI CUSTOMER_ADD_DATA with name ZCUSTOMER_ADD_DATA and
CUSTOMER_ADD_DATA_CS with name ZCUSTOMER_ADD_DATA_CS (this is for customer
subscreen).
5. Implement and activate the methods for the above two BADIs.
6. While implement, create the filter with value SK and filter group as CUST_SCGR.
7. Create the function group ZWARRIOR and assign screen 9001 to the function group. Create the
screen as subscreen.
8. In screen 9001, insert the field KNA1-ZZWARRIOR_NO.
9. In PBO module of screen 9001, get the value of input from screen and assign the value to
ZZWARRIOR_NO.
Assign (C_WARRIOR_NO ) to <fse>.
KNA1-ZZWARRIOR_NO = <fse>.
10. Also, modify the screen group to display if the transaction code is in display mode.
Get the activity category of the transaction and assign the value to V_AKTYP.
Assign (C_AKTYP) to <fse_aktyp>.
V_AKTYP = <fse_aktyp>.
If v_aktyp = A.
Page 17 of 25

11.
12.

13.

14.

Loop at screen.
If screen group = PSK.
Screen-input = 0.
Modify screen.
Endif.
Endloop.
Endif.
In PAI module of screen 9001, create a module validate_warriorno in PAI to make sure the valid entry
exist for customer group z001 or z004.
In BADI implementation ZCUSTOMER_ADD_DATA_CS, modify the following methods:
In method GET_DATA, pass the screen value to s_kna1-zzwarrior_no and make the value of
s_kna1-zzwarrior_no as right justified with leading zeroes.
v_length = strlen ( s_kna1-zzwarrior_no ).
If v_length < 14.
v_offset = 14 v_length.
v_temp = s_kna1-zzwarrior_no.
clear s_kna1-zzwarrior_no.
unpack s_kna1-zzwarrior_no to s_kna1-zzwarrior_no.
s_kna1-zzwarrior_no+v_offset(v_length) = v_temp.
clear v_length, v_offset, v_temp.
Endif.
In method GET_TAXI_SCREEN, define the screen name and number when function code is
SK_TAB.
Case i_taxi_fcode.
When sk_tab.
e_screen = 9001.
e_program = SAPLZWARRIOR.
e_headerscreen_layout = V.
endcase.
In BADI implementation ZCUSTOMER_ADD_DATA, implement the method
CHECK_ADD_ON_ACTIVE.
If screen group is SK then e_add_on_active = X.
In user exit EXIT_SAPMF02D_001, to make sure the valid entry exists for warrior number field for the
customer groups Z001 or Z004.
If i_kna1-ktokd eq Z001 or
I_kna1-ktokd eq Z004.
If i_kna1-zzwarrior_no is initial.
Message Warrior No. is mandatory. Please input
Endif.
Endif.

Run Procedure: Describe how to run the applicatio such as which transaction to call, which variant to
use, special considerations for the selection screen, etc.

Page 18 of 25

Restart Procedure: Describe how to restart the application in case it fails to run successfully

Page 19 of 25

7 Error Handling, Security.

7.1

Documentation of Error Handling, Security.

7.1.1

Error Handling

Error Handling: Describe the scenarios where processing errors can occur and how they should be
handled
1.

To ensure the valid warrior number entry exists for the customer groups Z001 or Z004.
In user exit EXIT_SAPMF02D_001,
If i_kna1-ktokd eq Z001 or
I_kna1-ktokd eq Z004.
If i_kna1-zzwarrior_no is initial.
Message Warrior No. is mandatory. Please input
Endif.
Endif.

7.1.2

Security

Security Details: Describe processing required to address Security Requirements defined in the
Functional Specification.
Security checks are not required for this enhancement since this functionality will be called with the standard
transaction codes. Who ever have access to these transaction codes can only execute this logic implicitly.

Page 20 of 25

8 Development Unit Testing (please include the negative test cases also)
Test Scenario Description

Expected Result

Validate the custom field

(Warrior Customer
Number)will be added to the
customer master general data
and will be populated with the
warrior customer number.

The custom field (Warrior

Customer Number)should be
added in the customer master
general data under Warrior No
task icon and the value of the
field have to be maintain
(create, update and populate)
as per the transaction activity.

Pass

validate the Warrior Customer

Number for the customer
account group is Z001 or Z004

Error message should occur as

Warrior No. is mandatory. please
input, if the warrior customer
number entry is not maintained for
the customer account groups Z001
or Z004.

Pass

validate the value of the

warrior customer number field
is right justified with leading
zeroes

The value in the field have to be

right justified with leading
zeroes

Pass

Page 21 of 25

Pass /
Fail

Comments

9 Post Production Modifications

9.1

<Date of Change> Change Request 9999 <brief description>

Client Contact: <Name of person who requested the change.>

Provide details of exactly what the change was and how it affects the program.

Page 22 of 25

Appendix A Object Templates

Program Attributes: Provide relevant program attributes
Name
Description
Logical Database
Development Package
Editor Lock

Yes

No

Start using variant;

Yes

No

Fixed Point Arithmetic:

Yes

No

Unicode

Yes

No

Master Data

____________________ Master data rep. class

Payroll Cluster

____________________ Payroll report category

HR Report Category
(if applicable)

or

Transaction Attributes: Provide relevant attributes based on transaction type

Name
Description
Development Package
Type
Program/Transaction
Screen Number
Variant
Class
Method
Update mode
Classification
GUI Support
Default Values
Describe other attributes

Screen Attributes: (Provide a description of each screen include fields, possible User actions and any
Processing that should happen)
Program Name
Description
Development Package
Screen Type
Field Definition:

Page 23 of 25

Screen
No.

Field
Name

Type(Field,
Push Button,
Or Table Control)

Field
Text

Format

Input
Masks

List of Possible
Values and
Context
Sensitive Help

Validation
Error
Actions

Screen Logic PBO Provide the modules needed for the process before output. Do not provide the coding
here, but the steps that need to be performed such as Set GUI STATUS and TITLE, Initialize Data, etc.

Screen Logic PAI Provide the modules needed for the process after input. Do not provide the coding here, but
the steps that need to be performed such as Verify Input, Process OK-Code, etc.

Screen GUI Title: Provide relevant GUI Title attributes for the screen
Program Name
Title Code
Description

Screen Status: Provide relevant attributes for Screen Status

Program Name
Status Name
Description
Status Type
Menu Bar: Provide the menu list and sub-menu with the corresponding menu items. If for a menu item you
have a sub-menu, then write first the main menu, then sub-menu and as function code write SUB. For the
sub-menu write the sub-menu, then the menu item, and then the function code representing the menu item
Menu/Sub-menu

Sub-menu/Menu
Item

Function Code

Description

Application Toolbar: Provide the required attributes for application toolbar items. Insert more lines into table
when needed
Item Number

Function Code

Description

Function Keys: Provide the required attributes for application toolbar items
Function Key

Page 24 of 25

Function Code

Description

LSMW Attributes: Provide relevant attributes for the LSMW

Name
Description
Lock Object Attributes: Provide relevant attributes for the lock object
Name
Description
Development Package
Primary Table:
Primary Lock Mode
Secondary Lock Tables: Provide information about secondary tables
Name

Lock Mode

Lock Parameters: Provide information about the lock parameters

Lock Parameter wanted

Lock Parameter Name

Table

Field

Search Help Attributes: Provide relevant attributes for the search help
Name
Description

Page 25 of 25