Production Planning

FUNCTIONAL SPECIFICATION
Interface
<Name of Interface>

Sender system: <Sender system>

Target system: <Target system>

PwC / TALEX

Table of Contents
1 Interface Facts 4
2 Executive Summary 6
2.1 Purpose 6
 FS Material Consumption

Production Planning

PWC/TALEX

2.2 Interface overview 6

2.3 Short Description 6
2.4 Alternative 6
2.5 Business Benefit and Consequence of Proposed Solution 7
2.6 Relations to other documentations 7
3 Requirements 8
3.1 Business Requirements 8
3.2 Technical Requirements 8
3.3 Operations Requirements 9
3.4 Constraints / decisions 9
3.5 Language Considerations 9
4 Message transfer and mapping 10
4.1 Involved Systems 10
4.2 Message processing 10
4.2.1 Processing within System A 11
4.2.2 Processing within System B 11
4.2.3 Situations Requiring Special Handling 11
4.3 Trigger Points 11
4.4 Activation of message transfer 11
4.5 Communication Details 12
4.5.1 File Transfer 12
4.5.2 Other communication types 13
4.6 Transformation Rules 13
4.6.1 Structure 14
4.6.2 Attributes 14
4.6.3 Situation requiring special handling … 14
4.7 Error Handling 14
4.7.1 Communication errors 15
4.7.2 Handling of Mapping errors 15
5 Response transfer and mapping 16
6 Deliveries 17
6.1 Integration tasks to be performed by <vendor 1 name> 17
6.2 Integration tasks to be performed by DS 17
6.3 Integration tasks to be performed by <vendor 2 name> 17
7 Technical Development Concept 18
7.1 Overall Process Description 18
7.2 Technical Development <Sender> 19
7.2.1 Graphical Visualization 19
7.2.2 Development description 19
7.3 Technical Development Middleware 19
7.3.1 Graphical Visualization 19

Last edited: 10-07-2017

Page 2 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

7.3.2 Development description 19

7.4 Technical Development <Receiver> 19
7.4.1 Graphical Visualization 19
7.4.2 Development description 19
Appendix 20
A.1 Contacts 20

1 Interface Facts
<Steps in Business Process: If possible, mention the Business Process step(s) the interface
is(are) related to..>
<SAP Components/Non-SAP Components: Specify in which component the development is
executed e.g. FI, CO, CO-PA.>
<Global/Local Solution: Global: The solution is the same in all the countries– Local: The solution
differs in the different countries in order to meet the different legal requirements as well as the
different business processes of the countries. State the countries where the solution differs.>
<Expected Lifetime: Mark the expected lifetime for this interface.>
<Business Critical: Highly critical: Very serious consequences for normal business transactions.
Work that cannot be postponed cannot be executed. The malfunction can cause serious losses. -
Critical: Normal business transactions are seriously affected. Necessary tasks cannot be
performed. The malfunction may seriously affect the entire productive business. - Normal: Normal
business transactions are affected. User productivity is restricted.>

Interface Facts
Business Process
Business Process
Number
Business Process
Step/Steps in Interface
SAP/Non-SAP System A (e.g. SAP ECC)
Components System B (e.g. SAP SCM)
Interface Name
Interface Number in
Interface Catalogue
Global/Local Solution ☒ Global ☐ Regional in these regions:
☐ Local in these countries:
Expected Lifetime ☒ Permanent
☐ Temporary, until these systems exist:
☐ Temporary, until end of roll-out:
☐ Other:

Last edited: 10-07-2017

Page 3 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

Business Critical
☐ Highly critical ☒ Critical ☐ Normal

Complexity ☐ High ☐ Medium

☒ Low

Implementation Estimates per technical component:

<Remove superfluous lines and add additional lines depending on the number of parties involved in
the solution.>
<High level Estimates: An estimate +/- 25% including analysis, design, development,
documentation and unit test. However, it is up to the project management to decide which parts of
the unit test that are to be carried out by the development and the requirement organization.>
<Detailed Estimates: An estimate +/- 10% including analysis, design, development, documentation
and unit test. However, it is up to the project management to decide which parts of the unit test that
are to be carried out by the development and the requirement organization.>

Technical Comp. High level estimates (+/- 25%) Detailed estimates (+/- 10%)
e.g. SAP ECC man days man days

0 man days man days

Last edited: 10-07-2017

Page 4 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

