https://s4hclub.

com/
https://www.youtube.com/@s4hclubforyou

{Workstream}
FUNCTIONAL SPECIFICATION
ABAP custom development – Interfaces

{WRICEF ID Description}
{Organisation / Project Name}

Role and Reason for Approval

Role Reason for Approval

Author The author is signing to confirm that this document has been
prepared in accordance with the programme document
management process, that relevant input from any contributory
authors has been included and that an appropriate review/editing
process has been conducted.
SAP Solution The SAP Solution Lead or Architect is signing, on behalf of the
Lead or Workstream, to confirm that this Functional Specification meets the
Architect Acceptance Criteria expected of it and assigned to it in the
Deliverable Quality Log.
SAP The SAP Development Lead or Manager is signing, on behalf of the
Development Development Team, to confirm that this Functional Specification
Lead or meets the Acceptance Criteria expected of it and assigned to it in
Manager the Deliverable Quality Log.

Note. Master copy of this document, with signatories, is held on Solution Manager

DATE: 03/04/2023
FS {WRICEF ID Description}
{Workstream}
{Organisation / Project Name}

Version Date Name Alteration Reason

1 09/07/2024 Roger Sainsbury Initial draft

Table of Content
1 Context 3
1.1 Business Background 3
1.2 Why is SAP standard not appropriate or sufficient? 3
1.3 Alternative Approaches Considered 3
1.4 Out of Scope 3
1.5 Assumptions 3
1.6 Dependencies 3
1.7 Links 3
2 Solution Design – APIs and Web Services 4
2.1 Business Object 4
2.2 API Signature 4
2.3 Data Validation 4
2.4 API Logic 4
2.5 Confirmation and Error Handling 4
3 Solution Design – IDOC extensions and custom IDOCs 5
3.1 Business Object 5
3.2 IDOC Structure 5
3.3 Inbound Processing 5
3.4 Outbound Processing 5
4 How to Test 6

© 2024 SAP SE or a SAP affiliate company. All rights reserved. Page 2 of 6

FS {WRICEF ID Description}
{Workstream}
{Organisation / Project Name}

1 Context

1.1 Business Background

Explain the business scenario that requires the development.

1.2 Why is SAP standard not appropriate or sufficient?

Generally we want to keep the system as standard as possible, so each custom development requires a
justification.

1.3 Alternative Approaches Considered

Sometimes a number of different approaches are possible to meet a requirement. If that is the case, outline
what the other options were, and why they were rejected in favour of this one.

1.4 Out of Scope

This Functional Spec only covers any ABAP development required for an Interface. The definition of the
interface itself, including data mapping, is to be covered in a separate document.

If functionality has been considered and decided to be out of scope for the development, then please record it
here.

1.5 Assumptions

If the proposed design relies on any assumptions, please state them here.

1.6 Dependencies

If the proposed design has dependencies on other developments or configuration, please state them here.

1.7 Links

Provide any links here to further relevant information (e.g. from SAP Help, SCN, SAP Notes).

© 2024 SAP SE or a SAP affiliate company. All rights reserved. Page 3 of 6

FS {WRICEF ID Description}
{Workstream}
{Organisation / Project Name}

2 Solution Design – APIs and Web Services

APIs usually take the form of an RFC-enabled function module, from which it’s possible to generate a web
service. Please delete this section if the development is a custom IDOC.

2.1 Business Object

What is the Business Object that the API will create/update/delete?

What transaction(s) can be used to see this type of object?

(If known) what tables hold the business object data?

2.2 API Signature

What input parameters should the API have?

2.3 Data Validation

If the inbound data should first be validated, then describe the requirements here.

2.4 API Logic

For standard business objects, any updates should be performed using a supported method such as a BAPI
call or Call Transaction (BDC). If you know of a suitable update method that may be used, then state it here.
For Call Transactions, if possible provide a BDC recording or a screen recording which the developer can
replay.

For custom business objects the code to perform the updates will be custom too – in which case specify here
any logic required.

Is the API to create, update, delete or read objects? It may be that all four of these activities (known as CRUD)
will be required.

2.5 Confirmation and Error Handling

Typically an RFC will return a table of messages indicating success or error, and perhaps the key of any object
created. If there are any more specific requirements for what the API should return, then state them here.

© 2024 SAP SE or a SAP affiliate company. All rights reserved. Page 4 of 6

FS {WRICEF ID Description}
{Workstream}
{Organisation / Project Name}

3 Solution Design – IDOC extensions and custom IDOCs

It may be necessary to define a custom IDOC type, or an extension to a standard type. Please delete this
section if the development is an API or web service.

3.1 Business Object

What is the Business Object that the IDOC will represent?

What transaction(s) can be used to see this type of object?

(If known) what tables hold the business object data?

3.2 IDOC Structure

Describe the required IDOC structure, referencing the standard IDOC type if there is one to be extended.

3.3 Inbound Processing

Typically a custom IDOC is needed for only outbound or inbound processing – delete this section if there’s no
inbound processing required.

Specify how the data from the custom parts of the IDOC should be saved. When extending a standard IDOC,
explain where is the standard inbound processing (usually a function module), and is there a known
enhancement point – e.g. a BAdI?

3.4 Outbound Processing

Typically a custom IDOC is needed for only outbound or inbound processing – delete this section if there’s no
outbound processing required.

Specify how the the custom parts of the IDOC should be filled. When extending a standard IDOC, explain
where is the standard outbound processing (usually a function module), and is there a known enhancement
point – e.g. a BAdI?

© 2024 SAP SE or a SAP affiliate company. All rights reserved. Page 5 of 6

FS {WRICEF ID Description}
{Workstream}
{Organisation / Project Name}

4 How to Test

If this is an enhancement to a standard application, then please provide some guidance and/or test data to
help the developer unit test the development. This can be included here or in a separate document.
The developer will need to test repeatedly, so where appropriate provide instructions to reverse the actions
performed so the test may be run again, or explain how to create new input data to the test.

© 2024 SAP SE or a SAP affiliate company. All rights reserved. Page 6 of 6