Reply

Re:
functional
spec
Posted: Mar 20,
2007 7:41 AM
in response
to: sandeep jain

Functional specifications (functional specs), in the end, are the blueprint for how you
want a particular report and transaction to look and work. It details what the report will
do, how a user will interact with it, and what it will look like. By creating a blueprint of
the report or transaction first, time and productivity are saved during the development
stage because the programmers can program instead of also working out the logic of the
user-experience. It will also enable you to manage the expectations of your clients or
management, as they will know exactly what to expect. A key benefit of writing up a
Functional Spec is in streamlining the development process. The developer working from
the spec has, ideally, all of their questions answered about the report or transaction and
can start building it. And since this is a spec that was approved by the client, they are
building nothing less than what the client is expecting. There should be nothing left to
guess or interpret when the spec is completed. Functional Specification A functional
specification (or sometimes functional specifications) is a formal document used to
describe in detail for software developers a product's intended capabilities, appearance,
and interactions with users. The functional specification is a kind of guideline and
continuing reference point as the developers write the programming code. (At least one
major product development group used a "Write the manual first" approach. Before the
product existed, they wrote the user's guide for a word processing system, then declared
that the user's guide was the functional specification. The developers were challenged to
create a product that matched what the user's guide described.) Typically, the functional
specification for an application program with a series of interactive windows and dialogs
with a user would show the visual appearance of the user interface and describe each of
the possible user input actions and the program response actions. A functional
specification may also contain formal descriptions of user tasks, dependencies on other
products, and usability criteria. Many companies have a guide for developers that
describes what topics any product's functional specification should contain. For a sense of
where the functional specification fits into the development process, here are a typical
series of steps in developing a software product: Requirements: This is a formal statement
of what the product planners informed by their knowledge of the marketplace and
specific input from existing or potential customers believe is needed for a new product or
a new version of an existing product. Requirements are usually expressed in terms of
narrative statements and in a relatively general way. Objectives: Objectives are written by
product designers in response to the Requirements. They describe in a more specific way
what the product will look like. Objectives may describe architectures, protocols, and
standards to which the product will conform. Measurable objectives are those that set
some criteria by which the end product can be judged. Measurability can be in terms of
some index of customer satisfaction or in terms of capabilities and task times. Objectives
must recognize time and resource constraints. The development schedule is often part or a
corollary of the Objectives. Functional specification.: The functional specification

(usually functional spec or just spec for short) is the formal response to the objectives. It
describes all external user and programming interfaces that the product must support.
Design change requests: Throughout the development process, as the need for change to
the functional specification is recognized, a formal change is described in a design change
request. Logic Specification: The structure of the programming (for example, major
groups of code modules that support a similar function), individual code modules and
their relationships, and the data parameters that they pass to each other may be described
in a formal document called a logic specification. The logic specification describes
internal interfaces and is for use only by the developers, testers, and, later, to some extent,
the programmers that service the product and provide code fixes to the field. User
documentation: In general, all of the preceding documents (except the logic specification)
are used as source material for the technical manuals and online information (such as help
pages) that are prepared for the product's users. Test plan: Most development groups have
a formal test plan that describes test cases that will exercise the programming that is
written. Testing is done at the module (or unit) level, at the component level, and at the
system level in context with other products. This can be thought of as alpha testing. The
plan may also allow for beta test. Some companies provide an early version of the
product to a selected group of customers for testing in a "real world" situation. The Final
Product: Ideally, the final product is a complete implementation of the functional
specification and design change requests, some of which may result from formal testing
and beta testing. The cycle is then repeated for the next version of the product, beginning
with a new Requirements statement, which ideally uses feedback from customers about
the current product to determine what customers need or want next. Most software
makers adhere to a formal development process similar to the one described above. The
hardware development process is similar but includes some additional considerations for
the outsourcing of parts and verification of the manufacturing process itself. Hope the
above helps you.
Re:
functional
spec and its
preparation

Reply

Posted: Jun 30,

2008 5:56 AM
in response
to: purna chandra

Functional Specification Document (FSD) is a document to determine and define the

business process of the area discussed. Depending on how SAP is implemented in your
organization, FSD format may differs for reports, enhancement, interface or forms.
FSD should be reviewed by the business owner. Once agreed, FSD should be forwarded
to the programmer to start the development of the business process. This is the reason
why FSD should be detail, comprehensive and technical enough so that the programmer
can understand the whole requirement and coding can be easily developed.
A standard FSD format should include:
- Title of the business process
- Version history

- Complexity
- Detail user requirement
- Pre-requisite and assumption
- Process flow diagram
- Enhancement screen (if any)
- Output layout
- Field and table description (which table/field to insert, update or delete)
- Input and output parameters
- Error handling
- Testing requirement
TQ,
pecs), in the end, are the blueprint for how you want a particular report and
transaction to look and work. It details what the report will do, how a user will
interact with it, and what it will look like. By creating a blueprint of the report or
transaction first, time and productivity are saved during the development stage
because the programmers can program instead of also working out the logic of the
user-experience. It will also enable you to manage the expectations of your clients or
management, as they will know exactly what to expect.
A key benefit of writing up a Functional Spec is in streamlining the development
process. The developer working from the spec has, ideally, all of their questions
answered about the report or transaction and can start building it. And since this is a
spec that was approved by the client, they are building nothing less than what the
client is expecting. There should be nothing left to guess or interpret when the spec
is completed.
Functional Specification
A functional specification (or sometimes functional specifications) is a formal
document used to describe in detail for software developers a product's intended
capabilities, appearance, and interactions with users. The functional specification is a
kind of guideline and continuing reference point as the developers write the
programming code. (At least one major product development group used a "Write
the manual first" approach. Before the product existed, they wrote the user's guide
for a word processing system, then declared that the user's guide was the functional
specification. The developers were challenged to create a product that matched what
the user's guide described.) Typically, the functional specification for an application
program with a series of interactive windows and dialogs with a user would show the
visual appearance of the user interface and describe each of the possible user input
actions and the program response actions. A functional specification may also
contain formal descriptions of user tasks, dependencies on other products, and
usability criteria. Many companies have a guide for developers that describes what
topics any product's functional specification should contain.
For a sense of where the functional specification fits into the development process,
here are a typical series of steps in developing a software product:
Requirements:
This is a formal statement of what the product planners informed by their knowledge
of the marketplace and specific input from existing or potential customers believe is
needed for a new product or a new version of an existing product. Requirements are
usually expressed in terms of narrative statements and in a relatively general way.

Objectives: Objectives are written by product designers in response to the

Requirements. They describe in a more specific way what the product will look like.
Objectives may describe architectures, protocols, and standards to which the product
will conform. Measurable objectives are those that set some criteria by which the end
product can be judged. Measurability can be in terms of some index of customer
satisfaction or in terms of capabilities and task times. Objectives must recognize time
and resource constraints. The development schedule is often part or a corollary of
the Objectives.
Functional specification.: The functional specification (usually functional spec or just
spec for short) is the formal response to the objectives. It describes all external user
and programming interfaces that the product must support.
Design change requests: Throughout the development process, as the need for
change to the functional specification is recognized, a formal change is described in a
design change request.
Logic Specification:
The structure of the programming (for example, major groups of code modules that
support a similar function), individual code modules and their relationships, and the
data parameters that they pass to each other may be described in a formal
document called a logic specification. The logic specification describes internal
interfaces and is for use only by the developers, testers, and, later, to some extent,
the programmers that service the product and provide code fixes to the field.
User documentation:
In general, all of the preceding documents (except the logic specification) are used
as source material for the technical manuals and online information (such as help
pages) that are prepared for the product's users.
Test plan: Most development groups have a formal test plan that describes test
cases that will exercise the programming that is written. Testing is done at the
module (or unit) level, at the component level, and at the system level in context
with other products. This can be thought of as alpha testing. The plan may also allow
for beta test. Some companies provide an early version of the product to a selected
group of customers for testing in a "real world" situation.
The Final Product:
Ideally, the final product is a complete implementation of the functional specification
and design change requests, some of which may result from formal testing and beta
testing. The cycle is then repeated for the next version of the product, beginning
with a new Requirements statement, which ideally uses feedback from customers
about the current product to determine what customers need or want next.
Most software makers adhere to a formal development process similar to the one
described above. The hardware development process is similar but includes some
additional considerations for the outsourcing of parts and verification of the
manufacturing process itself.
Read more: SAP F

Pages: 1

Back to Thread List

unctional Specific

Re:
Functional
Specification
Documents for
SAP Sales and
Distribution
Posted: May 20,
2010 9:14 AM
response
to: Abhishek

Reply

in

Hi there,
1st try to understand what is a functional specification doc before asking for it.
Functional specs is a doc in which you include what is the business requirement. If it
requires a change to change to existing configs / code, then you will give the progs & the
location where you will need to change. If the requirement is a totally new one, then yuo
will explain the requirement in detail & possibly give the progs / code if there are any.
In your case, your client has a specific invoice format which is different from which SAP
gives, in such cases, you will need to define a new Invoice output for eg ZINV. Define it
as a print output. You will need to define a new print prog for the new output in which
you will call smart forms to define the layout & fields.
Ask your business user to send the invoice copy which he has. Scan it & include it in the
functional specs which you prepare. Mention all the fields which you want in the layout.
Ask the ABAPer to code the invoice format in the same way. ABAPer is free to define
any convinent name as per the guidelines (which he will be aware). You will need to
assign that in the form routines of the output.
As a functional consultant you will need to give the field mappings (from where you get
the data) for all the fields which you wish to print in the output. All that should be
included in the func specs.
So there is no standard func specs that you can follow. Each func specs varies on the
requirement. So dont ask these kind of questions in SDN forum. If you dont know how to
define func specs, ask how to define. Dont ask people to send the sample func specs.
Thats against the rules of conduct.
Regards,
Sivanand
Re:
Functional
Specification

Reply

Posted: Nov 30,

2006 4:33 PM
in response
to: sourav bhaumik

check sap sd flow...u will understand everything abt specifications...

SD Process Flow:
The sales documents you create are individual documents but they can also form part of a

chain of inter-related documents. For example, you may record a customers telephone
inquiry in the system. The customer next requests a quotation, which you then create by
referring to the inquiry. The customer later places an order on the basis of the quotation
and you create a sales order with reference to the quotation. You ship the goods and bill
the customer. After delivery of the goods, the customer claims credit for some damaged
goods and you create a free-of-charge delivery with reference to the sales order. The
entire chain of documents the inquiry, the quotation, the sales order, the delivery, the
invoice, and the subsequent delivery free of charge creates a document flow or history.
The flow of data from one document into another reduces manual activity and makes
problem resolution easier. Inquiry and quotation management in the Sales Information
System help you to plan and control your sales.
Transaction Codes:
Inquiry - VA11/VA12/VA13
Quotation - VA21/VA22/VA23
Sales Order - VA01/VA02/VA03
Delivery - VL01N/VL02N/VL03N
Billing/Invoicing - VF01/VF02/VF03
ations - Wikipedia NewForum

Re: functional spec

Posted: Mar 20, 2007 7:41 AM
response to: sandeep jain

Reply
in

Functional specifications (functional specs), in the end, are the blueprint for how you
want a particular report and transaction to look and work. It details what the report will
do, how a user will interact with it, and what it will look like. By creating a blueprint of
the report or transaction first, time and productivity are saved during the development
stage because the programmers can program instead of also working out the logic of the
user-experience. It will also enable you to manage the expectations of your clients or
management, as they will know exactly what to expect. A key benefit of writing up a
Functional Spec is in streamlining the development process. The developer working from
the spec has, ideally, all of their questions answered about the report or transaction and
can start building it. And since this is a spec that was approved by the client, they are
building nothing less than what the client is expecting. There should be nothing left to
guess or interpret when the spec is completed. Functional Specification A functional
specification (or sometimes functional specifications) is a formal document used to
describe in detail for software developers a product's intended capabilities, appearance,
and interactions with users. The functional specification is a kind of guideline and
continuing reference point as the developers write the programming code. (At least one
major product development group used a "Write the manual first" approach. Before the
product existed, they wrote the user's guide for a word processing system, then declared
that the user's guide was the functional specification. The developers were challenged to
create a product that matched what the user's guide described.) Typically, the functional
specification for an application program with a series of interactive windows and dialogs
with a user would show the visual appearance of the user interface and describe each of
the possible user input actions and the program response actions. A functional
specification may also contain formal descriptions of user tasks, dependencies on other

products, and usability criteria. Many companies have a guide for developers that
describes what topics any product's functional specification should contain. For a sense of
where the functional specification fits into the development process, here are a typical
series of steps in developing a software product: Requirements: This is a formal statement
of what the product planners informed by their knowledge of the marketplace and specific
input from existing or potential customers believe is needed for a new product or a new
version of an existing product. Requirements are usually expressed in terms of narrative
statements and in a relatively general way. Objectives: Objectives are written by product
designers in response to the Requirements. They describe in a more specific way what the
product will look like. Objectives may describe architectures, protocols, and standards to
which the product will conform. Measurable objectives are those that set some criteria by
which the end product can be judged. Measurability can be in terms of some index of
customer satisfaction or in terms of capabilities and task times. Objectives must recognize
time and resource constraints. The development schedule is often part or a corollary of the
Objectives. Functional specification.: The functional specification (usually functional
spec or just spec for short) is the formal response to the objectives. It describes all
external user and programming interfaces that the product must support. Design change
requests: Throughout the development process, as the need for change to the functional
specification is recognized, a formal change is described in a design change request.
Logic Specification: The structure of the programming (for example, major groups of
code modules that support a similar function), individual code modules and their
relationships, and the data parameters that they pass to each other may be described in a
formal document called a logic specification. The logic specification describes internal
interfaces and is for use only by the developers, testers, and, later, to some extent, the
programmers that service the product and provide code fixes to the field. User
documentation: In general, all of the preceding documents (except the logic specification)
are used as source material for the technical manuals and online information (such as help
pages) that are prepared for the product's users. Test plan: Most development groups have
a formal test plan that describes test cases that will exercise the programming that is
written. Testing is done at the module (or unit) level, at the component level, and at the
system level in context with other products. This can be thought of as alpha testing. The
plan may also allow for beta test. Some companies provide an early version of the product
to a selected group of customers for testing in a "real world" situation. The Final Product:
Ideally, the final product is a complete implementation of the functional specification and
design change requests, some of which may result from formal testing and beta testing.
The cycle is then repeated for the next version of the product, beginning with a new
Requirements statement, which ideally uses feedback from customers about the current
product to determine what customers need or want next. Most software makers adhere to
a formal development process similar to the one described above. The hardware
development process is similar but includes some additional considerations for the
outsourcing of parts and verification of the manufacturing process itself. Hope the above
helps you.
Re:
Functional
Specifiation

Reply

SD
Posted: Nov 10,
2009 9:30 AM
in response
to: saparvind

Hi,
Normally Functional specification is for any new development.
for Ex. if u have to create Sales Register then u have to given fuction specification
related to that new report as per customer required.
In the Functional specification u have to give the inputs to abaper related to new
development,like field name,table name,logic..etc.
Functional Specification
A functional specification (or sometimes functional specifications) is a formal document
used to describe in detail for software developers a product's intended capabilities,
appearance, and interactions with users. The functional specification is a kind of
guideline and continuing reference point as the developers write the programming code.
(At least one major product development group used a "Write the manual first"
approach. Before the product existed, they wrote the user's guide for a word processing
system, then declared that the user's guide was the functional specification. The
developers were challenged to create a product that matched what the user's guide
described.) Typically, the functional specification for an application program with a
series of interactive windows and dialogs with a user would show the visual appearance
of the user interface and describe each of the possible user input actions and the program
response actions. A functional specification may also contain formal descriptions of user
tasks, dependencies on other products, and usability criteria. Many companies have a
guide for developers that describes what topics any product's functional specification
should contain.
Thanks,
PM
Guest

Re:
Functional
Specifiation
SD

Reply

Posted: Nov 10,

2009 10:02 AM
in response
to: saparvind

Hi,
FUNCTIONAL SPECIFICATIONS means you have to give
the COMPREHENSIVE DOCUMENT of your requirement
with logic

It will brief the requirement and its design how the Object
( such as INVOICES) should work
I will brief by an illustration..
Let say you are working on the requirements of INVOICE
LAYOUTS from Fnctional specifications and you have all
the Desing of Layout .
You have to tell ABAPer on how to fetch the Data from
different field and the Logic for retrieving the Data from
Tables.
for example if you want to print the ACCOUNTING
DOCUMENT number on the invoice , you have to tell
him to fetch the Sales order number from the VBAK
-VBELN and goto VBFA to get the Billing document
number and now goto the Table
VBRK-BELNR to get the accounting docu
Re:
Functional
Specifiation
SD

Reply

Posted: Nov 10,

2009 9:30 AM
in response
to: saparvind

Hi,
Normally Functional specification is for any new development.
for Ex. if u have to create Sales Register then u have to given fuction specification
related to that new report as per customer required.
In the Functional specification u have to give the inputs to abaper related to new
development,like field name,table name,logic..etc.
Functional Specification
A functional specification (or sometimes functional specifications) is a formal document
used to describe in detail for software developers a product's intended capabilities,
appearance, and interactions with users. The functional specification is a kind of
guideline and continuing reference point as the developers write the programming code.
(At least one major product development group used a "Write the manual first"
approach. Before the product existed, they wrote the user's guide for a word processing
system, then declared that the user's guide was the functional specification. The
developers were challenged to create a product that matched what the user's guide

described.) Typically, the functional specification for an application program with a

series of interactive windows and dialogs with a user would show the visual appearance
of the user interface and describe each of the possible user input actions and the program
response actions. A functional specification may also contain formal descriptions of user
tasks, dependencies on other products, and usability criteria. Many companies have a
guide for developers that describes what topics any product's functional specification
should contain.
Thanks,
PM
Re:
Functional
Specifiation
SD

Reply

Posted: Nov 10,

2009 10:56 AM
in response
to: saparvind

Hi,
For which object you want to prepare a FS(Functional
specification).Is it for Interface/Report/Forms/Extensions.
I will give you an example of preparing the FS for a report.
The FS should be as per the format given by your business.
It has the following sections:
1.Document Summary-What is this report and Necessity of
going for this report.
2.Dependencies / Constraints-What are the dependencies on this
object.
3.Assumptions-Mention the assumptions if present for this
object.
4.Processing Information-Mention the processing information
like frequency of using this object Report delivery and print
options etc....
5.Audience and Access Restriction-This section tells about the
users who are going to use this object.
6.Functional Specification-This is the main section in the FS.It

tells about the object indetail like what is the change and why
this change.
7.Report Layout-Layout for this new "Z" report.
8.Report fields-Mention all the fields required for you in using
this report and give the detailed logic for each and every field.
9.Selection criteria-What the fields on Selection screen etc.Here
you have provide which field is to be mandatory and for which
one you need the F4 help.
10.Interactive Capabilities / Jump Targets
11.Existing Sample Reports
12.Technical Test Conditions
13.Testing Considerations/Dependencies
14.Issues and Remarks.
Like this we have to create a FS.
Regards,
Krishna.

Re:
Functional
specs

Reply

Posted: Feb 5,
2008 10:37 AM
in response
to: Ashwath
Reddy

Func Spec basically contains the information about the business process which needs to
be mapped on to the IT system (SAP). It encompasses all the related function points
which will be part of the business process.
It also mentions the programs or utilities which can be enhanced/modified/copied to

achieve the end result (in case the functional consultant is aware of the program/utility)
Function Specs is a document which a functional consultant prepares to be given to
Abaper. This Document contains details like Tables & fields name, Table joints, Logic for
development, along with test case in sand box / test server to verify the development.
Format for Functional Specs:
Document Control
Change History
Issue No
Date
Name
Change
Initial Draft
Authorizations
Role
Name
Signed
Date
Business Process Lead (customer)
Functional Analyst (specification author)
Technical Lead
Developer (if known)
Select program type below and then use menu option tools > unprotect to
open other fields for input
Type
Table of Contents
Document Control 1
Overview. 3
1.1 Short Description. 3

1.2 Business Process. 3

1.3 Terminology. 3
1.4 New Custom Objects Required. 3
1.5 Impacted SAP Transactions/Tables. 4
Process Decomposition. 5
2.1 Process Flow. 5
2.2 New Tables/Structures Required. 5
2.3 Sub-Process Description. 5
2.4 Error Handling. 5
2.5 Security Considerations. 5
2.6 Database Considerations. 5
2.7 Conversion Implications. 5
2.8 Batch Processing. 6
2.9 Functional Test Requirements. 6
Overview
1.1 Short Description
1.2 Business Process
1.3 Terminology
1.4 New Custom Objects Required
Include all new tables, key new fields/domains, new lock objects, new
match-codes, new transaction codes, new authorization objects, new
function groups, reports and module pools (transaction programs). Don't
specify all includes, function modules, routines etc. here.
Type (table, transaction etc.)

Description
Naming convention
1.5 Impacted SAP Transactions/Tables
List SAP objects updated/impacted by this specification (do not include
read only impacts)
Object(s)
Type (table, transaction etc.)
Description of Impact
Process Decomposition
2.1 Process Flow
2.2 New Tables/Structures Required
Specify new tables and structures required. If appropriate, you may
defer detailed field list/specification to the technical specification
(e.g. for secondary tables and structures).
Table id
Description
Type
Master, transaction, customizing, staging
Expected size
Maint. dialog
None, SM30, custom
Fields
Key
Domain/data element names
Domain format (if new)

Description
2.3 Sub-Process Descriptio
2.4 Error Handling
Specify what to do if a condition passes AND fails (e.g. - what happens if a customer
record is found, or is not found). Specify messages and type.
Specify any special error logging or table storage, including use of standard application
log where appropriate.
Field
Validation
Message type/no.
Message text
2.5 Security Considerations
2.6 Database Considerations
2.7 Conversion Implications
2.8 Batch Processing
2.9 Functional Test Requirements
Consider all the conditions that need testing for this enhancement and document below.
For each logic branch in theory both (or more) conditions of the branch should be tested.
For each scenario that could impact program execution, all situations must be tested.
No.
Test condition
Expected result
Data set-up reqt.
Dependencies
Re:
Functional

Reply

specs
Posted: Feb 5,
2008 10:06 AM
in response
to: Ashwath
Reddy

Here i am explaining what is functional specs and what are the contents of it.
Functional Specs:
To speak at macro level that is at project manager or at senior levels. The Functional Spec
(Specification) which is a comprehensive document is created after the (SRS) Software
Requirements Document. It provides more details on selected items originally described
in the Software Requirements Template. Elsewhere organizations combine these two
documents into a single document.
The Functional Specification describes the features of the desired functionality. It
describes the product's features as seen by the stake holders, and contains the technical
information and the data needed for the design and development.
The Functional Specification defines what the functionality will be of a particular area
that is to be precise a transaction in SAP terminology.
The Functional Specification document to create a detailed design document that explains
in detail how the software will be designed and developed.
The functional specification translates the Software Requirements template into a
technical description which
a) Ensures that the product feature requirements are correctly understood before moving
into the next step that is technical development process.
b) Clearly and unambiguously provides all the information necessary for the technical
consultants to develop the objects.
At the consultant level the functional specs are prepared by functional consultants on any
functionality for the purpose of getting the same functionality designed by the technical
people as most of the times the functionalities according to the requirements of the clients
are not available on ready made basis.
Let me throw some light on documentation which is prepared before and in a project:
1) Templates
2) Heat Analysis 3) Fit Gap or Gap Analysis
4) Business Process Design
5) Business Process Model