2 Executive Summary
<The section is aimed at the project manager or project business manager; hence the text must be
understood by non-technical persons. The whole section should be 1-2 pages maximum.>

2.1 Purpose
The purpose of this interface is to…

<Describe the purpose of this interface. Also describe which part of the overall solution is covered
by this interface.>

2.2 Interface overview

<Purpose of this section is to visualize the main data objects exchanged between the
systems/platforms.>
<Show the protocol which is going to be used (e.g. RFC, http, LDAP, file, ftp, …).>
<Show if it is a read-only interface.>
<List all the Sender(s) and Receiver(s). Describe the direction which is used for the main data flow
("push data” versus “pull data”).

Interface overview

System A Technical Object e.g. IDOC System B

Interface technique, e.g. tRFC

2.3 Short Description

Last edited: 10-07-2017

Page 5 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

<Give a brief description of what the interface will do to support the business process. and a very
basic overview of the solution and dataflow on a level aimed for business management.>
<Highlight the scope of the solution and the consequences of that decision. E.g. “solution supports
creation but not update and discontinue, which is handled manually”.>
<Highlight the ambition level of the solution (decides e.g. the costs) and the consequences of that
decision.>
<Highlight who is doing what e.g. Customer, SAP and 3rd party vendor. This gives an input to the
expected costs.>

2.4 Alternative
<If “Yes” is marked, describe relevant alternative solutions, - e.g. a manual work around, a work
around in the SAP system, other development solutions. Incl. business process steps and technical
steps, pro’s and con’s.>
<If “No” is marked, it means that no actual alternatives exists.>

Are there any alternatives to the proposed solution? ☒ Yes ☐ No

2.5 Business Benefit and Consequence of Proposed Solution

<Describe the benefit and the consequence of the proposed solution as precise and specific as
possible.>

2.6 Relations to other documentations

<If there is a security guide of the application(s) involved by this interface, please list here>
<If there are SAP notes containing documentation or describing configuration options, please list
here>

Document System Description

Last edited: 10-07-2017

Page 6 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

3 Requirements

<Requirements should not describe the solution, but state the needs and constraints setting the
framework for the solution >
<The requirements should not be a description of the current solution, but should reflect how the
future solution should be experienced by the users (to be processes) and wishes to new technology
to be used.>

3.1 Business Requirements

<Describe the business requirements in business terms, and group the requirements in bullet points
or sections. Suggestion for areas to include:
● Give an overview of the workflow the integration must support (Include a drawing if
possible). E.g. concerning articles “SAP is the master of the articles. The integration must
support a solution where the user maintains (creates, updates, reads, deletes) the articles
on SAP ECC and each updated article is synchronized immediately to the legacy system
where the user can continue the work, e.g. creating orders for the article. The user must be
able to monitor the progress and status of the synchronization, but should not wait for the
synchronization to complete.”
● Describe situations which require special handling compared to the main workflow.

● Which data objects must be supported, e.g. concerning articles remember to describe all
the different article types and variants: full product, empties, individual, single, generic or
structured articles.
● Describe data objects that require special handling.

● Consider whether this interface is business critical and if so describe why?

● Describe if special requests exist to meet response times or critical time windows.>

3.2 Technical Requirements

Last edited: 10-07-2017

Page 7 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

<State the technical requirements that must be met by this interface i.e. set by other systems and
interfaces. Remember that this is requirements and not a solution proposal.>
<Areas to include are depending on the actual interface but below areas could among others be
considered:
● Architectural considerations.

● Limitations set by System A or interface to/from system A such as locking, sequencing,

does it support a mass change, Should a full image be received or only the changes,
communication e.g. (only supports RFC calls or SNA protocol) etc.
● Limitations set by System B or interface to/from system B (as above).

Last edited: 10-07-2017

Page 8 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

● Versions of the systems – should they be upgraded?

● Requirements set by other interfaces or systems.

● Timing requirements, when should batch files be sent, is there a sequence etc.?

● Is a portal part of the solution and if so does that make additional requirements?

● CITRIX, .Net, technical implementation, web services, EDI etc.

● Special error handling such as resend and forced export.>

3.3 Operations Requirements

<Does the interface require high availability?>

3.3.1 Monitoring
<Describe how monitoring of connections takes place and how monitoring data get archived.>
<Describe how monitoring of transmitted data takes place and how logged data get archived.>
Further details will be added by Transition to Operations workstream

3.4 Security Requirements

<General:
● Define who (person respective team) is responsible for the security of the destination.

● Describe how does system A authenticates itself in system B (stored credentials, Trusted-
RFC with technical user, Trusted-RFC with same user, http with SAP authentication token,
…)? See also technical design…
● Describe if the data contain personal information which might be under control of a data
protection law.
● Describe how can the owner of the data keep control about which data are pushed
respective pulled (authorization checks, configuration).
● Is it possible or required to encrypt the communication channel?

● Is it possible or required to encrypt the data transmitted over the communication channel?

● Is it possible or required to digitally sign the data transmitted over the communication
channel?

Last edited: 10-07-2017

Page 9 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

When technical design is more or less defined, following information should be added

In case of ABAP being the RFC client:

Define if a technical remote user is used or if Single Sign-On is used via Trusted RFC with the
‘same-user’ option.
Define if it is required to control access to the destination using authorization object S_ICF in ABAP.
(This is recommended if a very powerful destination is used, e.g. in case of a Central User
Management scenario.)

<In case of ABAP being the RFC server:

Define if the user type ‘system’ is sufficient or if the user type ‘dialog’ is required for the user in the
RFC server system.
Define if a technical remote user is used or if Single Sign-On is used (via Trusted RFC with the
‘same-user’ option).
Describe the authorizations for authorization object S_RFC which are required for the user in the
RFC server system.
Describe other required authorizations, too.
List the (SAP standard) roles which contain these authorizations.
Define if destination ‘BACK’ used to call back to the RFC client.>

<In case of ABAP being the WebService client:

Define if a technical remote user is used or if Single Sign-On is used via the SAP Authentication
Token.>

<In case of ABAP being the WebService server:

Define if a technical remote user is used or if Single Sign-On is used via the SAP Authentication
Token.
Describe the authorizations for authorization object S_SERVICE which are required for the user in
the WebService server system.
Describe other required authorizations, too.
List the (SAP standard) roles which contain these authorizations.>

<In case of non-ABAP / non-Java being the client:

● Describe how stored credentials (user and password) are secured.

● Describe how the client controls access to the interface.>

3.5 Constraints / decisions

Last edited: 10-07-2017

Page 10 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

<Describe limitations / decisions that have had influence on the above described requirements.>
<This could be limitations / decisions related to both business and/or technical infrastructure
identified up front or during the specification phase.>
<Examples could be
● It has been decided which system should be the master of record?

● Already agreed service levels which must be adhered

● Agreed ambition level.>

3.6 Language Considerations

<This section should contain information on language considerations/translation required for the
development.>
<Language Considerations Mark off if this development contains any areas that are subject for
translation and if so, state the areas. An example could be the situation where a value list is
exchanged as strings between two systems rather than values, then the texts will have to be
converted into the target language.>
<Translation Language: Indicate the languages the texts should be translated into.>

Language Considerations
Does this functional specification contain any areas that are subject for translation: ☒ No ☐ Yes

Last edited: 10-07-2017

Page 11 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

4 Message transfer and mapping

4.1 Involved Systems
<Update the arrows in the diagram. Each arrow must show the chosen communication type – e.g.
IDOC, CSV, PDF, XML, EDIFact, etc. Connection is RFC, FTP, HTTP, etc.>

Communication Type

System A System B

<Name: If the system is a customer system, then the name is given by system name and
abbreviation, e.g. “STR Struktur”. If the system is a SAP system mention e.g. SAP BW, SAP ERP,
SAP SRM.>
<Short System Description: Give a short explanation of the system if necessary. Also state if
upgrades / changes are needed in order for the solution to work.>
<Platform: State on which platform the system is placed.>

Sender(s)
Name
Short System
Description
Platform ☒ SAP ☐ Non-SAP
Operated by Inhouse, External, Service Provider, Cloud etc.

Receiver(s)
Name
Short System
Description
Platform ☒ SAP ☐ Non-SAP
Operated by Inhouse, External, Service Provider, Cloud etc.

Last edited: 10-07-2017

Page 12 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

4.2 Message processing

<The purpose of this section is to give an overview of the typical data flow between the Sender(s)
and Receiver(s) without going into the implementation details. During the description be careful to
describe which system or vendor is responsible for doing what, thus making the responsibilities
clear.>
<Processing: Describe the processing for the typical flow within the sending and receiving systems
(e.g. SAP ERP systems how IDoc’s are generated and sent to PI, or for simple file transfers within
PI, how the files will be uploaded into an application). Change the name of the <Sender> and
<Receiver> to the real system names and <Mapping Engine> to SAP PI, BizTalk or similar.>

4.2.1 Processing within System A

● TBD

4.2.2 Processing within System B

● TBD

4.2.3 Situations Requiring Special Handling

<Describe the variations to the dataflow above which requires special handling and which are of
interest to the business. One section must be created for each variation and the description must be
made using business terms.>

4.3 Trigger Points

<Insert a table describing the special user/system actions that triggers the interface.>
<Trigger Point: The various situations in the object(s) lifecycle in the interface. The trigger points
mentioned in the table below are meant as an inspiration and should be changed to reflect the
actual interface.>
Trigger point Should the interface be triggered [Y/N]
Create Y
Read Y
Update Y
Delete Y

Last edited: 10-07-2017

Page 13 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

4.4 Activation of message transfer

<Activation Type: Synchronous – send one object and await response. This will typically lock the
user or process awaiting the response, Asynchronous – send one object and do not await the
response, which will arrive later. The sending user/process is not locked. Batch: A scheduled job is
activated e.g. every 15 minutes, hourly or daily. The batch job can communicate single objects but
will create files with multiple objects.>
<Completion time: Mark when the activated functionality must be finished and the relevant
information must be ready in the receiving system.>
Activation
Activation Type ☐ Synchronous ☐ Asynchronous ☒ Batch
Completion time ☐ Real time ☒ Within an hour ☐ Next day ☐ Other:

4.5 Communication Details

<Content (Message): Describe additional specification of business relevant information that is part
of the interface.>
<Does the message/response contain sensitive data?: Describe what kind of sensitive data the
message contains, and describe the special requirements for protection/security of these data.>
<Frequency: e.g. once a day.>
<Amounts (Normal): fill in the normal amount each time the interface is triggered, e.g. number of
invoices per day (after roll-out of the whole project).>
<Amounts (Peak Load): fill in the amount at peak load, - When: give a short description of the
peak load situation.>
Communication Details
Content (Message) N/A
Does the
message/response
No.
contain sensitive
data ?
Frequency Daily.
Amounts (Normal) 200 a day.
Amounts
2000 When: Mass changes.
(Peak Load)

Full / Delta
Does the message contain a full image of data? ☒ Yes ☐ No
Comments

Last edited: 10-07-2017

Page 14 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

4.5.1 File Transfer

The section below describes the communication type shown in the drawing in section 4.1.
<Communication Type: Describe the file transfer method such as FTP, HTTP etc.>.
<Naming Convention:
● If batch: <Type>-<time stamp>.xml

● If object then per object: <Object name>-<time stamp>.xml

● Timestamp should be YYMMDD-HHMMSS. If a full image is sent and overwrite is required

then the time stamp should be omitted.>
<Overwrite: Y/N.>
File transfer
Communication N/A
Type
Naming N/A
convention
Overwrite

<Specify the frequency and responsibility.>

<Frequency: Daily, weekly, monthly, when needed.>
<Responsibility: Who or what will purge the file. Job or manual action. Name of job, profile etc.>
Purge
Frequency N/A
Responsibility

4.5.2 Other communication types

N/A
<To be filled in if not file transfer., e.g.if web services specify the exact service names and name of
the XML document.>

4.6 Transformation Rules

N/A

Last edited: 10-07-2017

Page 15 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

4.6.1 Structure
<Describe the structural problems between source and target and how these problems should be
overcome by the transformation engine (e.g. PI). Examples:
● Source is on object level, whereas target is a sorted batch file

● Data models in source and target are very different. For each area describe the actions to
be taken by the transformation engine. The source and target models should be modeled in
UML and be compared..
● Multiple sub files should be merged into one source object based on a file naming
convention
● Target files should be delivered as sub files of max 10MB and with a special naming
convention
● Special headers and footers to apply.>

4.6.2 Attributes
<The mapping on the attribute level is done in the mapping sheet.>
<In this section give an overview of the principles for the mapping of the attributes to be applied for
this interface. The below principles must be used if nothing else is described in the mapping sheet.
Examples:
● Default values

● Blank fields and empty tags

● Character encoding (Unicode, ISO 8859-1 (Latin 1), UTF-8, ASCII 7 bit, ASCII, EBCDIC
277,etc. for source and target. Describe the transformation rules to apply in general for text
fields
● Date fields, Booleans, Y/N flags

● Other special attributes.>

4.6.3 Situation requiring special handling …

<Describe special structural handling or attribute mapping which is to complex to be handled in a
mapping sheet. Make one section per area that requires special handling. Examples:
How to handle empty files?
Handling of variants to object types.>

4.7 Error Handling

N/A

Last edited: 10-07-2017

Page 16 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

<Describe the functional error handling that applies to this interface. Areas such as communication
errors, hard mapping errors, soft mapping errors, user replies etc should be covered.>

4.7.1 Communication errors

<Examples:
Possibilities for resend
Possibilities for forced export of data (synchronization)
System’s abilities to send notification to operations. Does the system have limitations. Other
possibilities for reporting errors.>

4.7.2 Handling of Mapping errors

<Examples:
● Should mapping continue (soft error) or terminate (hard error) if mapping fails

● In case of batch file should the mapping continue to next object if the mapping fails on an
object. How is the failed object handled and reported?>

Last edited: 10-07-2017

Page 17 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

5 Response transfer and mapping

N/A

<Examples:
● Should mapping continue (soft error) or terminate (hard error) if mapping fails

● In case of batch file should the mapping continue to next object if the mapping fails on an
object. How is the failed object handled and reported?.>

Last edited: 10-07-2017

Page 18 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

6 Deliveries
<Make a delivery list including each of the major areas and who is responsible for the task.
Examples are shown below. The intention is that everybody part of the solution knows what to do
and what not to do. This can also be input for the effort estimation.>

6.1 Integration tasks to be performed by <vendor 1 name>

<Examples of deliveries:
● Implement solution described in this document

● Implement enhancement XX to standard solution

● Configure trigger points

● Provide sample files for test

● Test of listed tasks.>

6.2 Integration tasks to be performed by DS

<Examples of deliveries:
● Establish physical connection, including special hardware, if any.

● Upgrade <Target System> to a suitable version

● Implement mapping in PI

● Purge exchanged files

● Maintain trigger points

● Test of listed tasks.>

6.3 Integration tasks to be performed by <vendor 2 name>

<Examples of deliveries:
● Implement solution described in this document

● Implement enhancement XX to standard solution

● Test of listed tasks.>

Last edited: 10-07-2017

Page 19 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

7 Technical Development Concept

<The intention of this section is for the vendors to make an overview of the implementation in order
to better give an estimate on the effort. The vendor can be very technical and can use internal
terms and function names.>
<Update the arrows in the diagram. Each arrow must show the chosen communication type – e.g.
IDOC, BAPI, XML, CSV, EDI.>

Communication Type

<type> SAP PI / <type>

Sender(s) Receiver(s)
<connection> BizTalk <connection>
System A System B

<type> <type>
<connection> <connection>

7.1 Overall Process Description

<Processing: Describe the processing within the sending and receiving systems (e.g. SAP ERP
systems how IDoc’s are generated and sent to PI, or for simple file transfers within PI, how the files
will be uploaded into an application). Alternatively refer to other specifications if available.If PI or
BizTalk are not part of the Interface just write N/A.>
<BPM: Only needed if Business Scenarios are created in the Integration Repository.>
<Additional Description: Only needed if Business Processes are used.>

Processing within Sender

Processing within PI
Processing
BPM
Additional
Description
Processing within BizTalk
Processing
Additional
Description
Processing within Receiver

Last edited: 10-07-2017

Page 20 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

7.2 Technical Development <Sender>

7.2.1 Graphical Visualization
<Draw up the process for the generation of data related to sender.>

7.2.2 Development description

7.3 Technical Development Middleware

<If no middleware is part of the interface just write N/A.>

7.3.1 Graphical Visualization

<Draw up the process for the handling of data in PI.>

7.3.2 Development description

7.4 Technical Development <Receiver>

7.4.1 Graphical Visualization
<Draw up the process for the handling of data related to receiver.>

7.4.2 Development description

Last edited: 10-07-2017

Page 21 of 22
 FS Material Consumption

Production Planning

PWC/TALEX

Appendix

A.1 Contacts
Solution
What Initials Name Company Phones Email
Coordinator
Designer
Process owner
Authorizations
…
<system 1>
What Initials Name Company Phones Email

Hardware and connections

What Initials Name Company Phones Email

Last edited: 10-07-2017

Page 22 of 22