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 FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master

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

Document Revision History

Document Revision Date Author Revision Description

Version #

1.0

Functional Specification Acceptance Sign-off

Role: Name: Signature/Electronic Reference Date

Business Process
Owner/ Requestor
Functional Team
Lead
Technical Lead
PMO

FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master Page 2 of 25

 Table of Contents

1 Attributes 5
2 Business Requirements 6
2.1 Overview 6
2.2 Business Users (requested by) 6
2.3 Benefits / Alternatives/ Assumptions 6
2.4 Comments 6
2.5 Related Documents (Ref BPDD No.) 6
3 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 Reports and Forms 9
3.1.4.2 Interfaces 9
3.1.4.3 Conversions- 9
3.1.4.4 Enhancement 9
3.1.4.5 Workflows 9
3.1.4.6 WebDynpros 9
3.1.5 Field Validations 9
3.1.6 Data Sources and Selection Criteria 9
3.1.7 Logic Flow / Processing Required 9
3.1.8 Calculations / Formulae against the fields if required 9
3.1.9 Sort/Control and Report Totals 10
3.1.10 Output Fields/ Report Layout 10
3.1.11 Interactive Report/Drilldown Processing 10
3.1.12 Data Volume 10
3.1.13 Error Handling 10
3.1.14 Security – 10
3.1.15 Comments 10
4 Business Requirements Testing 11
5 Technical Documentation 12
5.1 Documentation of the Development Objects 12
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 12
5.1.5 Set up / Operating Procedures 12
5.1.6 General Program Objects Created 12
5.1.7 SAP Objects Modified 13
5.1.8 New Development Object Attributes 13
6 Technical Documentation - Report 14
[Appendix A refers to the objects which won’t 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

FTDS_SD_E_227_Add Warrior Customer Number to the Customer Master Page 3 of 25

 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
6.8 Pseudo Code 19
Program Structure 19
7 Error Handling, Security. 20
7.1 Documentation of Error Handling, Security. 20
7.1.1 Error Handling 20
7.1.2 Security 20
8 Development Unit Testing (please include the negative test cases also) 21
9 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

1 Attributes

System(s) ECC 6.0 EP 7.0

Impacted BI 7.0 Other: _________________
Program type: Conversion Interface Report
Enhancement Form Workflow
EDI Other – R/3 Dev Legacy / Bolt-On
Priority High/Mandatory Medium/Recommended Low/Optional
Complexity Low (<2wks) Medium (3-5wks) High (6-8wks) Very High (>9wks)
ROM Rough Order of Magnitude = ______ days

Page 5 of 25
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/DM’s, 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 Field Title T Size Mandatory Wild Range SAP Source Field
y
p Cards? Required?
e
*

Warrior Customer No. ZSDWARRIOR C 14 Yes Zsdwarrior

Conditional
(See below)

 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 Functional Specifications-1
If T Code exist, please specify below.
Transaction Code (Existing Report Name New Transaction Code
Report)

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 Conversions-

N/A

Page 8 of 25
 3.1.4.4 Enhancement

3.1.4.5 Workflows

N/A

3.1.4.6 WebDynpros

3.1.5 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 Expected Result

Page 10 of 25
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 ID’s, 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 won’t 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 Background Both
The report will be created via: Report Painter Report Writer ALV
ABAP Program Info System Other: __________

Data Volume (Records): Date test data is to become available:

6.1.2 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 / Field name Default Values Validation
Parameters / Radio From – To (Required / Optional)
Buttons/ Check Boxes

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 function’s import parameters. Insert more lines into
table when needed
Parameter Typing Associated Default Optional Pass Description
Name. Type Value (Y/N) Value
(Y/N)

Page 14 of 25
 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
Instantiation
Class Type
Final Yes No
Only Modeled? Yes No
Super Class
Interface: Provide the required attributes for class interface definitions. Insert more lines into table when
needed
Interface Abstract Final Modeled Description
(Y/N) (Y/N) only
(Y/N)

Enhancements: Provide the required information for User Exits.

Enhancement Function Type Project Description
Module

6.4 Data Dictionary Objects

Table/Structure Attributes:

Name: ZZWARRIOR1
Short Text: Warrior Number
Type Transparent Pooled Cluster
Structure APPEND CI Customer include
Development Package ZSDPK
Delivery Class:
Table Maintenance:
Data Class:
Size:
Buffering:

Page 15 of 25
 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 Domain Description (Change, Add,

Delete, Key, etc)
ZZWARRIOR_NO ZWARRIORC 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
Inbound/Outbound
Partner Type
Receiving & Sending
System
Process Code

Page 16 of 25
 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 Customer’s 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 BADI’s.
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’.
Loop at screen.
If screen group = ‘PSK’.
Screen-input = ‘0’.
Modify screen.
Endif.
Endloop.

Page 17 of 25
 Endif.
11. 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.
12. 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.
13. In BADI implementation ZCUSTOMER_ADD_DATA, implement the method
CHECK_ADD_ON_ACTIVE.
- If screen group is ‘SK’ then e_add_on_active = ‘X’.
14. 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.

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

Page 18 of 25
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
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.
validate the Warrior Customer
Number for the customer
account group is Z001 or Z004
validate the value of the
warrior customer number field
is right justified with leading
zeroes
Page 21 of 25
Expected Result Pass / Comments
Fail
The custom field (Warrior Pass
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.
Error message should occur as Pass
“Warrior No. is mandatory. please
input”, if the warrior customer
number entry is not maintained for
the customer account groups Z001
or Z004.
The value in the field have to be Pass
right justified with leading
zeroes
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
HR Report Category Master Data ____________________ Master data rep. class
(if applicable) or
Payroll Cluster ____________________ Payroll report category

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 Field Type(Field, Field Format Input List of Possible Validation
No. Name Push Button, Text Masks Values and Error
Context Actions
Or Table Control) Sensitive Help

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 Function Code Description
Item

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 Function Code Description

Page 24 of 25
 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