6) Business Change & Impact

7) Configuration Design, which is just 5 % of Total SAP- have different names 8) Future Impact & Change Assessment
9) Functional Design (Module Wise)
10) Risk Assessment
11) Process Metrics and Many More-- Which has impact on Business and its work flow
Hope it is useful
Reward points if helpful...
Regards,
Kaleeswaran
Re:
Functional
specs

Reply

Posted: Feb 5,
2008 10:43 AM
in response
to: Ashwath
Reddy

Dear Ashwath Reddy,

What Are Functional Specification in SAP?
To speak at macro level that is at projet manager or at senior levels. The Functional Spec
(Specification) which is a comprehensive document is created after the (SRS) Software
Requirements Document. It provides more details on selected items originally described
in the Software Requirements Template. Elsewhre organizations combine these two
documents into a single document.
The Functional Specification describes the features of the desired functinality.. It
describes the product's features as seen by the stake holders,and contains the technical
information and the data needed for the design and developement.
The Functional Specification defines what the functionality will be of a particulat area
that is to be precise a transaction in SAP terminology.
The Functional Specification document to create a detailed design document that explains
in detail how the software will be designed and developed.
The functional specification translates the Software Requirements template into a
technical description which
a) Ensures that the product feature requirements are correctly understood before moving
into the next step, that is detchnical developement process.
b) Clearly and unambiguously provides all the information necessary for the technical

