{Workstream}

FUNCTIONAL SPECIFICATION
ABAP custom development – Enhancements
(Transactions and Apps)

{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: 14/06/2017
FS {WRICEF ID Description}
{Workstream}
{Organisation / Project Name}

Version Date Name Alteration Reason

1 30/04/2023 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 4
2.1 Data Model 4
2.2 User Interface 4
2.3 Enhancement Logic 5
2.4 Application Logic 5
2.5 Flow Diagram 5
2.6 Validation and Error Handling 5
2.7 Authorizations 5
2.8 Extension of Associated Objects for Interfaces, Data Migration and Reporting 6
2.8.1 IDOC 6
2.8.2 APIs: e.g. BAPI, RFC or Web Service 6
2.8.3 LSMW 6
2.8.4 Analytics Data Model (HANA Live or CDS Views) 6
3 How to Test 7

© 2023 SAP SE or a SAP affiliate company. All rights reserved. Page 2 of 7

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

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).

© 2023 SAP SE or a SAP affiliate company. All rights reserved. Page 3 of 7

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

2 Solution Design

This template may be used to specify:

• New custom applications or transactions.
• Major enhancements to SAP standard applications or transactions, for example adding custom fields. For
simple enhancements that don’t involve changes to the data model or user interface, use the
Enhancements (simple) template instead.

2.1 Data Model

If new database tables are required, or extensions to standard tables, then specify the requirements here. You
may prefer to explain the requirements in high-level terms here, and then work directly with the developer or
development lead to agree the detail. But if going into detail…

• For each field a Data Element is required. This defines what the data actually means in business
terms, and carries the text descriptions and long text (F4 help). Existing, SAP standard data elements
should be used as the first choice. Where a new data element is required, then the descriptions, long
text, data type, length, fixed values or foreign keys need to be defined.

Enhancements to other Data Dictionary objects may be specified here too.

2.2 User Interface

If changes to a SAP standard UI are required, then provide screenshots marked up with the changes required
- for example what fields are to be added and where. Also explain here, or as part of How to Test, how the
developer can access the screens in the standard application or transaction. If you know of a BAdI or other
enhancement point to facilitate the changes, then reference it here too.

For entirely new applications, UI technologies available in Business Suite are:

• SAPGUI (Dynpro) – e.g. for any programs to be run in batch

• Web Dynpro and Floorplan Manager (FPM) applications. FPM is a framework built on top of Web
Dynpro.

• Web UI – for CRM; also used by some other solutions.

• SAP UI5 – e.g. Fiori Apps

Consider which technology will be most appropriate – the project/customer may have a policy to follow which
determines this, or check with the development lead.

Please provide a mock-up of the new application’s screens. As well as design of the screens, it is also important
to consider:

• Is any dynamic screen behaviour required? This typically sets the visibility, read-only or mandatory
properties of the UI elements. E.g. if field ‘a’ has a value ‘x’, then make fields ‘b’, ‘c’ and ‘d’ read-only,
and make field ‘e’ mandatory.

• How will the user navigate between screens?

© 2023 SAP SE or a SAP affiliate company. All rights reserved. Page 4 of 7

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

• For simple input fields, does the value need to be validated? Can a value-help be assigned?

• Can tooltips or input prompts be used to help and guide the user?

A prototyping tool such as SAP Build (for UI5) or iRise may be used to mock-up a design. The developers
should follow UI best practice to keep the screens user-friendly and consistent. So either involve a developer
in the prototyping; or provide the mock-up as guidance, and be aware that some of the design details may
change in implementation.

2.3 Enhancement Logic

Changes to existing SAP applications may be made using enhancement techniques such as BAdIs or User
Exits. Specify here the enhancement points to be changed and the logic required. Create a new subsection
for each enhancement to be made, if one than one is required.

Enhancement Spot
BAdI Definition
Method

2.4 Application Logic

For new applications, specify the business logic here. The developer will then build and structure the required
ABAP following the development guidelines. There is no need to specify names or details of development
objects such as classes or transaction codes.

2.5 Flow Diagram

Please illustrate any complex logic requirements with a flow diagram.

2.6 Validation and Error Handling

As far as possible the application should actively prevent the user from taking an invalid course of action, for
example by:

• Using dropdown lists and radiobuttons to restrict input to valid choices

• Making irrelevant fields read-only or hidden

• Keeping buttons inactive unless their functions are relevant at that moment

However sometimes it will be necessary to provide error or warning messages. Please provide the text of any
such messages (short and long), and details of when the message should be raised.

2.7 Authorizations

Authorizations are used to restrict what data and actions a user has access to.

If your application logic involves reading from database tables, then please consider if the data selection should
be restricted by authorization objects - for example by an org unit.

© 2023 SAP SE or a SAP affiliate company. All rights reserved. Page 5 of 7

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

If this is a new Application that maintains a business object, then there may be different options to create,
change, display or delete the object. Such actions should be governed by authorizations – for example it should
be possible to provide display access without any ability to make changes. If the data object is standard, then
an existing authorization object may exist for it; otherwise a new custom object may be required.

2.8 Extension of Associated Objects for Interfaces, Data Migration and Reporting

If a standard business object has been extended with custom fields, then there may be related objects for
Interfaces, Data Migration or Reporting, which also should be extended. Consider if that’s true for each of the
following, and if so state the object the extend.

2.8.1 IDOC

2.8.2 APIs: e.g. BAPI, RFC or Web Service

2.8.3 LSMW

2.8.4 Analytics Data Model (HANA Live or CDS Views)

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

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

3 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.

© 2023 SAP SE or a SAP affiliate company. All rights reserved. Page 7 of 7