consultants to develop the objects.

At the consultant level the functional spects are preapred by functinal consultants on any
functionality for the purpose of getting the same functinality designed by the technical
pepole as most of the times the functionalities according to the requirements of the clients
are not available on ready made basis.
Let me throw some light on documentation which is prepared before and in a project:
1) Templates
2) Heat Analysis 3) Fit Gap or Gap Analysis
4) Business Process Design
5) Business Process Model
6) Business Change & Impact
7) Configuration Design, which is just 5 % of Total SAP- have different names 8) Future Impact & Change Assessement
9) Functional Design (Module Wise)
10) Risk Assessement
11) Process Metrics and Many More-- Which has impact on Business and its work flow
Note * This documents are preapared in Vanilla SAP Standards -- Things differ from one
implementation to another, and it always depends on the type of business which is opting
for SAP.
Hope this helps you.
Regards,
Rakesh
Re:
Functional
specs

Reply

Posted: Feb 5,
2008 11:04 AM
in response
to: Ashwath
Reddy

dear reddy
Functional Spec: FS is a document written by the functional guy to communicate to the
ABAPer, to say what development needs to be carried out and what are the tables and
fields involved. The basic reason for a functional spec would be that of documentation
and reference and importantly the technical guys wouldnt really know the business
process but only the tables and fields involved. So the functional guy communicates the
business requirement in technical way through a functional spec. Features of a FS would
be that it will have a version number which would change depending on the modifications

made to that particular object there after. There would be a pseudo logic which outlines
what needs to be done for data extraction, tables and fields to be used, validations, testing
info .,
A functional spec is a document which provides the logic to carry out the development.
This document contains logic to be followed & the table from which the data is to be
picked. It also contains details of which are the connecting table & how the fields are to
be mapped
what are Functional Specification in SAP?
To speak at macro level that is at project manager or at senior levels. The Functional Spec
(Specification) which is a comprehensive document is created after the (SRS) Software
Requirements Document. It provides more details on selected items originally described
in the Software Requirements Template. Elsewhere organizations combine these two
documents into a single document.
The Functional Specification describes the features of the desired functionality.. It
describes the product's features as seen by the stake holders, and contains the technical
information and the data needed for the design and development.
The Functional Specification defines what the functionality will be of a particular area
that is to be precise a transaction in SAP terminology.
The Functional Specification document to create a detailed design document that explains
in detail how the software will be designed and developed.
The functional specification translates the Software Requirements template into a
technical description which
a) Ensures that the product feature requirements are correctly understood before moving
into the next step, which is technical development process.
b) Clearly and unambiguously provides all the information necessary for the technical
consultants to develop the objects.
At the consultant level the functional sects are prepared by functional consultants on any
functionality for the purpose of getting the same functionality designed by the technical
people as most of the times the functionalities according to the requirements of the clients
are not available on ready made basis.
Let me throw some light on documentation which is prepared before and in a project:
1) Templates
2) Heat Analysis 3) Fit Gap or Gap Analysis
4) Business Process Design
5) Business Process Model
6) Business Change & Impact
7) Configuration Design, which is just 5 % of Total SAP- have different names 8) Future Impact & Change Assessment
9) Functional Design (Module Wise)

10) Risk Assessment

11) Process Metrics and Many More-- Which has impact on Business and its work flow
rewards if it helps
siva
Functional Specs concept varies from Client to Client. The Standard Concept of Functional Specs
in SAP is that it is a document, which will contain the details of the requirement for development
purpose. It will include important parameters such as:
1. Company's Name
2. Topic of Functional specs
3. Created by
4. Reviewed by
5. Creation date
6. Revised date & version (it may also contain a breif information about revision / modification
done)
7. Purpose of Functional Specs
8. Requirement of client
9. Logic to arrive at the requirement, along with details of Tables-fields & links between tables.
10. Provision for capturing test cases
The above are the few, which can be recollected upfront.

Re: How to
prepare a
functional spec.
Posted: Jan 19, 2008
12:39 PM
in
response to: Raghu Ram

follow and prepare as per below contents,

TABLE OF CONTENTS
1. Program Information
2. Functional Specification
3. Detail description
3.1 The Functional Solution - Detail Logic
3.2 Programme Type / Timing
3.3 Impact of change on the system
3.4 Assumptions
3.5 Authorisation
3.6 Other Issues
3.7 Error Processing
3.8 Additional Information
3.9 Testing
3.10 User Acceptance Criteria
4. Technical implementation
4.1 Inputs:
4.2 Outputs:

4.3 Reporting:
4.4 Validation:
4.5 Technical Flow
4.6 Transaction for enhancement
5. Authorization checks
5.1 Objects which should be checked
5.2 Sensitivity of Report
Re: How to
prepare a
functional
spec.
Posted: Jan 20, 2008
2:59 PM
in
response to: Raghu
Ram

Functional Specification Format

Authorization Name- Tech Consultant Approval Date
Approval Name- Functional Consultant
1. Solution Information
a) Companyb) Release2.Object Information
a) Object field
b) Functional Specification type- Reports/Interface enhancement
c) Status- Approved/Not Approved
d) Test Scenariaoe) Priority- High/Low/Medium Or 1 2 3
f) Complexity-g) Cleint start Date-h) Clent End Date-3. Revision History-Rev No--Rev Date-- User--Description
4.Description or Purpose
a) Description or purpose---Here follows a complete description what Functionality this
specification is going to perform
b) Business proess details-- Here follows the description of business process onvolved
c) Current Functionality-d) Decide Functionality--Replay
Functional specifications (functional specs), in the end, are the blueprint for how you
want a particular report and transaction to look and work. It details what the report will
do, how a user will interact with it, and what it will look like. By creating a blueprint of
the report or transaction first, time and productivity are saved during the development
stage because the programmers can program instead of also working out the logic of the
user-experience. It will also enable you to manage the expectations of your clients or
management, as they will know exactly what to expect.

A key benefit of writing up a Functional Spec is in streamlining the development process.

The developer working from the spec has, ideally, all of their questions answered about
the report or transaction and can start building it. And since this is a spec that was
approved by the client, they are building nothing less than what the client is expecting.
There should be nothing left to guess or interpret when the spec is completed.
Functional Specification
A functional specification (or sometimes functional specifications) is a formal document
used to describe in detail for software developers a product's intended capabilities,
appearance, and interactions with users. The functional specification is a kind of
guideline and continuing reference point as the developers write the programming code.
(At least one major product development group used a "Write the manual first" approach.
Before the product existed, they wrote the user's guide for a word processing system, then
declared that the user's guide was the functional specification. The developers were
challenged to create a product that matched what the user's guide described.) Typically,
the functional specification for an application program with a series of interactive
windows and dialogs with a user would show the visual appearance of the user interface
and describe each of the possible user input actions and the program response actions. A
functional specification may also contain formal descriptions of user tasks, dependencies
on other products, and usability criteria. Many companies have a guide for developers
that describes what topics any product's functional specification should contain.
For a sense of where the functional specification fits into the development process, here
are a typical series of steps in developing a software product:
Requirements:
This is a formal statement of what the product planners informed by their knowledge of
the marketplace and specific input from existing or potential customers believe is needed
for a new product or a new version of an existing product. Requirements are usually
expressed in terms of narrative statements and in a relatively general way.
Objectives: Objectives are written by product designers in response to the Requirements.
They describe in a more specific way what the product will look like. Objectives may
describe architectures, protocols, and standards to which the product will conform.
Measurable objectives are those that set some criteria by which the end product can be
judged. Measurability can be in terms of some index of customer satisfaction or in terms
of capabilities and task times. Objectives must recognize time and resource constraints.
The development schedule is often part or a corollary of the Objectives.
Functional specification.: The functional specification (usually functional spec or just
spec for short) is the formal response to the objectives. It describes all external user and
programming interfaces that the product must support.
Design change requests: Throughout the development process, as the need for change to
the functional specification is recognized, a formal change is described in a design
change request.
Logic Specification:
The structure of the programming (for example, major groups of code modules that

support a similar function), individual code modules and their relationships, and the data
parameters that they pass to each other may be described in a formal document called a
logic specification. The logic specification describes internal interfaces and is for use
only by the developers, testers, and, later, to some extent, the programmers that service
the product and provide code fixes to the field.
User documentation:
In general, all of the preceding documents (except the logic specification) are used as
source material for the technical manuals and online information (such as help pages) that
are prepared for the product's users.
Test plan: Most development groups have a formal test plan that describes test cases that
will exercise the programming that is written. Testing is done at the module (or unit)
level, at the component level, and at the system level in context with other products. This
can be thought of as alpha testing. The plan may also allow for beta test. Some companies
provide an early version of the product to a selected group of customers for testing in a
"real world" situation.
The Final Product:
Ideally, the final product is a complete implementation of the functional specification and
design change requests, some of which may result from formal testing and beta testing.
The cycle is then repeated for the next version of the product, beginning with a new
Requirements statement, which ideally uses feedback from customers about the current
product to determine what customers need or want next.
Most software makers adhere to a formal development process similar to the one
described above. The hardware development process is similar but includes some
additional considerations for the outsourcing of parts and verification of the
manufacturing process itself.

Comments
how to convert function specs to technical specs,
please mail the details to mail id: nishanthvairagade@gmail.com
By: | 30 Nov 2009
when we closed the month peread in a clint . after closing when we are go migo any new
order that a messeg is come your current moth not opening . That time what i can do .
Please tel me
By: | 22 Jan 2010
Do you have an example that can illustrate how this kind of document should look like ?
if so can you email it to alfredb15@yahoo.com
By: | 14 Mar 2010
Kindly also send a sample of the actual document to josh.qa@hotmail.com. Thank you.
By: John Doe | 26 Mar 2010
could you please send some sample of FS to grmeena1975@gmail.com, since it will be
useful for me to make a very good practise and gather idea just equal to
real time work.
By: | 07 May 2010

please send me some of FS's on interactive reporting ,ALV reporting and on smart
forms....on my mail id-sandeepruhela@hotmail.com,sangrtstr@gmail.com
i will be thank full for all of you
By: | 29 May 2010
Hi SD Experts,Can you share with me 2-4 sample Functional Specfications in SAP SD
which you have worked on in your real time project. please send the above samples to my
e-mail id sivakumar.nice@gmail.com. Expecting express reply from your end. Thankxx
in advance....
I would be thankful for your timely help.
By: | 29 Jun 2010
It is very helpful. Please kindly send a sample of FSD to tammielpt@yahoo.com. Thanks
so much!
By: | 07 Jul 2010
could you please send some sample of FS to akash2426@gmail.com, since it will be
useful for me to make a very good practise and gather idea just equal to
real time work.
BR//
Rofique
By: | 29 Jul 2010
could you please send some sample of Functional specs to sumith3006@gmail.com, since
it will be useful for me to make a very good practice and gather idea just equal to
real time work.
By: | 01 Aug 2010
hi its very urgent for me could you please send some sample of Functional specs to
shahed_sap@yahoo.com,
Best regards
Shahed
By: | 02 Aug 2010
Please, I need functional spec too close to asset acquisition through Cash Advance to
staff. Send to gbengabiola2003@yahoo.com
Thanks
Gbenga
By: | 12 Aug 2010
hi friends ,
i need few funcational specations in fico please any body can sent to my mail.
kaparthi86@gmail.com
thank you
By: santhosh kaparthi | 20 Aug 2010

I need some functional specifications in fico please. Kindly send it to

bla.mcphee@yahoo.com. Thanks
By: | 20 Aug 2010
I need some functional specifications in fico plz send it to santhoshrao.a@gmail.com
By: | 16 Sep 2010
I need some functional spec's in fico... Any help would be appreciated.
Please mail at j.shrenik@gmail.com
By: | 04 Oct 2010
Hi,
Can any one share some FS related to FICO and AM.
please send them to mal id:rajesh_jasti@rediffmail.com.
thanks
rajesh J
By: | 20 Nov 2010
HOW TO MAKE FUNCTIONAL SPECIFICATIONS FOR MATERIAL MASTER,IF
SUPPOSE I WANT TO MAKE A NEW MATERIAL WHERE AS I WOULD LIKE TO
INPUT THE NAME OF THE REQUESTER FOR WHOM I AM CREATING THE
MATERIAL, SO CAN YOU PLEASE REPLY ME HOW TO MAKE THE
FUNCTIONAL SPECIFICATION..................
By: | 09 Dec 2010
kindly send me some functional specification for material mngt, sd,fi.
Please send it on email id sadiqahmedcse@gmail.com
By: | 15 Dec 2010
kindly send me some functional specification for SAP SD
Please send it on email id papriyatam@gmail.com
By: | 01 Jan 2010
Kindy send me some functional specification for HR if available via
clean_wc@hotmail.com. Thanks :)

List of all the important tables used in Sales and Distribution (SD) :
VTFA
VEPVG

Flow shipping documents

Delivery Due Index

Sales order :
VBAK
VBAP
VBPA
VBKD
VBEP

Header data
Item data
Partners in sales order
Sales district data
Data related to delivery line items

Billing document :

VBRK
VBRP

header data
Item data

Shipping :
VTTK
VTTP
VTTS
VTSP
VTPA
VEKP
VEPO

Shipment header
Shipment item
Stage in transport
Stage in transport per shipment item
Shipment partners
Handling Unit - Header Table
Packing: Handling Unit Item (Contents)

SD Delivery Documet :
LIKP
LIPS

Delivery header
Delivery item

Pricing :
KONH
KONP
KONV
KOND

Conditions header
Conditions items
Procedure ( billing doc or sales order)

Contracts :
VEDA

Contract data

Customers
KNA1
KNB1
KNB4
KNB5
KNBK
KNKA
KNKK
KNVV
KNVI
KNVP
KNVD
KNVS
KLPA

General Data
Customer Master Co. Code Data (payment method, reconciliation acct)
Customer Payment History
Customer Master Dunning info
Customer Master Bank Data
Customer Master Credit Mgmt.
Customer Master Credit Control Area Data (credit limits)
Sales Area Data (terms, order probability)
Customer Master Tax Indicator
Partner Function key
Output type
Customer Master Ship Data
Customer/Vendor Link

Sales Documents
VBAKUK VBAK + VBUK
VBUK Header Status and Administrative Data
VBAK Sales Document - Header Data
VBKD Sales Document - Business Data
VBUP Item Status
VBAP Sales Document - Item Data
VBPA Partners

VBFA Document Flow

VBEP Sales Document Schedule Line
VBBE Sales Requirements: Individual Records

Invoice Split Criteria for Invoice Lists

Multiple Invoices are combined into an invoice list however, more than one invoice list is
created.
Invoice List Splits occur because of different header partners (bill-to parties and payers,
table VBPA) or, primarily due to different header fields (table VBRK).
The 1st step in resolving issues with invoice splits is to simply compare ALL header
fields, i.e. the entries in tables VBRK and VBPA. You can use transaction SE16 or SE17
to compare the entries in these tables for invoices or invoice lists.
Especially the following header fields could cause invoices to split into multiple invoice
lists.
1) Billing Date for the invoice list (VBRK-FKDAT_RL)
Different Billing Dates for the invoice list from the original invoices will automatically
cause invoices to split into multiple invoice lists. This is standard functionality. The
primary way to avoid this is to enter a date as a default billing date in transaction VF21 or
to modify
the report from traqnsaction VF24.
If you do not enter a default billing date and the dates from the individual invoices differ,
than the invoice lists will be split into as many invoice lists as there are different dates.
2) Translation Date (VBRK-KURRF_DAT, new as of release 4.0)
The exchange rate date is determined in the order header by the pricing date. This date
can be copied into the invoice or, redetermined at the time of invoice creation based on
the copy control settings. The implementation of note 168850 will avoid this problem.
You can also check that note 115528 is installed if you are on 4.0B.
3) Origin sls.tax no. (VBRK-STCEG_H)
The implementation of note 141978 will avoid this problem if the split would not be
justifiable.

4) All other header field may also cause a split with the exception
of:
VBRK-KNUMV
VBRK-NETWR
VBRK-MWSBK
VBRK-VBELN
VBRK-RFBSK
VBRK-ERNAM
VBRK-AEDAT
VBRK-ERDAT
VBRK-ERZET
The relevant coding can be found in program LV60AF0X,
FORM XVBRK_BEARBEITEN:
...
LOOP AT XVBRK.
BELEG = XVBRK-VBELN.
XVBRK-NETWR = 0.
"aus Vergleich ausnehmen
XVBRK-MWSBK = 0.
"aus Vergleich ausnehmen
XVBRK-VBELN = SPACE.
"
"
XVBRK-RFBSK = VBRK-RFBSK.
"
"
XVBRK-ERNAM = VBRK-ERNAM.
"
"
XVBRK-AEDAT = VBRK-AEDAT.
"
"
XVBRK-ERDAT = VBRK-ERDAT.
"
"
XVBRK-ERZET = VBRK-ERZET.
"
"
...
The only possibility to avoid a split caused by different entries in table VBRK with the
exception of the fields listed above, is to initialize the entries in a own data transport
routine in the copy control of the affected billing document types. Of course the
information stored in these fields will then be lost in the invoice list.

Grouping sales order and export delivery in a

billing document.
It is possible to group export deliveries in a billing document if the determination of
the foreign trade segment in the copying control table is set to 'A' (Copy foreign trade
data of the delivery) or 'B' (Redetermine foreign trade data).
It is possible to group sales orders and deliveries in a billing document, providing no
split is initialized by different header fields or header partners.

Customizing in the copying control table (TVCPF):

Determine foreign trade segment (field name in Rel.3.0x)
Determine export segment (field name in Rel.2.2x)
1st case : The field 'Det. foreign trade segment' (or 'Det. export segment') is set
differently in the sales order and in the export delivery:
--> Billing split due to different export indicators
2nd case : The field 'Det. foreign trade segment' (or 'Det. export segment') is set to ' ' in
the sales order and in the export delivery:
--> Billing split due to different export indicators
(' ' in the sales order and 'X' in the export delivery)
3rd Case : The field 'Det. foreign trade segment' (or 'Det. export segment') is set to 'A' in
the sales order and in the export delivery:
--> no split due to export indicator or export segment number; the export data of
the order item was redetermined in the billing document
4th Case: The field 'Det. foreign trade segment' (or 'Det. export segment') is set to 'B' in
the sales order and in the export delivery:
--> no split due to export indicator or export segment number; the export data of
the order item was redetermined in the billing document
Note:
If export fields should explicitly initialize a billing document split (for example, different
country of origin), you have to create a corresponding data transport routine.

Collective billing for order-related and

delivery-related items
Collective Billing:
Collective Billing combines different documents (orders / deliveries) into a single Invoice
document provided certain data specified is common across these source documents. The
Header data appearing in billing document must be same.Collective billing is not possible
for a sales order and an export delivery. Collective billing can only be carried out for
domestic business affairs.The transaction code for collective billing is via VF04.
Collective billing for order-related and delivery-related items :
If you create a sales order with an item which is relevant for billing by delivery and an
item which is relevant for billing by the sales order up to now the items could not be
grouped together in a billing document.

Order releted billing is done when we proceed directly to the billing from order while
doing only the PGI.eg Cash sales
Delivery releted billing is the normal sales cycle where we go to dilivery from order and
then to the invoice from delivery.eg normal sales cycle rush order.
1. Problems with the billing date
If a sales order and a delivery are billed together and the date of the sales order (proposal
for the billing date) is not equal to the goods issue date (proposal for the billing date),
there is a problem with specifying the billing date. If a common billing date is not
determined, an invoice split is created.
This problem can be avoided if you specify a default date when creating the billing
document.
This problem generally does not occur for period calculations.
You can determine a common billing date (for example, the current date) by creating a
new data copying routine xxx (for example, by copying routine '001').
Using transaction VOFM and menu path "Data transfer -> Billing documents", you can
copy the data transport routine and change it as follows :
form daten_kopieren_xxx.
: