Customizing SHANA Treasury

S4F51
Customizing in Treasury and Risk

Management in SAP S/4HANA
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 17
Course Duration: 5 Day(s)
Material Number: 50155855
SAP Copyrights, Trademarks and
Disclaimers
© 2021 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials may have been machine translated and may contain grammatical errors or
inaccuracies.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.
© Copyright. All rights reserved. iii

Typographic Conventions
American English is the standard used in this handbook.

The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Demonstration
Procedure
Warning or Caution
Hint
Related or Additional Information
Facilitated Discussion
User interface control Example text
Window title Example text
iv © Copyright. All rights reserved.

Contents
ix Course Overview
1 Unit 1: Overview of Financials for SAP S/4HANA
3 Lesson: Describing SAP HANA and SAP S/4HANA
17 Unit 2: Customizing in Treasury and Risk Management in SAP S/4HANA
19 Lesson: Understanding the SAP Treasury and Risk Management

Solution
34 Lesson: Maintaining Business Partner Settings
49 Exercise 1: Create a Business Partner
71 Lesson: Defining House Bank Accounts
75 Lesson: Defining Securities-Related Master Data
79 Exercise 2: Create a Securities Account
85 Exercise 3: Create Securities Class Data
93 Unit 3: General Configuration Settings
95 Lesson: Configuring the Company Code

97 Lesson: Defining Valuation Areas
103 Lesson: Configuring the Valuation Class
© Copyright. All rights reserved. v

109 Unit 4: Transaction Manager – Basic Customizing for all Products
112 Lesson: Creating Traders and Portfolios

119 Exercise 4: Create Trader and Portfolio
123 Lesson: Defining Trade Types
135 Exercise 5: Maintain Product and Transaction Types in Money
Market
143 Exercise 6: Assign Flow Types
149 Exercise 7: Assign Condition Types and Default Valuation Class
157 Exercise 8: Create Fixed-Term Deposit Transaction
171 Exercise 9: Maintain Product and Transaction Types in Foreign
Exchange
179 Exercise 10: Maintain Flow Types for FX Transactions
183 Exercise 11: Define Open and Close Position Cash Flows
187 Exercise 12: Create a Foreign Exchange Forward Contract
201 Exercise 13: Define Product and Transaction Types for
Derivatives
207 Exercise 14: Assign Flow Types for Derivative Product Types
213 Exercise 15: Assign Condition Types for Derivatives
217 Exercise 16: Define Derivative Open and Close Position Update
Types
221 Exercise 17: Create Derivative Transactions
241 Exercise 18: Define a Securities Product Type
253 Exercise 19: Basic Settings for Transaction Management
273 Exercise 20: Create a Security Trade
293 Lesson: Maintaining Derived Flows
297 Lesson: Using the Deal Release Workflow
301 Exercise 21: Implement the Deal Release Workflow
307 Lesson: Defining Position Management
319 Exercise 22: Create a Position Management Procedure
327 Lesson: Valuing Trades
341 Lesson: Defining Derived Business Transactions
347 Lesson: Understanding Interest Accruals
353 Exercise 23: Carry Out Settlement and Interest Accrual
359 Lesson: Configuring Account Determination
371 Exercise 24: Link to Accounting
379 Lesson: Replacing LIBOR
401 Unit 5: Additional Configuration
403 Lesson: Maintaining Company Code Additional Information

407 Lesson: Entering Trade Field Selection
411 Exercise 25: Change Trade Field Status
417 Lesson: Establishing the Cash Management Integration
423 Lesson: Mirroring of Trades
vi © Copyright. All rights reserved.

431 Unit 6: Back Office Functions Customizing
432 Lesson: Configuring the Correspondence Monitor

453 Exercise 26: Correspondence Activities
463 Exercise 27: Execute Correspondence
473 Lesson: Using the Payment Program
493 Exercise 28: Execute the Treasury Payment Run
507 Lesson: Using the Trade Repository
513 Unit 7: Hedge Management and Accounting
515 Lesson: Defining Exposure Management

525 Exercise 29: Create Exposure Activity Type and Reference
Based Exposure
537 Lesson: Understanding the SAP Hedge Management Solution
576 Lesson: Creating Reference Based Hedging Areas
583 Exercise 30: Create Hedging Classification
585 Exercise 31: Create a Reference-Based Hedging Area
596 Lesson: Customizing Hedge Management Elements
607 Exercise 32: Customize Hedge Management
613 Exercise 33: Update a Reference Based Hedging Area and
Create FX Trade
621 Lesson: Understanding FX Options Process and Customizing
629 Lesson: Understanding Hedge Accounting
641 Unit 8: Market Data
642 Lesson: Defining Market Data

655 Exercise 34: Reference Interest Rates and Yield Curves
675 Exercise 35: Define Credit Spreads
687 Lesson: Importing Market Data into SAP
695 Unit 9: Risk Management
696 Lesson: Configuring the Market Risk Analyzer

711 Exercise 36: Define Market Data Settings and Structures
721 Exercise 37: Define the Basic Analyzer Settings
731 Exercise 38: Define Value at Risk
742 Lesson: Credit Risk Analyzer
755 Exercise 39: Activate the Credit Risk Analyzer Integration
773 Exercise 40: Set Up Limit Types and Limits
779 Exercise 41: Set Up the Limit Management Application
© Copyright. All rights reserved. vii

789 Unit 10: Commodities
791 Lesson: Understanding Commodities

794 Lesson: Defining Commodities Basic Data
799 Exercise 42: Define Commodity Market Data Elements
805 Lesson: Understanding Derivative Contract Specifications
811 Lesson: Defining Period Determination
814 Lesson: Defining Commodity Trade Types
819 Exercise 43: Define Product and Transaction Type
Commodities
825 Exercise 44: Assign Flow Types Commodity Product Types
829 Exercise 45: Define Open and Close Position Commodities
833 Exercise 46: Create a Commodity Transaction
viii © Copyright. All rights reserved.

Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
● Industry / Business Analyst Consultant
© Copyright. All rights reserved. ix

x © Copyright. All rights reserved.
UNIT 1 Overview of Financials for SAP
S/4HANA
Lesson 1
Describing SAP HANA and SAP S/4HANA 3
UNIT OBJECTIVES
● Describe SAP S/4HANA and SAP Fiori
© Copyright. All rights reserved. 1

Unit 1: Overview of Financials for SAP S/4HANA
2 © Copyright. All rights reserved.

Unit 1
Lesson 1
Describing SAP HANA and SAP S/4HANA
LESSON OBJECTIVES
After completing this lesson, you will be able to:
SAP S/4HANA Core Products
Figure 1: Evolution of SAP Products
SAP SE is a software corporation that provides enterprise software applications and support
to businesses of all sizes globally. Headquartered in Walldorf, Germany, with subsidiaries
around the world, SAP is the largest enterprise software company in the world (as of 2016). It
is also the largest software company in Europe and the fourth largest globally, with more than
100,000 customers.
Since the beginning of enterprise computing, SAP have been rebuilding the business
applications whenever major technology shifts have occurred. Some key moments in SAP’s
application development history are the following:
● 1979 – SAP invents ERP. SAP builds standard business software based on mainframe
technology. The name, SAP R/2, supports and integrates major business functions in real
time and handles multi-country and multi-currency implementations. (R means real time,
and although there was an R/1, this is not regarded as the first major release.)

● 1992 – With the rise of the personal computer, the introduction of client/server
architecture means another rewrite of the applications to exploit the power of a layered,
three-tier architecture approach, in which processing is split across three layers: client,
application, and database. It is the end of the mono-chromatic, text-based, messy green
screens and the start of a new graphical interface to improve the end user experience. This
is the birth of SAP R/3.
● 2004 – Now the Web is firmly established as the common business network and
customers demand better integration between their business applications and the Web.
SAP develops a new integration application platform called SAP NetWeaver in order to
enable this. Now all SAP applications run on a common platform, and customers and
partners can build and integrate existing applications easily using widely adopted Web
standards, such as service-oriented architecture (SOA). Additionally, a little later, a new
switch framework is introduced to allow customers to selectively enable only the new
functions developed by SAP in order to avoid disrupting their core processes. The SAP R/3
name is now replaced by SAP ERP. ERP is part of a larger family known as SAP Business
Suite, which also contains many other line of business (LOB) applications from SAP, such
as SAP CRM.
● 2015 – A new wave of advances in hardware architecture brings massive computing power
at decreasing costs. Huge memory and multi-core processors arrive to offer massive
computing power. The underlying design of existing SAP applications was not fully
exploiting the power of the new hardware. A rewrite of the complete Business Suite is
required. The new business suite is called SAP S/4HANA.
Main SAP ERP Core Products
Figure 2: Key Aspects of SAP S/4HANA
Animation: Key Aspects of SAP S/4HANA

For more information on Key Aspects of SAP S/4HANA, please view the
animation in the lesson Describing SAP HANA and SAP S/4HANA, online in the
SAP Learning Hub.

Lesson: Describing SAP HANA and SAP S/4HANA
SAP S/4HANA is built on SAP HANA, and so we inherit all the capabilities of this powerful in-
memory data management and application platform. This includes advanced text mining,
predictive analysis, simulations, and powerful real-time decision support, with access to any
type of data in real time.
A brand new user experience is delivered to improve the productivity and satisfaction of
business users and brings the interface up to a consumer-grade experience optimized for any
device.
SAP S/4HANA can be deployed on premise or in the cloud or a combination of both to
provide flexible consumption options to customers.
The data model has been massively simplified. This means we lost unnecessary tables and of
course the data in those tables in order to shrink the footprint dramatically and simplify the
application design and extensibility.
SAP S/4HANA Product Portfolio
Figure 4: SAP S/4HANA Product Portfolio
Animation: SAP S/4HANA Product Portfolio

For more information on SAP S/4HANA Product Portfolio, please view the
SAP Learning Hub.
SAP S/4HANA is not a single product, but covers many applications. Customers can start
with the basic components and add others later. SAP S/4HANA Enterprise Management is a
great place to start. This is known as the “simplified core”. It is helpful to think of SAP S/
4HANA Enterprise Management as the replacement for SAP ERP. It offers support for all core
business processes, such as quotation to cash, procure to pay, and so on. For many
customers, this is where their SAP S/4HANA adoption begins.
SAP S/4HANA Lines of Business (LoB) solutions seamlessly integrate with the core. There
are options that can be added at any time, and provide best-in-class lines of business

solutions and connections to SAP business networks. Customers carefully choose the LOB
solutions that suit their businesses in order to extend the functionality of the core.
In the past, we had multiple add-on applications surrounding the core (for example, SAP CRM
and SAP SRM surrounded the core ECC), but with overlapping models and much redundancy.
Overlaps and redundancy have been completely removed from SAP S/4HANA.
A key point is that SAP S/4HANA is built natively and optimally to run only on the SAP HANA
platform.
Core Processes within SAP S/4HANA
Figure 6: Core Processes Within SAP S/4HANA
There are two key layers in the SAP S/4HANA application framework.
SAP S/4HANA Enterprise Management

SAP S/4HANA Enterprise Management represents the core solution, covering all
mission-critical processes of an enterprise. It represents the foundational core solution,
natively built on the SAP HANA platform and designed with SAP Fiori UX.
For customers who are coming from an existing SAP applications background, Enterprise
Management can be loosely compared to SAP ERP. However, SAP S/4HANA is a
completely new set of applications. Although there are many similarities to SAP ERP,
many of the processes are redesigned, so there is often not a simple one-to-one
comparison with traditional transactions.
SAP S/4HANA Line of Business

SAP S/4HANA Line of Business (LoB) solutions provide much broader and deeper
functionality to support organizations in strategic areas, where they want to fully exploit
innovative digital applications. LoB solutions can be on premise or in the cloud. The key
point is that you extend the core by adding LoB solutions. The overall solution is
extended seamlessly. When LoB solutions are added, the business users have the same
SAP Fiori-based user experience as before, with the same SAP HANA-based high
performance.

Animation: Core Processes Within SAP S/4HANA

For more information on Core Processes Within SAP S/4HANA, please view the
SAP Learning Hub.
SAP S/4HANA Enterprise Management is very broad and includes support for key end-to-end
business processes, including the following:
● Procure to pay
● Plan to product
● Order to cash
● Request to service
Remember, core HR and core finance are also included in Enterprise Management, rather
than only logistics and operations applications.
For all these areas, there are additional LoB solutions that can be added to significantly
extend the functionality and provide innovation on top of the core.
SAP S/4HANA Enterprise Management is the digital core and represents the starting point on
which modern, innovative digital applications are implemented and built.
SAP ERP is an integrated computer-based system used to manage internal and external
resources, including tangible assets, financial resources, materials, and human resources. Its
purpose is to facilitate the flow of information between all business functions inside the
boundaries of the organization and manage the connections to outside stakeholders. Built on
a centralized database and normally utilizing a common computing platform, ERP systems
consolidate all business operations into a uniform and enterprise-wide system environment.
Evolution of the Finance Application
Figure 8: Evolution of the Finance Application

Animation: Evolution of the Finance Application

For more information on Evolution of the Finance Application, please view the
SAP Learning Hub.
Beginning with ECC 5.00, SAP customers had the choice between two different forms of
financial accounting:
● Classic General Ledger Accounting
● New General Ledger Accounting
Both options were part of an SAP ERP running on a traditional database.

After introducing the SAP HANA database technology, SAP offered its customers the
opportunity to enhance and speed up FI and CO processes not only by using the new and
faster database technology but also by using a set of accelerators especially designed for
using SAP Financials on an SAP HANA technology. Still classic and new G/L were the two
options for SAP’s customers.
With SAP S/4HANA and SAP Accounting within SAP S/4HANA Finance, there is only one
possibility for general ledger accounting which bases on the functionalities of the former new
general ledger accounting.
Overview on the Functionality of SAP S/4HANA Finance
Figure 10: Overview on the Functionality of SAP S/4HANA Finance

Animation: Overview on the Functionality of SAP S/4HANA Finance

For more information on Overview on the Functionality of SAP S/4HANA
Finance, please view the animation in the lesson Describing SAP HANA and SAP
S/4HANA, online in the SAP Learning Hub.
SAP provides a fully integrated platform, based on the latest technology trends, to allow
finance to lead the transformation to digital business.
SAP S/4HANA Finance gives you the ability to centrally track financial accounting data within
an international framework of multiple companies, languages, currencies, and charts of
accounts.
For example, when raw materials move from inventory into manufacturing, the system
reduces the quantity in inventory and simultaneously subtracts values for inventory accounts
in the balance sheet. The Financial Accounting function complies with international
accounting standards, such as United States Generally Accepted Account Principles (US-
GAAP) and International Financial Reporting Standards (IFRS). It also fulfills local legal
requirements of many countries and fully reflects the legal and accounting changes resulting
from European market and currency unification.
Key features and functions of Financial Accounting in SAP S/4HANA Finances:
● General Ledger Accounting
● Accounts Receivable or Accounts Payable
● Fixed Assets
● Banks
● Fast-Close Functions
● Financial Statements
● Parallel Valuation
Management Accounting in SAP S/4HANA Finance

Management Accounting (Controlling) enables the valuation and recording of financial data,
not only for financial reporting, but also as the basis for all cost and revenue-related reporting.
As a result, analysts and managers can work with the same basic data as the company’s
financial accountants. Because financial data is tightly integrated with the business processes
of the logistic processes of SAP S/4HANA and human resources applications, users can also
easily obtain detailed information about cost structures and profit margins.
Easy access to this data helps support and enable management to achieve business goals,
such as increasing revenue, maximizing customer profitability, and reducing operating costs
while increasing efficiency, reducing the cost of goods sold, and improving the visibility of
inventory.
Key features and functions of Management Accounting in SAP S/4HANA Finance:
● Cost Element Accounting
● Cost Center Accounting
● Internal Orders

● Product Cost Controlling

● Profitability Analysis
● Revenue and Cost Planning
● Budgeting
SAP Fiori
Scenario
You want to ensure that everybody working with the system has the best possible experience
when interacting with SAP S/4HANA, and that everybody can access business critical
applications on any device without compromises. You need a solution that integrates with
your existing IT system landscape and that can expand to cover your specific needs. You want
to make sure that SAP Fiori meets these requirements.
SAP Fiori User Experience Paradigm
Figure 12: SAP Fiori User Experience Paradigm
There are five pillars to the SAP Fiori user experiences paradigm:
● Role-based: Users have access to the applications they need to perform their tasks. The
applications are specific to completing this task.
● Responsive: The application interface is responsive; it adapts to the size and device used
by users accessing it.
● Simple: Simple application scope – one user, one use case, and up to three screens for
each application.
● Coherent: The applications are developed with a coherent structure. All apps speak the
same language, and can be implemented in multiple landscapes and environments.
● Instant value: Instant value through a low adoption barrier, both on the IT-system side and
on the user-adoption side.
Animation: SAP Fiori User Experience Paradigm

For more information on SAP Fiori User Experience Paradigm, please view the
SAP Learning Hub.

What is SAP Fiori?
Figure 14: SAP Fiori Application Types
Animation: SAP Fiori Application Types

For more information on SAP Fiori Application Types, please view the animation
in the lesson Describing SAP HANA and SAP S/4HANA, online in the SAP
Learning Hub.
SAP Fiori applications can be classified into different types. Examples include the following:
● Transactional: These follow an optimal design for fast transaction processing, such as
purchase receipt entry. Transactional apps offer task-based access to tasks like change,
create, display (documents, master records), or entire processes with guided navigation.
● Analytical: Provide tools required for analysis, graphs, charts, exploration, data mining,
and drilldown. Analytical apps provide insight to action. They give you a visual overview of
complex topics for monitoring or tracking purposes.
● Factsheet: Provide a 360 degree view of all key information related to a business subject.
For example, enter an employee name and all information about that employee appears,
such as working hours, vacation, pay, performance, manager, and awards. Factsheets give
you the opportunity to search and explore your data. They provide a 360 degree view on
essential information about an object, and contextual navigation between related objects.
This is a good example of the SAP Fiori approach, which is to use a limited number of
consistent interfaces to keep things simple.

When developers create a new SAP Fiori application, they begin by selecting a template that is
based on transactional, analytical, or factsheet, so they have a consistent look and feel.
SAP Fiori Launchpad — One Entry Point for the User
Figure 16: SAP Fiori Launchpad
The SAP Fiori Launchpad is a shell that hosts SAP Fiori apps and provides services, such as
navigation, personalization, embedded support, and application configuration. It is the entry
point to SAP Fiori apps on mobile and desktop devices. The launchpad displays a home page
with tiles, which can display live status indicators, such as the number of open tasks. Each tile
represents a business application that the user can launch.
The SAP Fiori apps on the home page are arranged in tile groups. The user can personalize
the layout of the home page, by grouping, moving, and removing tiles. The user can also add,
delete, rename, and reorder groups. The ability to personalize the home page must be
enabled in the launchpad configuration.
To add tiles to groups, the launchpad provides a tile catalog, which displays all the tiles that
are available to a user.

SAP Fiori Launchpad User Personalization
Figure 17: User Personalization
Animation: User Personalization

For more information on User Personalization, please view the animation in the
lesson Describing SAP HANA and SAP S/4HANA, online in the SAP Learning
Hub.
The following personalization options are available in SAP Fiori Launchpad:

● Adding applications from the catalog
● Removing applications that should no longer be used
● Modifying and adding applications for filtered report results
For example, if the user is a group cash manager who is interested in the German market, the
user can create an application to take them directly to the cash position of the German
market. They can arrive at the cash position directly with one click from the SAP Fiori
launchpad home page.
LESSON SUMMARY
You should now be able to:


Unit 1
Learning Assessment
1. _____ provide essential information about an object, and contextual navigation between
related objects.
Choose the correct answer.
X A Analysis sheet
X B Transaction sheet
X C Factsheet
X D Hedge sheet

Unit 1: Learning Assessment

UNIT 2 Customizing in Treasury and
Risk Management in SAP S/
4HANA
Lesson 1
Understanding the SAP Treasury and Risk Management Solution 19
Lesson 2
Maintaining Business Partner Settings 34
Exercise 1: Create a Business Partner 49
Lesson 3
Defining House Bank Accounts 71
Lesson 4
Defining Securities-Related Master Data 75
Exercise 2: Create a Securities Account 79
Exercise 3: Create Securities Class Data 85
UNIT OBJECTIVES
● Describe the course goals and objectives

● Provide a functional overview of SAP Treasury and Risk Management
● Understand business partners
● Maintain business partner settings
● Configure business partner workflows
● Check business partner settings in the application
● Define house bank accounts
● Define securities-related master data

Unit 2: Customizing in Treasury and Risk Management in SAP S/4HANA

Unit 2
Lesson 1
Understanding the SAP Treasury and Risk
Management Solution
LESSON OBJECTIVES
Course Objectives
Figure 19: Course Objectives
This course provides insight into how to implement SAP Treasury and Risk Management as
part of SAP S/4HANA. You will learn how to execute the most important configuration steps,
specifically, the key customizing steps for Transaction Manager, Exposure Management, and
the Market and Credit Risk Analyzers.
The knowledge of the course S4F50 'Business Processes in SAP Treasury and Risk
Management in SAP S/4HANA' or equal knowledge is a mandatory prerequisite.

Overview of SAP Treasury and Risk Management
Figure 20: Overview of Treasury and Risk Management
Animation: Overview of Treasury and Risk Management

For more information on Overview of Treasury and Risk Management, please
view the animation in the lesson Understanding the SAP Treasury and Risk
Management Solution, online in the SAP Learning Hub.
SAP's Transaction Manager module tracks Treasury trades through their full life cycle – from
trade entry to payments to month-end processing to maturity of the trades. All accounting
entries related to the trades are triggered by the trades and are posted directly to the SAP
General Ledger.
Transaction Manager configuration is extensive when considering the several submodules
within Transaction Manager (e.g., Money Market, Foreign Exchange, Securities, Derivatives,
Commodities, and Trade Finance).
The Transaction Manager modules integrate well into other SAP modules, such as Cash
Management and Financial Accounting.
Transaction Manager configuration is consistent wherever possible across different trade
types. For example, there are basic differences between money market trades and derivative
trades. Derivative trades have underlying assets, but money market trades do not. The
configuration required for the different trade types is going to be different but is largely going
to be driven by the definition of the product and transaction type configuration.
Financial Instruments in SAP

The core component of the SAP Treasury solution is covering financial instruments. A wide
variety of financial instruments is available in SAP: These are divided into the following
groups:
● Money Market transactions for short, mid, and long-term investments and borrowing.

Lesson: Understanding the SAP Treasury and Risk Management Solution
● Foreign Exchange transactions for all types of spot and forward transactions, including
swaps, plain vanilla options and many exotic options, through to knock-in and knock-out
structures and average rate options.
● Loans cover both bilateral contracts, such as bank loans and syndicated contracts, issuing
programs and facilities.
● Derivatives cover many types of OTC derivatives, such as caps and swaps as well as
futures and options dealt on the stock exchange.
● Securities contain both bonds and stocks, with all types of rights and corporate actions.
Active, passive, and lending position can be managed.
● Different types of Commodities. Matching of long/short future position and margin
management.
● Trade Finance which includes instruments such as letters of credit and bank guarantees.
SAP Treasury: Analyzers

Transaction Manager covers the management of deals and requirements for the front,
middle, and back office, as well as accounting. SAP Treasury provides the following Analyzers.
Market Risk Analyzer and Credit Risk Analyzer will be covered in unit 9.
● Market Risk Analyzer (e.g. NPV, Sensitivity key figures, value at risk)
● Portfolio Analyzer (calculates the yield on balances, including benchmarking)
● Credit Risk Analyzer (manages limits and calculates utilization for the front office and risk
controlling)
● Accounting Analyzer (calculation of accounting key figures)
Figure 22: Hedge Management Solution
The SAP Treasury and Risk Management solution includes the following components:
● Master Data (House Bank Accounts, Business Partner, Securities Account, Future
Account, Security Class)
● Transaction Manager (Front, Middle, Back Office and Accounting)
● Market Data Management (e.g. Currency Rates, Yield Curves)

● Risk Management (Market Risk Analyzer, Credit Risk Analyzer, Portfolio Analyzer,
Accounting Analyzer)
● Payment Program
● Hedge and Exposure Management
In addition, there is integration with the Cash Management module, as well as other
components in SAP S/4HANA Finance.
Transaction Manager provides you with the instruments you require to process the
appropriate financial transactions, from entering the relevant data right down to transferring
it to Financial Accounting. Both conventional Treasury departments and Asset Management
departments are supported with a trading-related focus. This has the advantage that all types
of transaction – from short-term financing to strategic long-term investment – can be
processed on the same platform.
The FX Risk Management process uses the Trading Platform Integration SCP App as the
connection between the FX Trading Platform, such as 360T or FXAll, and SAP’s Treasury and
Risk Management module. With the use of the Trading Platform Integration app and the
functionality delivered in Treasury and Risk Management, companies can have an FX trading
process that is very automated and requires little manual interaction.
Figure 23: Understanding Key Date Valuations
Animation: Understanding Key Date Valuations

For more information on Understanding Key Date Valuations, please view the
animation in the lesson Understanding the SAP Treasury and Risk Management
Solution, online in the SAP Learning Hub.
Before proceeding, consider the treasury process flow shown here. Throughout the day,
payments related to Treasury processing accumulate and will need to be transferred to the
banks. Using straight-through processing of payments is best so there is no re-entry of
payment details.

Figure 25: Support Throughout the Trade Life Cycle
Animation: Support Throughout the Trade Life Cycle

For more information on Support Throughout the Trade Life Cycle, please view
the animation in the lesson Understanding the SAP Treasury and Risk
Entering into financial transactions is a task carried out by most financial departments.
Depending on the corporate policy, the emphasis here may be placed on providing an internal
service focused on the associated group companies or on actively investing liquid funds,
financing planned investments, or hedging existing risks in the financial markets.
The transaction management processes are split into the following areas:
● In the front office department, you create transactions and exercise rights.
● In the middle office, you validate the transactions, that is, you check the entered
transactions and carry out position management-related processes such as securities
account transfers. You manage the correspondence (e.g. dealing slip, confirmation, and
counter-confirmation) process.
● Back Office/Accounting covers the accounting treatment of the relevant activities in the
subledger and the transfer of the posting information to the SAP General Ledger. At
closing, valuation and interest accrued is carried out for each subledger position to the
SAP General Ledger.
For securities and traded derivatives/commodities, a position management process is

defined in addition to the transaction management process. The resulting posting activities
are automatically transferred to Financial Accounting. Enter master data (e.g. commodity ID,
security class, security account) settings before you can start the transaction management
process. For example, before you can map the purchase (or sale) of a security in the system,
you first have to enter its relevant structure and condition characteristics as a class. You can
use master data as well as transactions and positions to create reports in the information
system.

Treasury and Risk Management Customizing
Figure 27: Treasury and Risk Management Customizing
Once you understand the processing and configuration for one trade type, it is easy to build
on that knowledge to other trade types, such as Foreign Exchange or Derivative trades.
Configuration for types of trades across all Transaction Manager submodules requires the
following:
● Define Accounting Codes
● Assign Accounting Codes to Valuation Areas
● Definition of Product Type
● Definition of Transaction Types
● Definition of Flow Types
● Definition of Update Types and Assign Usages
● Set Effects of Update Types on Position Components
● Derived Business Transactions
● Account Determination
In addition, the valuation class, position management procedure and account assignment
reference are required fields for trades across all Transaction Manager submodules.
Note: The above list is not an exhaustive list. There are other configuration nodes that are
relevant to all Transaction Manager trade types.
Said another way, although the settings for each of the above configuration nodes could be
different across the different trade types, understanding the structure of the trades and the
configuration process for Money Market trades is going to be helpful in understanding how to
configure Foreign Exchange or Derivative trades.

Figure 28: Overview of SAP Treasury and Risk Management
Animation: Overview of SAP Treasury and Risk Management

For more information on Overview of SAP Treasury and Risk Management,
please view the animation in the lesson Understanding the SAP Treasury and
Risk Management Solution, online in the SAP Learning Hub.
The process flow shown above references the components covered in this course.
Note: The Bank Communication Management (BCM) and In-House Cash (IHC) modules, and
the Accounting Analyzer, will not be covered in this course.

Corporate Treasury: The Strategic Role, Main Tasks and Challenges
Figure 30: Corporate Treasury: The Strategic Role and Main Tasks
Strategic or tactical
Much has been written over the years about the role of treasury. The modern treasury group
is strategic, collaborates with the businesses it serves, and is using automation, offshoring
and treasury centers of excellence to consolidate and standardize tactical areas.
CFO mandates
Treasurers clearly have strong mandates to be strategic. More than 70% of respondents
noted the following mandates from their CFOs:
● Liquidity risk management
● Efficient capital markets access
● Steward for risk management company
● Strategic advisor to the business
● Value-add partner to the CFO in areas such as mergers and acquisitions (M&A)
● Leading, governing and driving working capital improvement initiatives
● Enhanced governance and control over domestic and overseas operations
● Creation of scalable treasury organization to support company growth
Animation: Corporate Treasury: The Strategic Role and Main Tasks

For more information on Corporate Treasury: The Strategic Role and Main Tasks,
please view the animation in the lesson Understanding the SAP Treasury and
Risk Management Solution, online in the SAP Learning Hub.

Source: survey by Deloitte 2015:

Responses were received from the treasury groups of more than 100 top corporations from
around the globe, representing a wide array of global scales, industrial footprints, and
geographic headquarters.
Figure 32: The Strategic Challenges Treasury Organizations Face
Key challenges persist

Fifty percent of treasurers noted their biggest challenges are the ability to repatriate cash and
to manage foreign exchange (FX) volatility. These challenges continue, despite the ongoing
trend toward leveraging technology solutions.
The primary challenges facing treasury groups today have not yet been resolved with the
increased investment in treasury technology, a trend over the past few years. Inadequate
systems, FX management, and visibility to global operations continue to be difficult. Most
corporate treasury groups rely on multiple ERPs for data sources and use multiple solutions
(some manual) to address their company's needs. This may lead to increased operational
difficulties and risk rather than providing sufficient solutions to address these challenges.
Source: survey by Deloitte 2015

Key Drivers SAP Identified: Input for Further Development of the SAP Treasury Solutions
and S/4HANA Use
Figure 33: Key Drivers SAP Identified: Input for Further Development of the SAP Treasury Solutions and S/
4HANA Use
Figure 34: Treasurers Task Profiles and the SAP Solutions Provided
Our training: SAP Treasury and Risk Management. Separate trainings exist for Cash and
Liquidity Management, Payments and Bank Communication.
TRM: Treasury and Risk Management.

Figure 35: An Integrated Solution: Connectivity and Coordination
Strong treasury and cash management are critical needs in times of reduced bank lending
and general liquidity challenges. Businesses need cash to operate, and when it can't be
procured easily from outside, it must be generated and conserved from within. In addition,
today's challenges in treasury and cash management are very different from that several
years ago. This all puts significant additional pressure on corporate treasury operations to
adapt and evolve.
Today more than ever, companies need to better integrate their treasury functions into their
overall finance operation, to gain both efficiency, as well as effectiveness. Their older treasury
and cash silos can no longer remain stand-alone, but must become more integrated with the
cash generating (accounts receivable) and cash depleting (accounts payable) operations of
the company, so that every economy can be gained, and every impact to daily cash position
can be predicted and understood. Enterprises rightfully expect the treasury function to
provide real-time analysis of cash positions and an apparatus to allocate cash to strategic
locations and geographies instantaneously, or to procure it if it is needed from the most
efficient and lowest-cost source.
New standards for financial reporting also require better functions and controls. Treasury
managers need analytical and transactional tools to execute trades and hedging transactions
that are visible, and comply with accounting standards and that are auditable. In short, much
more coordination and visibility is required by today's corporate treasury function across the
board, and much tighter integration with operational and enterprise finance and accounting
systems.

Overview Treasury and Risk Management Customizing
Figure 36: Overview of Treasury and Risk Management Customizing
Animation: Overview of Treasury and Risk Management Customizing

For more information on Overview of Treasury and Risk Management
Customizing, please view the animation in the lesson Understanding the SAP
Treasury and Risk Management Solution, online in the SAP Learning Hub.
Customizing is entered in a development system and is captured in a transport. A transport

request in SAP simply refers to a method by which you can modify customizing, capture the
changes, and then move them to other systems, such as a quality assurance system, and
then to production.
The customizing changes should be tested both in the development system and the quality
assurance system before being moved to the production environment.
The exact landscape used may vary by customer but typically there is a development, QA, and
productive environment.
Figure 38: SAP Reference IMG

Animation: SAP Reference IMG

For more information on SAP Reference IMG, please view the animation in the
lesson Understanding the SAP Treasury and Risk Management Solution, online in
the SAP Learning Hub.
To get to the customizing menu, enter SPRO in the transactions box, then press on the SAP
Reference IMG button, as shown above.
Following these steps will take the user to the SAP customizing menu. It is from the SAP
customizing menu where changes to customizing are made.
Figure 40: IMG - Financial Supply Chain Management
Animation: IMG - Financial Supply Chain Management

For more information on IMG - Financial Supply Chain Management, please view
the animation in the lesson Understanding the SAP Treasury and Risk
All the Treasury and Risk Management customizing is found on the SAP customizing menu
under Financial Supply Chain Management. The Treasury and Risk Management customizing
is structured into organized sub-node. For example, the above slide shows where the
business partner customizing nodes can be found and where the customizing related to
market data management is entered.

Figure 42: IMG - Transaction Manager
Animation: IMG - Transaction Manager

For more information on IMG - Transaction Manager, please view the animation
in the lesson Understanding the SAP Treasury and Risk Management Solution,
online in the SAP Learning Hub.
The screenshot above shows where the customizing across the Transaction Manager
submodules is done, as well as where the customizing nodes for Market Risk Analyzer and
Credit Risk Analyzer can be found.
Customizing for types of trades across all Transaction Manager sub-modules requires the
following:
In addition, the valuation class, position management procedure and account assignment
reference are required fields for trades across all Transaction Manager sub-modules.

Note: The above list is not an exhaustive list. There are other customizing nodes that are
relevant to all Transaction Manager trade types.
Figure 44: IMG - Money Market
Animation: IMG - Money Market

For more information on IMG - Money Market, please view the animation in the
lesson Understanding the SAP Treasury and Risk Management Solution, online in
The screenshot above shows the main customizing nodes for Money Market trades. This
customizing drives the characteristics of the Money Market trades. The customizing nodes
under the Transaction Manager submodules, e.g. Foreign Exchange, Securities, etc., are
organized similarly. Understanding the structure of the trades and the customizing process
for Money Market trades is going to be helpful in understanding how to configure Foreign
Exchange or Derivative trades.
Once you understand the processing and customizing for one trade type, it is easy to expand
that knowledge to other trade types.
LESSON SUMMARY

Unit 2
Lesson 2
Maintaining Business Partner Settings
LESSON OBJECTIVES
Business Partner Overview
Figure 46: Business Partner Overview
Before entering business transactions in the Transaction Manager module, business partner
customizing settings must be done and then business partners can be created.
In this lesson, the following will be covered:
● Steps to create business partners
● Business partner general data
● Company code dependent settings (also known as standing instructions)
● Relevant business partner roles (examples: counterparty, issuer, depository bank)
One of the first steps in a Transaction Manager implementation is to define on SAP the
business partners.

Lesson: Maintaining Business Partner Settings
Figure 47: Treasury Process Review
Animation: Treasury Process Review

For more information on Treasury Process Review, please view the animation in
the lesson Maintaining Business Partner Settings, online in the SAP Learning
Hub.
This slide reviews the Treasury trade process flow on SAP. In the front office processing, the
traders make decisions of the trades to enter into, then the trades are then created on SAP.
As part of middle office processing, the trades are reviewed and approved. Often details of the
trades are sent to the counterparties to ensure all trade details are correct. As the trade is
created in SAP, it is automatically reflected in the cash position report. Next, as part of back
office processing, the trades are posted to the SAP general ledger, and trade cash flows are
paid using the Treasury payment program.
Figure 49: Business Partner Master Data Activities

Animation: Business Partner Master Data Activities

For more information on Business Partner Master Data Activities, please view the
animation in the lesson Maintaining Business Partner Settings, online in the SAP
Learning Hub.
A prerequisite to creating trades is to have business partners created and standing

instructions set-up, both of which are master data activities.
Business Partner Role Concept
Figure 51: Overview of the Business Partner
Animation: Overview of the Business Partner

For more information on Overview of the Business Partner, please view the
Learning Hub.
There are two types of business partner master data. The first is the general settings, which
apply across all company codes. This includes the name, address, and contact information for
the business partner. Next, is the company code specific information, which is referred to as
standing instructions on SAP.
Within the Treasury and Risk Management, financial transactions are executed by means of
the business partner. Typical partners are bank branches or company subsidiaries. You
create a master data record for each business partner. The business partner master record
holds all relevant information for the business partner on SAP.
There are two areas of the maintain business partner master record:
1. General role data is stored centrally for all roles. The data may vary according to the role
category and depending on the settings in customizing.

2. Company code specific data that only applies for the role in the respective company code.
Company code specific settings are part of the standing instructions.
Figure 53: Business Partner (General Settings)
The general settings apply across all company codes. This includes the basic name, address,
and contact information for the business partner.
The address settings are relevant for the communication (e.g. Correspondence, Payment).
Depending on the correspondence type, the following information is required:
● E-Mail address
● Fax number
● SWIFT code
Figure 54: Master Data - Maintaining Business Payment Instructions
Animation: Master Data - Maintaining Business Payment Instructions

For more information on Master Data - Maintaining Business Payment
Instructions, please view the animation in the lesson Maintaining Business
Partner Settings, online in the SAP Learning Hub.
The payment transactions, which are the business partner's bank accounts, are part of the
business partner general settings.
Payment Transactions: Set up the relevant bank settings for this business partner, which you
can later use in the payment transactions standing instructions.

Figure 56: Company Code-Dependent Settings (Standing Instructions)
Animation: Company Code-Dependent Settings (Standing Instructions)

For more information on Company Code-Dependent Settings (Standing
Instructions), please view the animation in the lesson Maintaining Business
The company code-dependent settings are referred to as standing instructions on SAP.

The three types of information above for the business partner data are known as standing
instructions. They are:
Authorizations
● Which are the financial transactions are allowed with business partner A
Payment details
● For transactions with business partner A, what payments details should be used for a
specific type of transaction
Derived flows
● For transactions with business partner A, if flow X occurs in a transaction with BP A, a tax /
commission of Y % shall be calculated on it and added to the financial transaction's cash
flows. For example, derived flows can also be done to account for withholding taxes.
Master Data - Maintaining Business Partner Groups
Figure 58: Master Data - Maintaining Business Partner Groups

Animation: Master Data - Maintaining Business Partner Groups

For more information on Master Data - Maintaining Business Partner Groups,
please view the animation in the lesson Maintaining Business Partner Settings,
To create a business partner, from the Maintain Business Partner tile or from transaction
code BP, press the create business partner option.
Business partners can be created in different BP groups. SAP differentiates between the
following groups:
● Person
● Organization
● Group
Figure 60: Master Data - Maintaining Business Partner General Settings
If you create a new business partner in the system, you need to specify the General Business
Partner role, the business partner category and the grouping in the initial screen.
The grouping is defined in customizing and is used to classify business partners according to
any criteria, to control authorizations, and to assign the number ranges. For example, it is
within the customizing of the grouping where the internal number range is specified, as well as
if for that grouping, the business partner IDs should be internally generated or externally
generated.
In the business partner configuration, it is possible to specify the field selection using the Field
Groupings configuration, which is found in the IMG menu under Financial Supply Chain
Management → Treasury and Risk Management → Basic Functions → SAP Business Partner
for Financial Services → General Settings → Business Partner → Basic Settings → Field
Groupings. In addition, field selection can be done by SAP client, by BP role, by activity or by
business partner type.

Figure 61: Master Data - Maintaining Business Partner Roles
Animation: Master Data - Maintaining Business Partner Roles

For more information on Master Data - Maintaining Business Partner Roles,
please view the animation in the lesson Maintaining Business Partner Settings,
Business partners are maintained using the Maintain Business Partner tile. Each business
partner must be created as a "General BP" in the first step.
In our example, we will only examine the "Counterparty" BP role; other BP roles are controlled
in exactly the same way.
To get to the standing instructions screens from the Maintain Business Partner tile, change
the role to Counterparty, then press the company code button. The standing instruction tabs
will then be displayed.
By assigning different roles to a business partner, specific functionality can be used for the
business partner.
For example, after the role of Counterparty is assigned to a business partner, the business
partner can be used to create trades in Transaction Manager. To be able to use a business
partner in Transaction Manager, the business partner must have the role of Counterparty
assigned.
Additionally, the following standing instructions should be specified for all business partners
that have this role: Payment details, Derived flows (if used), and Authorizations.
Note the steps to get to the standing instructions. The business partner role must be set to
Counterparty, otherwise the „Company Code" button does not appear.
Maintaining the standing instructions can also be done by using the following transaction
codes:
● TBI1 - Payment Details

● TBI6 - Transaction Authorizations

● TBI7 - Derived Flows
Note: The correspondence monitor has been redesigned and replaced by the
Correspondence Framework, thus the correspondence tab is no longer available.
Figure 63: Master Data - Maintaining Business Partner Payment Details
Business partner payment details standing instructions are done so that the correct bank
accounts to be used for trades will default into the trades automatically and not need to be
manually entered. This saves times and reduces the possibility of manual entry errors.
In the payment details area, you specify the company code-specific payment details.
Payment details are controlled for each currency and house bank. You can use various
different payment details for each transaction type.
In order to be able to assign house banks, the house bank accounts must already have been
defined.
The payer field enables you to specify which of the business partner's payment details are
used to settle the payment item. Settlement can also take place via another BP, depending on
how payment transactions are to be managed in the company.
The payment request specifies whether a payment run is to be carried out for the item.
Figure 64: Master Data - Maintaining Business Partner Authorizations

Animation: Master Data - Maintaining Business Partner Authorizations

For more information on Master Data - Maintaining Business Partner
Authorizations, please view the animation in the lesson Maintaining Business
In the business partner authorization standing instructions, the business user authorizes
specific trade types to be entered into with the business partners. Without the business
partner authorization standing instructions specified for a business partner and trade type,
the trade cannot be entered into SAP.
The transaction level authorization standing instructions can be defined down to the product
type and transaction type level.
Figure 66: Master Data - Maintaining Business Partner Derived Flows
Derived Flows standing instructions enable you to automatically generate and calculate
certain financial flows that result from other financial flows. One example of how derived flows
can be used is to generate withholding tax cash flows in treasury transactions.
Derived flows are rules that are assigned by business partner at the company code level. Cash
flows will automatically be created in the financial transactions (trades) based on the rule
assigned. An example of derived flows is withholding taxes, which are based on rules that
apply based on the characteristics of the trade.
To set up derived flows, the derivation procedures (calculation rules) must first be maintained
in customizing. The derived flows can be assigned at the product and transaction type level.
The derived flow standing instructions can be defined down to the product type and
transaction type level.
How to View the Business Partner Settings
Simulation: How to View the Business Partner Settings

For more information on How to View the Business Partner Settings, please view
the simulation in the lesson Maintaining Business Partner Settings online in the
SAP Learning Hub.

Business Partner Roles
Figure 68: Business Example
Animation: Business Example

For more information on Business Example, please view the animation in the
lesson Maintaining Business Partner Settings, online in the SAP Learning Hub.
See on the next slides how to work on the customizing for business partners.
Figure 70: Business Partner in Customizing
Animation: Business Partner in Customizing

For more information on Business Partner in Customizing, please view the
Learning Hub.

To get to the customizing area, enter the text SPRO, as shown above, in the transaction code
box, then press the SAP Reference IMG button. The user will then be taken to the customizing
menu across all areas of SAP.
The menu path is Tools → Customizing → IMG → Execute Project.
The application side is where business users enter transactions into SAP. Customizing is
where IT makes the settings specific to the company's business. Customizing is done as part
of the implementation phase of the project, and on an ongoing basis in the case of supporting
the business's changes.
Figure 72: Define Business Partner Roles
Animation: Define Business Partner Roles

For more information on Define Business Partner Roles, please view the
Learning Hub.
All business partners are automatically assigned the role of "000000 Business Partner
(General)" when created. Additional roles are assigned to business partners based on the
business situation. For example, the role "TR0153 - Depository Bank" is assigned to business
partners that represent a custody or trustee, and the role "TR0151 Counterparty" is to use the
business partner as the counterparty of a trade in Transaction Manager.
The screenshot above shows the SAP role categories. Each business partner role is assigned
a unique identifier. The role categories used in Transaction Manager have a role category that
starts with „TR".
Changes to business partner roles can be made by following the customizing path: Financial
Supply Chain Management → Treasury and Risk Management → Basic Functions → SAP
Business Partner for Financial Services → General Settings → Business Partner → Basic
Settings → Business Partner Roles

Figure 74: Define Business Partner Roles
Animation: Define Business Partner Roles

For more information on Define Business Partner Roles, please view the
Learning Hub.
In configuration for each role, it is specified if the business partner can be an organization,
person and/or group, which is driven by configuration settings. These configuration settings
drive the application side processing allowed for the specific role.
For Transaction Manager deals, only the category Organization is required. We differentiate
between the following areas when a business partner is created:
● Organization
● Person
● Group
This assignment makes it possible to reserve certain roles for use with certain business
partner groups only. The assignment takes place in connection with the functions that are to
be carried out by this group.
Business Partner Types
Figure 76: Business Partner Types

It may be useful to group business partners. This can be done by using the business partner
type field. After defining business partner types, one business partner type can be assigned to
each business partner.
A common use of business partner type in Transaction Manager implementation is to
distinguish external versus internal business partners. In doing this, the above field status
settings, could be done by business partner types. One example of different field settings
needed for internal versus external business partners is the trading partner field, which
should be set as required for internal business partners and suppressed for external business
partners.
Defining business partner types can be done by following the customizing path Financial
Supply Chain Management → Treasury and Risk Management → Basic Functions → SAP BP
for FS → General Settings → Business Partner → Basic Settings → Business Partner Types →
Define Business Partner Types.
After defining the business partner types, the field attributes per BP type is done by following
the customizing path Financial Supply Chain Management → Treasury and Risk Management
→ Basic Functions → SAP BP for FS → General Settings → Business Partner → Basic
Settings → Field Groupings → Configure Field Attributes per Business Partner Type.
Business Partner Field Modifications
Figure 77: Configure Field Attributes per BP Role
Animation: Configure Field Attributes per BP Role

For more information on Configure Field Attributes per BP Role, please view the
Learning Hub.
Using this configuration, field status is assigned to all tabs of the specific business partner
role. In the screenshot above, the field status is done by each tab in the business partner
master record. Because the field attributes are done in this step by BP role, they impact just
the role being configured.
Here, you can define for each field in the business partner master record, how the field should
be displayed for specific BP roles.
Depending on the BP role, you can define various different field settings using this
Customizing setting.
Field settings can be controlled using the following specifications:

● Suppress/Hide
● Required entry
● Optional entry
● Display only
● Not specified (SAP default, generally an optional entry)
Configuring field attributes per BP role is done by following the customizing path Financial
Supply Chain Management → Treasury and Risk Management → Basic Functions → SAP BP
for FS → General Settings → Business Partner → Basic Settings → Field Groupings →
Configure Field Attributes per BP Role.
Business Partner Relationships
Figure 79: Business Partner Relationships
Animation: Business Partner Relationships

For more information on Business Partner Relationships, please view the
Learning Hub.
Defining relationship types makes it possible to determine and evaluate corporate limits in
Credit Risk Analyzer. For example, in total, Citibank Group has a limit of 100 million USD
distributed across the individual bank branches.
With the relationship button on the application side, relationships between two business
partners can be defined. Before a relationship can be created, two business partners need to
have been defined.
The business partner relationship is key for Credit Risk Analyzer, which will roll-up the
exposures across the whole group, for example, the whole bank group. In other words, the
credit exposure will be calculated on SAP across all related business partners.

Figure 81: Business Partner Relationship Categories
In this step, the settings for the properties of the business partner relationship categories are
made.
In business partner relationship maintenance, all the business partner relationship categories
are provided for selection in the relationship overview.
The most commonly used relationship categories used in Transaction Manager are:
● FSB002 – Is subsidiary of/Is parent company of
● BUR001 – Has Contact Person/Is Contact Person for
● FSB001 – Private Co. with partners
If only certain business partner relationship categories should be displayed, select the Hide
indicator by the other business partner relationship categories. In selecting this indicator, the
relationship category will not be displayed on the application side.
The definition of relationship categories is done by following the customizing path Financial
Supply Chain Management → Treasury and Risk Management → Basic Functions → SAP
Business Partner for Financial Services → General Settings → Business Partner Relationships
→ Basic Settings → Properties of Business Partner Relationship Categories.
Create a Business Partner
Simulation: Create a Business Partner

For more information on Create a Business Partner, please view the simulation in
the lesson Maintaining Business Partner Settings online in the SAP Learning Hub.

Unit 2
Exercise 1
Business Example
You want to create a new business partner with whom you can execute financial transactions.
To do this, create a new business partner and assign the Counterparty role to your business
partner.
To create a business partner, select the Maintain Business Partner tile (Treasury – Master
Data).
As you want to invest in U.S. government T-Bills and bonds, create the U.S. government as a
business partner and assign it the Issuer role.
Note:
In this course, ## is used as a placeholder. When you see ## in an exercise step,
replace it with your two-digit group number.
There are no dependencies for this exercise.
Also, depending on the resolution, some buttons may appear under the “More”
option. If the students cannot find a button, it may be behind the “More” option.
1. In future exercises, you will want to conclude transactions in your company code TA##
(where ## is your group number, which is shown on the monitor) with business partner
BP##. Create the business partner BP## (as an organization). Use the grouping Treasury
Partner (external) TR02 (which drives the external number assignment). Maintain the
details in the following tables, and then save your business partner:
Table 1: Business Partner Data

Field Name Value
Business Partner BP## (where ## is your PC or group num-

ber)
Grouping Treasury Partner (external) (TR02)
Name any name
Table 2: Business Partner Address Details

Field Name Value
Street, House number Dietmar-Hopp-Allee, 16

Postal Code 69190
City Waldorf

Field Name Value
Country DE (country must be Germany)
Note:
In the communication information, select the language EN English. Then, to set
up the system to check your entries, press the Enter key.
2. Add the Counterparty role to your business partner.
3. Add the details of the registered office (“Germany”) to your business partner in the
system using the information in the Legal Address table.
Table 3: Legal Address

Field Name Value
Country DE - Germany
4. Define the payment details for your business partner BP##. Create two payment details
(bank account information in EUR and USD) on the payment transactions tab. These
payment details are used for EUR and USD payments. These bank accounts are your
business partner's bank accounts.
Table 4: Bank Details

Field Name Value
ID First EUR, then USD

Bank key Select from a list
Bank account Individual
5. Create a second business partner BP##A (with the General role), following steps 1-2.
6. Your business partner BP## became a Is subsidiary of business partner BP##A at the start
of the month. Note this relationship in the system using the business partner
relationships.
7. You want to allow ALL trade types to be made with partner BP##. Assign the appropriate
transaction authorizations in the BP after assigning the TR0151 Counterpartyrole to your
business partner. (Use your company code TA## to do this).
Switch to change mode for the business partner BP## and assign the transaction
authorizations through the Counterparty role (Company Code button).
Field Name Value
Company Code TA##

8. Create payment details standing instructions in EUR and USD for your company code
TA##, to be used for transactions with business partner BP##. Then assign these details
to the corresponding product types.
Table 5: Outbound EUR Payments

Field Name or Data Type Value
Currency EUR
Payment details ID EURO_OUT
House bank HB001
Account HB001
Payer/payee BP##
P bank EUR (or first business partner bank ac-
count)
Payment request X (select)
Payment methods T
Table 6: Inbound EUR Payments

Currency EUR
Payment details ID EURO_IN
House bank HB001
Account HB001
Table 7: USD Payments

Currency USD
Payment details ID USD_IN_OUT
House bank HB001
Account HB001
9. Create the U.S. government as a business partner (GOV##) as an organization, and

assign it the Issuer role. Use the grouping Treasury Partner (external) TR02 (which drives
the external number assignment) and add the Issuer role.
Table 8: Issuer Business Partner Data

Field Name Value
Business Partner GOV## (where ## is your PC or group

number)

Field Name Value
Name U.S. Government ##
Note:
You do not need to add any information other than the name of the business
partner.

Unit 2
Solution 1
Business Example
You want to create a new business partner with whom you can execute financial transactions.
To do this, create a new business partner and assign the Counterparty role to your business
partner.
To create a business partner, select the Maintain Business Partner tile (Treasury – Master
Data).
As you want to invest in U.S. government T-Bills and bonds, create the U.S. government as a
business partner and assign it the Issuer role.
Note:
Also, depending on the resolution, some buttons may appear under the “More”
option. If the students cannot find a button, it may be behind the “More” option.
1. In future exercises, you will want to conclude transactions in your company code TA##
(where ## is your group number, which is shown on the monitor) with business partner
BP##. Create the business partner BP## (as an organization). Use the grouping Treasury
Partner (external) TR02 (which drives the external number assignment). Maintain the
details in the following tables, and then save your business partner:
Table 1: Business Partner Data

Field Name Value
Business Partner BP## (where ## is your PC or group num-

ber)
Name any name
Table 2: Business Partner Address Details

Field Name Value
Street, House number Dietmar-Hopp-Allee, 16

Postal Code 69190
City Waldorf

Field Name Value
Country DE (country must be Germany)
Note:
In the communication information, select the language EN English. Then, to set
up the system to check your entries, press the Enter key.
a) Logon to the Fiori Launchpad.
b) Choose the Maintain Business Partner tile in the group Treasury - Master Data.
c) Press the Create Organization button on the toolbar.
d) Enter the data provided in the table, Business Partner Data.
e) Enter the data provided in the table, Business Partner Address Details.
f) In Communication Information, select the language EN English, and press Enter.
g) To check your entries, choose Check button on the toolbar.

The Business partner data without errors notification appears in the status bar.
h) Choose Save.
2. Add the Counterparty role to your business partner.

a) To get from display mode to change mode, on the toolbar, choose Switch between
display and change mode.
b) At the Change in BP role field, and choose the Counterparty role.
c) To save to your business partner BP##, press theSave button in the lower right of the
screen.
3. Add the details of the registered office (“Germany”) to your business partner in the
system using the information in the Legal Address table.
Table 3: Legal Address

Field Name Value
a) If necessary, to get to change mode, on the toolbar, choose Switch between display
and change mode.
b) Press the Navigation Menu, and choose the Legal Data tab.
c) Enter the details provided in the table, Legal Address.
d) To save to your business partner BP##, press theSave button in the lower right of the
screen.
4. Define the payment details for your business partner BP##. Create two payment details
(bank account information in EUR and USD) on the payment transactions tab. These

payment details are used for EUR and USD payments. These bank accounts are your
business partner's bank accounts.
Table 4: Bank Details

Field Name Value
ID First EUR, then USD

Bank key Select from a list
Bank account Individual
a) If necessary, to get from display mode to change mode, on the toolbar, choose Switch
between display and change mode.
b) Press the Navigation Menu, and choose the Payment Transactions tab.
c) Enter the details provided in the table, Bank Details.
d) Create the IBAN for each bank account by pressing the IBAN button. Select Continue
(twice) to accept to proposed IBAN.
e) Choose Save.
5. Create a second business partner BP##A (with the General role), following steps 1-2.
a) Create a second business Partner BP##A (with the General role), using steps 1 to 2.
b) Fill the mandatory fields, as normal, and ensure that you select the Generalrole.
6. Your business partner BP## became a Is subsidiary of business partner BP##A at the start
of the month. Note this relationship in the system using the business partner
relationships.
a) If necessary, to get from display mode to change mode, on the toolbar, choose Switch
b) In the application toolbar, choose Relationships, under the More menu.

No relationships are found.
c) Select the Relationship Category Is subsidiary of from the drop down list, and enter the
business partner BP## in the Relationship to BP: field. On the right-hand side of the
screen, choose Create.
d) At the popup window, choose Continue.

The Overview screen displays the connection between BP## and the business partner
BP##A that has been created.
e) To save to your business partner BP##, choose Save.
f) Choose General Data to get back to the main business partner screen.
7. You want to allow ALL trade types to be made with partner BP##. Assign the appropriate
transaction authorizations in the BP after assigning the TR0151 Counterpartyrole to your
business partner. (Use your company code TA## to do this).
Switch to change mode for the business partner BP## and assign the transaction
authorizations through the Counterparty role (Company Code button).

Field Name Value
Company Code TA##
a) To open BP##, press the Open BP button. At the Open business partner popup, enter
BP##, then the Enter button.
b) If necessary, to get from display mode to change mode, on the toolbar, choose Switch
c) Select the TR0151 Counterparty role, and choose Company Code.
d) Press the Switch Company Code button, which opens the Company Code field, and
enter the data provided in the table, and press Enter.
An overview of the available standing instruction tabs appear in the lower part of the
screen.
e) Select the SI: Authorizationstab to specify the authorization standing instructions.
f) You can click each individual area and assign individual authorizations or set up
authorizations at the top level for all trade types. (Verify this by opening the Money
Market folder.)
g) Select the indicators for ALL submodules at the top level, by selecting theSelect All
icon, because all transactions of these types are possible for this business partner.
Make sure the indicators for each submodule is selected so that all trade types are
authorized.
h) To save to your business partner BP##, choose Save.

The Changes saved notification appears in the status bar.
8. Create payment details standing instructions in EUR and USD for your company code
TA##, to be used for transactions with business partner BP##. Then assign these details
to the corresponding product types.
Table 5: Outbound EUR Payments

Currency EUR
Payment details ID EURO_OUT
House bank HB001
Account HB001
Payer/payee BP##
P bank EUR (or first business partner bank ac-
count)
Payment request X (select)
Payment methods T

Table 6: Inbound EUR Payments

Currency EUR
Payment details ID EURO_IN
House bank HB001
Account HB001
Table 7: USD Payments

Currency USD
Payment details ID USD_IN_OUT
House bank HB001
Account HB001
a) Select the SI: Payment Details tab.
b) Enter the data provided in the table, Outbound EUR Payments.
c) Enter the data provided in the table, Inbound EUR Payments.
d) Select the EURO_OUT (Pay.Det.ID) entry and assign it the product types you require
(by pressing the Assign button). Assign the EURO_OUT to all outgoing flows by
pressing the Select All Outgoing icon. Then press the Continue button.
e) Select the EURO_IN (Pay.Det.ID) entry and assign it the product types you require (by
pressing the Assign button). Assign the EURO_IN to all incoming flows by pressing the
Select All Incoming icon. Then press the Continue button.
f) Enter the data provided in the table, USD Payments.
g) Select the USD_IN_OUT (Pay.Det.ID) entry and assign it the product types you require
(by pressing the Assign button). Complete the assignments for both incoming and
outgoing flows by pressing the Select All Outgoing icon and then pressing the Select All
Incoming icon. Then press the Continue button.
h) To save to your business partner BP##, choose Save.

9. Create the U.S. government as a business partner (GOV##) as an organization, and

assign it the Issuer role. Use the grouping Treasury Partner (external) TR02 (which drives
the external number assignment) and add the Issuer role.
Table 8: Issuer Business Partner Data

Field Name Value
Business Partner GOV## (where ## is your PC or group

number)

Field Name Value
Name U.S. Government ##
Note:
You do not need to add any information other than the name of the business
partner.
a) Choose the Maintain Business Partner tile in the group Treasury - Master Data.
b) Press the Create Organization button on the toolbar.
c) Enter the data provided in the table, Issuer Business Partner Data.
d) To check your entries, choose Check button on the toolbar.

The Business partner data without errors notification appears in the status bar.
e) Choose Save.
f) To get from display mode to change mode, on the toolbar, choose Switch between
display and change mode.
g) At the Change in BP role field, change the role to Issuer to the business partner
GOV##.
h) To save to your business partner GOV##, choose Save.


Business Partner Release Workflow
Figure 83: Business Example
The three configuration steps to setting up the business partner workflow are listed above.
Before the workflow can be used in practice, all the menu items have to be processed. We will
now walk through all three steps in detail.

the lesson Maintaining Business Partner Settings, online in the SAP Learning
Hub.
Before proceeding, consider the treasury process flow. Before a business partner can be used
in a Transaction Manager trade, it must be created. After it is created and before it can be
used, it must be approved, when using the business partner workflow release functionality.

Using the dual control on business partner creation and changes is a customizing step that an
SAP customer may or may not choose to use. In other words, setting up the workflow release
on business partner creation and changes is an optional configuration step.
Figure 86: Overview of Workflow Release Process Flow
The representation above shows the process around a business partner's release. First, the
business partner is created or is changed, then it must be released before it can be used in a
trade. After the BP is released, the BP can be used for trade processing. The advantage of the
BP release workflow is that the person who creates the BP cannot release the BP. In other
words, there is dual-control enforced by SAP.
A change history is available and a check can be performed before the release can be done.
As a matter of principle, only standard workflows that allow individual and enterprise-specific
definitions are used.
The business partner dual control workflow works both for the creation of new business
partners and for the modification of business partner master records. In both cases, before a
business partner can be used in a treasury trade, it must be approved by a business user
other than the business partner that created the business partner or than made the last
changes.
Release Procedure
Figure 87: Activate Release
As a matter of principle, only standard workflows that allow individual and enterprise-specific
definitions are used for the business partner workflow.
The business partner workflow steps can be found by following the customizing path:
Financial Supply Chain Management → Treasury and Risk Management → Basic Functions →
SAP BP for FS → Settings for Financial Services → Release → Activate Release.
The three steps to setting up business partner workflow are below. Each of the steps is
executed in order.
1. Activate Release
2. Maintain and Activate Release Parameters
3. Maintain Workflow Settings

In the first step, the workflow is started if the Active field is confirmed with a checkmark
(indicator selected). The release is only active for the specified release object, which in our
case is ZGP (shown above).
To turn off the BP release completely, use the 'Activate Release' node, and deselect the
'Active' indicator. To reactivate the workflow, select the 'Active' indicator.
Note: In standard Customizing, if the release object ZGP is not available, please check note
438277 and 1030808.
Release Parameters
Figure 88: Maintain/Activate Release Parameters
Different roles are needed, depending on the workflow type. You should only use standard
roles here. In our example, the standard roles TR0150, TR0151, and TR0152 are used.
Enter the desired role categories along with the desired release status, and select the
activation flag.
The release status assigned determines the number of approvals that are needed. The
following associated release statuses can be used:
● Release status principle of dual control (22)
● Release status principle of triple control (33)
● Release status principle of quadruple control (44)
The release status also controls whether the initiator of a release is excluded from the release.
● With status: '44', '33', '22' and '11' The initiator may release.
● With status: '43', '32' and '21' ... The initiator may not release. The initial entry is considered
as initial release.
If, for example, the principle of dual control is to be used for releasing a counterparty,
standard role TR0151 is entered. For dual control where the initiator cannot release their own
entries, use release status of 21. In this case, the first person creates the business partner or
makes a change to a business partner, and a second person must approve the change before
it can be used.

Figure 89: Maintain Workflow Settings
The final step is done completing the Maintain Workflow Settings step, which is done by
executing the following customizing step: FSCM → Treasury and Risk Management → Basic
Functions → SAP BP for FS → Settings for Financial Services → Tools → Release → Maintain
Workflow Settings.
In this final step, the approvers of the business partner workflow messages are specified.
After selecting the customizing step above, the activities window is displayed. This
configuration step involves executing all four steps displayed in order, as shown above.
Figure 90: Create Responsibility
With the release role, you can decide for which release object a workflow is set up. In addition,
you defined the release pattern. The BP release workflow was developed for the loans
management module; now, some additional fields are available but not required for the
release procedure.
The name of the object can be changed to BP Workflow from “Loans: Role for Release
Workflow".

Figure 91: Responsibility Specifications
To create the rule, press the create icon. Enter the release object, which in our case is ZGP.
Use the created release object "ZGP".
Figure 92: Create Relationship
In this step, the workflow agents are assigned. The agents are the users who will receive the
workflow messages to approve the changes made to the business partners.
Follow the steps below to assign agents:
1. Select the icon "Insert agent assignment". This is the seventh icon along the toolbar.
2. The user will see a popup window from which how the agent is to be assigned. Double click
on User, and enter a user ID.
3. A screen similar to the one above will be displayed. Note that a time period can be
specified which is the time period the particular agent will be active.
4. Repeat this process until all workflow agents have been assigned.
All settings are saved to a transport request. When complete with this step, go back to the
submenu and select the next menu item "Administrative Responsibility for Incorrect Agent
Assignment".

Maintain Workflow Settings
Figure 93: Maintain Workflow Settings - Maintain Areas of Responsibility for Agent Assignment
Once the steps are completed, the responsibility rule shows as 'Responsibility complete'.
Figure 94: Maintain Workflow Settings - Administrative Responsibility for Incorrect Agent Assignment
In the next step, the administrative responsibility for incorrect agent assignment is done. In
this step, one or more areas of responsibility are created to be used for release decisions in
cases where the agent assignment for standard roles is incorrect.
Make the required settings similar to how was done in the Maintain Areas of Responsibility for
Agent Assignment step.

Figure 95: Incorrect Agent Assignment
In this step, the administrative responsibility for incorrect agent assignment is done.
Follow the same process as done for the 'Maintain Areas of Responsibility for Agent
Assignment', which is:
1. Select the icon.
2. 'Insert agent assignment'. This is the seventh icon along the toolbar.
3. The user will see a popup window from which how the agent is to be assigned. Double click
on User, and enter a user ID.
4. A screen similar to the one above will be displayed. Note that a time period can be
specified which is the time period the particular agent will be active.
5. Repeat this process until all workflow agents have been assigned.
At the popup, select the User option, enter the user ID, then press the Enter key. The user has
now been added as an agent, which will be able to approve the business partner workflow
messages.
Match the SAP user to the created business partner role. All settings are saved to a transport
request. Go back to the submenu and select the next menu item 'Administrative
Responsibility for Incorrect Agent Assignment'.
Save the settings and go back to the submenu, open the next menu item.
Figure 96: Define General Processor Assignment of Tasks
In the next step, the define general processor assignment of tasks is done. To enable the
workflow task ‚Release decision by user' to also be assigned to the agents from the agent
assignment function, this task must be defined as a general task, which is done in this step.

Figure 97: Maintain Workflow Settings - Define General Processor Assignment of Tasks
Press the 'Assign Agents' item. The system will display the task groups for the workflow
release.
For each task, set the task to be a General Task by following these steps for each of the three
tasks:
1. Place the cursor on the respective task.
2. Choose the 'Attributes' button.
3. On the screen that appears, select the field 'General Task' and confirm by choosing
'Transfer'.
Figure 98: Maintain Workflow Settings - Maintain Agent Assignment
Once complete, all items will be set to 'General Task', as shown above.
Figure 99: Activate/Deactivate Workflow
In the final step, the workflow is activated.

Figure 100: Activate/Deactivate Workflow - Event Linkage
In the final step, the release workflow has to be activated. First, select the 'Activate event
linking' symbol. Then, double-click on the activation/deactivation symbol. At the popup
window, select the 'Event linkage activated' indicator. Press the Save button. The status will
change from Deactivated to Activated.
After the activation is completed, four green arrows should appear in the interim menu. These
arrows clarify the processing status.
Figure 101: Master Data - Business Partner Workflow
Now, all four steps have been completed on the interim menu.

Workflow Settings
Figure 102: Release Workflow: Generating Automatic Workflow Customizing
The automatic workflow customizing must be generated using transaction code SWU3. The
individual areas have to be set up and generated, depending on the system structure and the
application depth.
In the prefix numbers area, there must be one entry for each system and client. If this is not
the case, the workflow will not function.
These setting are not transported; they are part of the "Go Live" activities. It is important that
the workflow batch user is available, because this user is relevant for the background
processing process of the workflow.
Figure 103: Release Workflow: Synchronizing the Runtime Buffer
After all the settings have been made, the runtime buffer must be synchronized. If there are
any further subsequent changes, for example to the user assignment, the buffer must be
synchronized again.
The Synchronize Runtime Buffer step is found by executing transaction code SWU_OBUF.
The synchronization requires you simply to press the 'Start Synchronization' button. Once
synchronization has been successfully carried out, a runtime date plus the time appears in the
status section.

How to Activate the Business Partner Workflow
Simulation: How to Activate the Business Partner Workflow

For more information on How to Activate the Business Partner Workflow, please
view the simulation in the lesson Maintaining Business Partner Settings online in
How to Execute the Business Partner Workflow
Simulation: How to Execute the Business Partner Workflow

For more information on How to Execute the Business Partner Workflow, please
view the simulation in the lesson Maintaining Business Partner Settings online in

LESSON SUMMARY

Unit 2
Lesson 3
Defining House Bank Accounts
LESSON OBJECTIVES
House Bank Accounts
Figure 106: House Bank Accounts
Business Example
You are starting a Transaction Manager implementation and will need to validate the house
bank accounts to be used for Transaction Manager processes.
See below how House Bank Accounts are setup in the system.

Figure 107: Define House Bank Accounts
A house bank is where the SAP customer has bank accounts. This is typically an external
bank, but in the case of In-House Cash, SAP's in-house bank functionality, could also be an
internal bank. An up to five-character house bank ID is created to represent the bank, e.g.
JPMC1, BONY1, or BANK1. The house bank ID is assigned to a company code. A house bank
account is a bank account at the house bank. An up to five-character house bank account ID
is created to represent each bank account, e.g. 39403, USD01, ACCT1. Both the house bank
ID and house account ID are freeform alphanumeric IDs.
Starting from SAP S/4HANA Finance 1503, creating house bank accounts is a master data
function, as opposed to a customizing task. House bank accounts are created using the
Manage Bank Accounts tile in Bank Account Management.
With this app, customers are able to do the following:
● Displaying bank accounts in a list view
● Searching for a bank account either by exact search or fuzzy search
● Maintaining the bank account master data
● Importing or exporting bank accounts using the tool Import and Export Bank Accounts
Press the Create New Object button (+ button) to create a new house bank account. The user
will see the screen above, and should enter the required fields noted by the *. Press Save as
Draft or Save as Active once complete. After creating the bank account, to create the house
bank account ID for the bank account just created, press the Edit button then the
Connectivity Path button. Under the Connectivity Path, the house bank account ID and G/L
account for the house bank account is defined.
It is possible to upload and download house bank accounts when moving from one system to
the next, e.g. moving from DEV to QA.
Note: House banks continue to be a customizing task that are created and displayed using
transaction codes FI12_HBANK and FI13_HBANK respectively.

Lesson: Defining House Bank Accounts
Figure 108: Display House Bank Accounts
To display house bank accounts, use the Manage Bank Accounts tile, enter the selection
criteria, and press the Go button.
Note: It is possible to change the fields displayed by changing the layout.
Figure 109: Number Ranges
Number ranges are now required for the house bank account IDs.
To define number ranges for bank account technical IDs, see the Implementation Guide (IMG)
under Financial Supply Chain Management → Cash and Liquidity Management → Bank
Account Management → Basic Settings → Define Number Ranges for Bank Account
Technical IDs.
For information on how to specify a number range for bank account technical IDs, see the
Implementation Guide under Financial Supply Chain Management → Cash and Liquidity
Management → Bank Account Management → Basic Settings → Define Settings for Bank
Account Master Data.

How to View House Bank Accounts
Simulation: How to View House Bank Accounts

For more information on How to View House Bank Accounts, please view the
simulation in the lesson Defining House Bank Accounts online in the SAP
Learning Hub.
LESSON SUMMARY

Unit 2
Lesson 4
Defining Securities-Related Master Data
LESSON OBJECTIVES
Security Accounts
Figure 111: Security Accounts (1)
In SAP, both active and passive positions can be mapped. Note: The passive-position
management functions are currently only available for stocks and bonds.
It is also possible to map lending securities accounts in the system. This means that active
positions can be passed on to third parties in order to change the company's risk profile.
The following types of securities accounts can be defined on SAP:
● Asset Securities Account (AKT): In securities accounts of this type, all positions can be
managed except for issue positions or positions belonging to securities-lending
transactions.
● Issuance Securities Account (PAS): Only positions for securities issuances can be in
issuance securities accounts. The system makes sure that issuance positions cannot be
transferred to asset securities accounts or lending securities accounts. It also ensures that
asset positions or positions that belong to securities lending transactions are not
transferred to an issuance securities account.
● Lending Securities Account (SLE): For a securities lending transaction, the lent securities
are transferred at the start of the term from the asset securities account to a lending

securities account. At the end of the term, the securities are returned to the original
investment securities account. The system ensures that the positions in the lending
securities account cannot be sold or cleared during the term of the securities lending
transaction.
The Define Securities Account Categories configuration node can be found under Financial
Supply Chain Management → Treasury and Risk Management → Transaction Manager →
Securities → Master Data → Securities Account Management → Define Securities Account
Categories.
In this configuration node, you can create securities account types for security accounts. This
specifies the different categories of securities accounts. For each security account type, you
must specify a security account category. This category contains teh information about which
positions can be managed in the associated securities accounts.
Field status on security account master data is done by company code. In other words, each
company code could have different field selections for the security accounts defined.
The Maintain Field Selection for Security Account Master Data configuration node can be
found under Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → Securities → Master Data → Securities Account Management →
Maintain Field Selection for Security Account Master Data.
To get to the field status settings, select the tab to the left of a company code and press the
“Field select.control" button.

Lesson: Defining Securities-Related Master Data
Per company code, different field selections for security accounts can be defined.
The field status configuration is done by:
● General Data
● Bank Data
● Additional Data
Here, you can specify the field attribute for each field available in the securities account
master data definition. The field status options are:
● Suppress fields
● Required entry fields
● Optional entry fields
● Display fields
Create a Securities Account
Simulation: Create a Securities Account

For more information on Create a Securities Account, please view the simulation
in the lesson Defining Securities-Related Master Data online in the SAP Learning
Hub.


Unit 2
Exercise 2
Business Example
To prepare to start trading securities, you have opened a securities (custody) account. In this
step, you create the securities account on SAP.
The only prerequisite to this exercise is that the house bank account related to the securities
account has already been created on SAP. For the exercise, we use House Bank ID HB001 and
Account ID HB001.
Note:
1. Create a new securities account SecACC_## using the Create Securities Account
(Treasury - Securities) tile.
Use the additional data from the two tables to complete the task.
Table 9: Company Code

Field Name Value
Company Code TA##
Security Account SecACC_##
Table 10: Security Account

Field Name Value
Security Account ID: 1000##
Security Account Type: AKT (Investments)

Depository Bank: BP1000
Payment Currency: USD
House Bank: HB001
Account: HB001

Unit 2
Solution 2
Business Example
To prepare to start trading securities, you have opened a securities (custody) account. In this
step, you create the securities account on SAP.
The only prerequisite to this exercise is that the house bank account related to the securities
account has already been created on SAP. For the exercise, we use House Bank ID HB001 and
Account ID HB001.
Note:
1. Create a new securities account SecACC_## using the Create Securities Account
(Treasury - Securities) tile.
Use the additional data from the two tables to complete the task.
Table 9: Company Code

Field Name Value
Company Code TA##
Security Account SecACC_##

Field Name Value
Security Account ID: 1000##
Security Account Type: AKT (Investments)

Depository Bank: BP1000
Payment Currency: USD
House Bank: HB001
Account: HB001
a) Log on to the SAP Fiori Launchpad.
b) In the Treasury - Securities group, navigate to the Create Securities Account tile.
c) At the Choose Securities Account and Company Code screen, choose Create.

d) In the Create New Securities Account window, enter the data provided in the table,
Company Code.
e) Choose Create.
f) On the Create Securities Account SecACC_## in Company TA## screen, enter the
data provided in the table, Security Account.
g) Choose Save.
h) To return to the SAP Fiori Launchpad, choose Home.

Class Data
Figure 115: Class Data
The security class master data is the definition of the market traded security, which could be
a bond, share of stock, asset backed security, etc. Over-the-counter instruments, such as
money market trades, do not require class master data because the instruments are specific
to a trade. Market traded securities require class data to be defined, which defines the
specific details of the traded security, such as the maturity date or interest rate.
The screenshot displayed is the initial screen of the Securities Class tile or use transaction
code FWZZ, which is where the security class data is displayed. This screen is displayed if you
want to enter new class data. In a previous step, you specified in a pop-up the product type to
which you want the new class to belong. In the Search Terms tab, the system displays the
Product Type and the Product Category to you once more. The system decides on the basis
of the product category which information is required or not in each case. Also, linked with the
product type is the field selection control function, which you can use to control which fields
are shown and hidden, and to permit or request entries. You can enter more information on
Descriptions, Secondary Indexes, Classification, and Ratings on the Search terms tab.
Class master data exists independently of whether you actually own the security, etc., in
question. The master data must exist in the system before you enter the first transaction for a
class. Therefore, open Transaction Class Master Data (Transaction FWZZ) to start entering
the master data. You can find this transaction in the menu under Treasury and Risk
Management → Transaction Manager → Securities → Master Data.

Figure 116: Class Data
Animation: Class Data

For more information on Class Data, please view the animation in the lesson
Defining Securities-Related Master Data, online in the SAP Learning Hub.
Classifications for the different types of securities trade types can be defined, which allow the
securities trades to be subdivided into customer specific groups. The different groups of
securities trade types can be used for valuations or reporting.
The customizing path to define the classification for interest bearing securities, follow the
customizing path Treasury and Risk Management → Transaction Manager → Securities →
Master Data → Specific Class Data → Settings for Special Types of Securities → Interest
Bearing Securities → Define Classification for Bonds.
To assign the classifications to product types, follow the customizing path Treasury and Risk
Management → Transaction Manager → Securities → Master Data → Specific Class Data →
Settings for Special Types of Securities → Interest Bearing Securities → Assign Classification
for Bonds.
Create Securities Class Data
Simulation: Create Securities Class Data

For more information on Create Securities Class Data, please view the simulation
in the lesson Defining Securities-Related Master Data online in the SAP Learning
Hub.


Unit 2
Exercise 3
Business Example
In preparation to start trading securities, create the class data for a U.S. T-bill investment.
Dependencies: In exercise 1, the issuer business partner GOV## was created.
Note:
1. Create a new securities class 912796LX5_## using product type 04J.

Use the information from the following tables to complete the task:
Table 11: Securities Class ID

Field Name Value
ID number 912796LX5_##
Product Type 04J

Short name 912796LX5_##
Long name U.S. TBill maturity <current date + 1 year>
Table 12: Search Terms

Field Name Value
Bond Classification Government bond
Table 13: Rating Box

Field Name Value
Valid From <current date>
Institute Moody’s
Rating AAA

Table 14: Basic Data

Field Name Value
Issuer GOV##
Issue currency USD
Nominal value 1,000
Issue start <current date>
Term end <current date + 1 year>
Issue rate 98
Quotation Percentage quotation
Table 15: Conditions

Field Name Value
Interest Calculation
Int. calc. method 360/360
Discounted Discounted on Exponential
Table 16: Exchanges

Field Name Value
Listed <select>
Exchange NYSE
You should see a message indicating your class data has been saved.

Unit 2
Solution 3
Business Example
In preparation to start trading securities, create the class data for a U.S. T-bill investment.
Dependencies: In exercise 1, the issuer business partner GOV## was created.
Note:
1. Create a new securities class 912796LX5_## using product type 04J.

Use the information from the following tables to complete the task:
Table 11: Securities Class ID

Field Name Value
ID number 912796LX5_##
Product Type 04J

Short name 912796LX5_##
Long name U.S. TBill maturity <current date + 1 year>
Table 12: Search Terms

Field Name Value
Bond Classification Government bond
Table 13: Rating Box

Field Name Value
Valid From <current date>
Institute Moody’s
Rating AAA


Field Name Value
Issuer GOV##
Issue currency USD
Nominal value 1,000
Issue start <current date>
Term end <current date + 1 year>
Issue rate 98
Table 15: Conditions

Field Name Value
Interest Calculation
Int. calc. method 360/360
Discounted Discounted on Exponential
Table 16: Exchanges

Field Name Value
Listed <select>
Exchange NYSE
b) Choose the Security Class tile (Treasury - Securities).
c) Choose the Create icon.
d) At the Create Class dialog, enter the data provided in the table, Securities Class ID, and
choose the Create button in the lower left of the popup.
e) On the Search Terms tab, from the dropdown menu, select the Bond Classification
provided in the table, Search Terms.
f) On the Search term tab, scroll down to the bottom of the screen. On the right-hand
side, under the Rating section, to add a new entry, choose the + sign (use the right
scroll bar to move down the screen).
g) Enter the data provided in the table, Rating Box.
h) Choose the Basic Data tab, enter the data provided in the table, Basic Data.
i) Choose the Conditions tab, and enter the interest calculation method and the value
from the Discounted field provided in the table, Conditions.

j) Press the + icon at the bottom of the screen , select the Final Repayment condition,
and press the Copy (Enter) key.
Note:
The system populates the data in the Conditions Items section, based on
the data entered. You do not need to change the conditions fields.
k) To check the cash flows of this security, choose the Cash Flow tab. After checking the
values go back to the previous screen.
l) Choose the Exchanges tab, enter the data provided in the table, Exchanges.
m) Choose Save.
You should see a message indicating your class data has been saved.

LESSON SUMMARY

Unit 2
Learning Assessment
1. What is the transaction code that will get you to the customizing menu?
X A IMG
X B SPRO
X C PROJ
X D IMG1
2. Which role must be selected to get to the Transaction Manager standing instruction
settings?
X A General role
X B Issuer role
X C Counterparty role
X D Transaction Manager role
3. Customizing changes are made directly to a production environment.

Determine whether this statement is true or false.
X True
X False
4. What does the Grouping field on the create Maintain Business Partner screen drive?
X A Roles that can be assigned to the business partner
X B The number range of the business partner
X C Field selection for the business partner
X D Business partner relationship settings

5. What is the lowest level at which business partner standing instruction authorizations can
be set?
X A Product type
X B Transaction type
X C Flow type
X D Update type
6. House Bank Accounts can be transported from one system to the next in SAP S/4HANA.
X True
X False
7. Which of the following data is transportable?

X A House banks
X B House bank accounts
X C Bank keys
X D G/L accounts
8. The securities class data represents the definition of an exchange traded instrument.
X True
X False
9. Which are the types of securities accounts?

Choose the correct answers.
X A Asset securities accounts
X B Lending securities accounts
X C Derivative securities accounts
X D Issuance securities accounts

UNIT 3 General Configuration Settings
Lesson 1
Configuring the Company Code 95
Lesson 2
Defining Valuation Areas 97
Lesson 3
Configuring the Valuation Class 103
UNIT OBJECTIVES
● Configure company code settings

● Define settings for valuation areas
● Explain valuation class

Unit 3: General Configuration Settings

Unit 3
Lesson 1
Configuring the Company Code
LESSON OBJECTIVES
Accounting Code
Figure 119: Define Accounting Codes
Business Example
You are starting a Transaction Manager implementation and will need to define the entities
that will be used for Transaction Manager.
Configuration for types of trades across all Transaction Manager sub-modules requires the
following:

Note:
The above list is not an exhaustive list, but gives a good representation of the
configuration steps required across all Transaction Manager trade types. In
addition, the valuation class, position management procedure and account
assignment reference are required fields for trades across all Transaction
Manager sub-modules.
Figure 120: Define Accounting Codes
Accounting codes are specific settings for Transaction Manager. It is a required step to
customize the accounting codes that will be used. The definition of accounting codes makes it
possible to use different logic in Transaction Manager versus for accounting, but in most
implementations there should be a 1:1 relationship between the company code and the
accounting code.
The accounting code is the term for the company code within Transaction Manager's internal
position management. There should be a one-to-one relationship between company code and
accounting code. In addition, company code and accounting code should have the same
name. The system does not verify this, but if this is not done it may lead to confusion or
involve incorrect specifications in internal position management.
To define the quotation source, use the customizing path: Financial Supply Chain
Management → Treasury and Risk Management → General Settings → Accounting →
Organization → Define Accounting Codes.
For each accounting code created, enter an accounting code, a description, and a company
code.
LESSON SUMMARY

Unit 3
Lesson 2
Defining Valuation Areas
LESSON OBJECTIVES
Valuation Area
Figure 121: Valuation Areas
Business Example
Your company is global and needs to report in both local and IFRS accounting standards. You,
therefore, will need to define multiple valuation areas, and initialize parallel valuation areas in
Transaction Manager.
Discuss the differences between accounting standards such as IFRS, US-GAAP and local
accounting, and explain the necessity which arises from these for different valuations.
Figure 122: Define Valuation Areas

Animation: Define Valuation Areas

For more information on Define Valuation Areas, please view the animation in the
lesson Defining Valuation Areas, online in the SAP Learning Hub.
A valuation area is an accounting principle that needs to be maintained on SAP. Examples of

valuation areas are IFRS, US GAAP, and local GAAP. When multiple valuation areas are
defined, they are independent, parallel views of the values of the financial instruments.
In this step, the valuation areas needed are defined. The valuation area 001 must be assigned
to the operative valuation area. This is the leading valuation area. Any parallel valuation areas
are derived from the operative valuation area. The operative valuation area will be valid for all
company codes.
To summarize:
● The operative valuation area applies to all companies and is always international. The
group accounting principle should be selected here, as the valuation areas apply across
company codes. Payment processes will be made only from the leading valuation area. In
addition, cash management is linked only to the operative valuation area.
● The parallel valuation area is used to map country-specific valuation specifications. The
parallel valuation area is derived from the operative valuation area.
Organization → Define Valuation Areas.
When defining a valuation area, enter the three-digit valuation ID and a description.
Assign Accounting Codes to Valuation Areas
Figure 124: Assign Accounting Codes to Valuation Areas

Lesson: Defining Valuation Areas
Next, the valuation areas are assigned to the accounting codes. By doing this step, you define
which company code uses which accounting principle. (An accounting code actually
corresponds to a company code.)
The valuation area is now assigned to the accounting codes. It is important here to ensure
that all valuation areas are assigned to an accounting code. This assignment also specifies
whether a posting to accounting is generated, and which accounting principle is used. The key
assignment to the correct ledger takes place in FI by means of the accounting principle. Each
accounting code must also be assigned a currency to make it possible to determine whether
transactions are foreign-exchange transaction or not.
In this step, the currency and rate type used for valuations is specified. This currency is
almost always the local currency. The system uses the Exchange Rate Type field to translate
from the exchange rate type position currency into the valuation currency.
The system very rarely uses the exchange rate type because almost all business transactions
of external positions involve a local currency, and a translation into the valuation currency is
not necessary. The Translation field enables you to force a currency translation from the
position currency into the valuation currency. You use the Always Translate option instead of
For Different Valuation Currency for this purpose. This can be useful if you work with two
accounting principles that stipulate different exchange rates for translating operational
business transactions from a position currency into a valuation currency.
In addition, the accounting principle defined in FI is assigned.
Organization → Assigning Accounting Codes and Valuation Areas.
How to Define and Assign Company Code
Simulation: How to Define and Assign Company Code

For more information on How to Define and Assign Company Code, please view
the simulation in the lesson Defining Valuation Areas online in the SAP Learning
Hub.

Parallel Valuation Areas
Figure 126: Parallel Valuation Areas Challenges
Parallel valuation areas refer to the challenge that an increasing number of companies must
face: they must simultaneously create financial statements according to different accounting
principles, such as according to IFRS and a local accounting principle.
The valuation approaches are often very different, which means that it is not done simply by
regrouping the results of one accounting principle. The internal position management of SAP
Treasury and Risk Management provides a mechanism to meet this requirement. It manages
a separate, complete record of ledger positions for each accounting principle.
All parallel valuation areas (in our example, local GAAP) are derived from the operative
valuation area. As no distinction is made in the local GAAP between three valuation periods,
the long-term and medium-term holding periods are grouped together into the category
"fixed assets." The details of the legal specifications for the individual GAAP are defined in
country-specific legal sources.
Figure 127: Parallel Valuation Areas
An initialization process is required for all parallel valuation areas. Before initialization can be
carried out, you have to specify a key date. This key date specifies the point from which the
parallel valuation or posting functions can be used. Each initialization operation consists of a
variety of steps, which you have to process sequentially.

Lesson: Defining Valuation Areas
To move through the initialization process, you select a step and start it by pressing the
Execute button.
Keep in mind the following regarding parallel valuation areas:
● Initialization posts all historical documents from the operative valuation area in the parallel
valuation area.
● All accounting customizing must be completed before the initialization of parallel valuation
areas.
● The parallel valuation area should be initialized before the first transaction is entered.
● The initialization should be carefully tested with production data before rolling the parallel
valuation areas to production.
● While initializing the parallel valuation areas, no transactions should be created or
changed.
● Position management into different valuation areas is only possible after the initialization
has been carried out.
After all the settings have been made, the valuation areas are initialized. A separate
initialization has to be carried out for each financial transaction area (loans, OTC transactions,
securities). If changes are carried out at a later time, it is only necessary to carry out a new
initialization if the changes were major (such as a new valuation area).
Organization → Initialization of Parallel Valuation Area.
LESSON SUMMARY


Unit 3
Lesson 3
Configuring the Valuation Class
LESSON OBJECTIVES
General Valuation Class Definition
Figure 128: General Valuation Class Definition
Animation: General Valuation Class Definition

For more information on General Valuation Class Definition, please view the
animation in the lesson Configuring the Valuation Class, online in the SAP
Learning Hub.

Figure 130: Valuation Areas
Accounting standards necessitate that companies classify any investments in debt or equity
securities when they are purchased as held to maturity, held for trading, or available for sale.
These holding categories or accounting classifications are defined as valuation classes on
SAP.
Depending on the accounting specifications, you can differentiate between different holding
periods. As the current accounting specifications in Europe require a closing in line with the
IFRS guidelines for most enterprises, all positions have to be subdivided into the following
categories: "held for trading," "held to maturity," "loans and receivables," and "available for
sale." The various definitions of the periods are not standardized and allow you some leeway.
Each valuation class can have different accounting treatment. For example, trades
categorized as available-for-sale are reported at fair value with changes in value between
accounting periods are included in comprehensive income until the securities are sold,
whereas trades categorized as held-to-maturity are reported at amortized cost.
Transaction Manager broadly tries to mask the complexity of parallel accounting principles
when you create financial transactions and other operational processes. The holding category
conveys an intention that the trader is also aware of when a transaction is created. The
general valuation class is the term in the Transaction Manager that reflects this intention. The
general valuation class is independent of the valuation area.
Customize the General Valuation Class
Figure 131: Valuation Class (1)

Lesson: Configuring the Valuation Class
The general valuation class must contain all the information from the operative and parallel
valuation areas, as only these are assigned in the transaction and all the local valuation
classes are derived.
The general valuation class specifies in the transaction which valuation area the specified
transaction can be assigned to. In our example, the general valuation class includes
information from IFRS and local GAAP.
Each valuation area is subdivided into various valuation classes by means of the international
(IFRS) or local accounting principles. In this step, the valuation areas are linked to the
corresponding valuation classes.
Settings for Position Management → Define and Assign Valuation Classes.
Figure 132: Valuation Class (2)
Animation: Valuation Class (2)

For more information on Valuation Class (2), please view the animation in the
lesson Configuring the Valuation Class, online in the SAP Learning Hub.

Figure 134: General Valuation Class
In the transaction, only the general valuation classes are entered, or they are retrieved
automatically. For the position to be transferred to the valuation classes, there is now an
assignment step. In the Assign Gen. Valuation Class menu item, the three functional areas
Valuation area, Valuation class, and Gen. valuation class are linked.
Various accounting principles provide for holding categories. The special valuation class maps
the holding categories of the individual accounting principles, and the general valuation class
describes the holding categories in general, irrespective of accounting principles.
You must define at least one valuation class per valuation area because the valuation class is
a mandatory part of each ledger position. The general valuation class is independent of the
valuation area.
The valuation class is the transaction management term for a holding category. All ledger
positions have the valuation class as a distinctive feature. Because the valuation class
conveys an intention that was already known when the financial instrument was acquired, you
specify it when you create the financial transaction or let the system determine it.
The Administration tab page provides data for managing financial transactions. In the
Position assignment screen area, you use the general valuation class to classify financial
transactions according to assets (for example, short-term assets).
For many financial instruments, only one holding category is valid. You can assign a general
valuation class to a transaction type and product type for each company code in Customizing
in the settings of the relevant product group under Transaction Management → Assign
General Valuation Class. This general valuation class is then automatically defaulted into the
financial transaction when it is created.
This can be done by using the customizing path: Financial Supply Chain Management →
Treasury and Risk Management → Transaction Management → General Settings →
Accounting → Settings for Position Management → Assign General Valuation Classes to
Groups.
To define and assign valuation classes, use the customizing path: Financial Supply Chain
LESSON SUMMARY

Unit 3
Learning Assessment
1. There should be a one-for-one mapping between company codes and accounting codes
for company codes related to Transaction Manager functionality.
X True
X False
2. There must be an operative valuation area.

X True
X False
3. If using parallel valuation areas, the initialization of the parallel valuation area is an optional
step.
X True
X False
4. With the use of valuation classes, the same product type (trade type) can have different
accounting treatment.
X True
X False


UNIT 4 Transaction Manager – Basic
Customizing for all Products
Lesson 1
Creating Traders and Portfolios 112
Exercise 4: Create Trader and Portfolio 119
Lesson 2
Defining Trade Types 123
Exercise 5: Maintain Product and Transaction Types in Money Market 135
Exercise 6: Assign Flow Types 143
Exercise 7: Assign Condition Types and Default Valuation Class 149
Exercise 8: Create Fixed-Term Deposit Transaction 157
Exercise 9: Maintain Product and Transaction Types in Foreign Exchange 171
Exercise 10: Maintain Flow Types for FX Transactions 179
Exercise 11: Define Open and Close Position Cash Flows 183
Exercise 12: Create a Foreign Exchange Forward Contract 187
Exercise 13: Define Product and Transaction Types for Derivatives 201
Exercise 14: Assign Flow Types for Derivative Product Types 207
Exercise 15: Assign Condition Types for Derivatives 213
Exercise 16: Define Derivative Open and Close Position Update Types 217
Exercise 17: Create Derivative Transactions 221
Exercise 18: Define a Securities Product Type 241
Exercise 19: Basic Settings for Transaction Management 253
Exercise 20: Create a Security Trade 273
Lesson 3
Maintaining Derived Flows 293
Lesson 4
Using the Deal Release Workflow 297
Exercise 21: Implement the Deal Release Workflow 301
Lesson 5
Defining Position Management 307
Exercise 22: Create a Position Management Procedure 319
Lesson 6

Unit 4: Transaction Manager – Basic Customizing for all Products
Valuing Trades 327
Lesson 7
Defining Derived Business Transactions 341
Lesson 8
Understanding Interest Accruals 347
Exercise 23: Carry Out Settlement and Interest Accrual 353
Lesson 9
Configuring Account Determination 359
Exercise 24: Link to Accounting 371
Lesson 10
Replacing LIBOR 379
UNIT OBJECTIVES
● Understand traders and portfolios

● Configure traders and portfolios
● Understand financial transactions
● Define money market trade types
● Understand facilities
● Define foreign exchange trade types
● Understand product and transaction types for derivatives
● Define securities and listed derivatives trade types
● Define trade finance trade types
● Understand derived flows
● Use the deal release workflow
● Understand position management
● Configure position management
● Understand key date valuations
● Understand derived business transactions
● Understand interest accruals
● Understand aspects of account determination

● Learn about Benchmark Reform
● Know what changes on SAP with the benchmark replacement
● Know where to go to get more information

Unit 4
Lesson 1
Creating Traders and Portfolios
LESSON OBJECTIVES
Overview of Traders and Portfolios
Figure 135: Overview of Traders and Portfolios
Traders are defined by company code. The trader name length is 12 characters long. In this
step, the trader name is defined.
After the traders are created, specific authorizations must be defined by company code,
product type, transaction type, and trader ID. Without authorizing a trader to enter specific
transactions, they will receive an authorization error when initiating the transactions. Trader
authorizations are defined using the Trader Authorization tile. This step must be performed in
each system, as it is not transportable.
There should be a one-to-one relationship between trader name and SAP user. A trader name
is tied to an SAP username. When trades are entered into SAP by the SAP username user,
SAP will fill the Trader field with the Trader entered in this configuration step.

Lesson: Creating Traders and Portfolios
Figure 136: Overview of Traders and Portfolios
Portfolios are a criterion for grouping transactions for reporting (e.g. Credit Risk Analyzer,
Market Risk Analyzer, and standard TM reporting) and for the account determination. The
definition takes place per company code. The portfolio key can be up to 10 digits long.
You can create a portfolio and use it for trade reporting purposes. In this role, it groups the
financial transactions.
The portfolio field can have another role for securities positions. The position management
function of the Transaction Manager allows your accounting positions to be managed and
accounted for based on specific criteria in the financial transaction. It is possible to
distinguish securities positions by portfolio.
The portfolio is specified on the Administration tab of trades, and in most reports, the
portfolio field is a selection criteria and so can be used to filter on trades.
Similar to the trader field, portfolios are defined in customizing by company code.
Both the trader and portfolio fields are used consistently across the Transaction Manager
module.
Traders
Figure 137: Traders
Portfolios should be created for reporting purposes.

Traders can be defined for each company code to represent the business users entering
trades into SAP.

Figure 138: Traders
Traders are defined by company code. The trader name length is 12 characters long. In this
step, the trader name is defined.
In the next step, the trader name will be tied to an SAP username. There should be a one-to-
one relationship between trader name and SAP user.
The configuration node can be found under Financial Supply Chain Management → Treasury
and Risk Management → Transaction Manager → General Settings → Organization → Define
Traders.
User Settings
Figure 139: User Settings
In this step, a trader name is tied to an SAP username. When trades are entered into SAP by
the SAP username, SAP will fill the Trader field with the Trader entered in this configuration
step. There should be a one-to-one relationship between trader name and SAP user.

Note: Once the traders are created, specific authorizations must be defined by company
code, product type, transaction type, and trader ID. Trader authorizations are defined using
the Trader Authorization tile. This step must be performed in each system, as it is not
transportable.
An abbreviation for millions and thousands is specified by username. For example, for user
S4F51-00, if the user enters 10M into an amount field in trade entry, the system will
automatically change the amount to 10,000,000. The common abbreviations entered are T
for thousands and M for millions, though other abbreviations can be defined.
The working day check examines whether an entered date falls on a working day on the basis
of a particular calendar. The system reaction, by username, is driven by the entry specified
here.
Below are the possible options:
● 0 = A selection dialog is generated
● 1 = A warning message is generated
● 2 = An error message is generated
● 3 = No working day check is carried out
Lastly, the check criteria for an exchange rate input and swap rate input are specified. The
input check compares the values entered into trades with the current market data in the
market data tables. The associated user will receive warning messages if there are significant
differences between the rate entered in the trade and the corresponding market data rate.
Below are the possible options:
● Rate and swap entry check
● Only rate entry check
● Only swap entry check
● No check
These configuration settings are made in the customizing under Treasury and Risk
Management → Transaction Manager → General Settings → Organization → Define User
Data.

Portfolios
Figure 140: Portfolios
Portfolios are a criterion for grouping transactions for reporting (e.g. Credit Risk Analyzer,
Market Risk Analyzer, and standard TM reporting) and for the account determination. The
definition takes place per company code. The portfolio key can be up to 10 digits long.
Portfolios are defined in customizing under Treasury and Risk Management → Transaction
Manager → General Settings → Organization → Define Portfolio.
You can create a portfolio and use it for trade reporting purposes. In this role, it groups the
In the case of OTC transactions — that is, financial instruments in the areas of money market,
foreign exchange trading, and OTC derivatives — a transaction is the same as a position.
Because the portfolio as a reporting characteristic initially refers to transactions, it can be
seen only in those flows that are clearly assigned to a transaction.
The portfolio field can have another role for securities positions. The position management
function of the Transaction Manager allows your accounting positions to be divided up in a
flexible manner. You can specify that you want to distinguish between securities positions by
portfolio. In this case, two purchases of the same security with different portfolios, for
example, would give rise to different accounting positions, even if the purchases were made in
the same securities account. The portfolio is therefore a differentiating characteristic of a
securities position. This portfolio role has its own column in many reports. It is filled for
securities only, and even then only if you use the portfolio to differentiate between positions.
Note that although the portfolio is linked to the position, it originates from the transactions
that make up the position-that is, it originates from the same field that is also used as a
reporting characteristic.
The portfolio is specified on the Administration tab of trades, and in most reports, the
portfolio field is a selection criteria and so can be used to filter on trades.

The configuration node can be found under Financial Supply Chain Management → Treasury
and Risk Management → Transaction Manager → General Settings → Organization → Define
Portfolios.
How to Define a Portfolio
Simulation: How to Define a Portfolio

For more information on How to Define a Portfolio, please view the simulation in
the lesson Creating Traders and Portfolios online in the SAP Learning Hub.
Create Trader and Portfolio
Simulation: Create Trader and Portfolio

For more information on Create Trader and Portfolio, please view the simulation
in the lesson Creating Traders and Portfolios online in the SAP Learning Hub.


Unit 4
Exercise 4
Business Example
For company code TA##, a new trader must be defined and authorized to enter all trade
types into SAP. In addition, create a new portfolio. This is a customizing exercise. Use
transaction code SPRO, and following the path to Treasury and Risk Management.
Note:
1. A new employee has joined your team and needs authorization for trading financial
transactions. Create a new trader (NewTrader##) in the system.
Traders are required before you can create a financial transaction in the Transaction
Manager. To do this, a trader must be created in customizing, user assigned, and then the
trader needs to be authorized to enter trades into SAP.
2. Assign the SAP user (S4F51-##) to the new trader.

In customizing, assign your user S4F51-## to the NewTrader## that you have just
created.
3. On the application side, authorize the new trader for all available product types.
Return to the application side and authorize the NewTrader## that you have created in
company code, TA##.
4. A new portfolio is need, which is to be called S4F51-##. Create the portfolio S4F51-## in
company code TA##.

Unit 4
Solution 4
Business Example
For company code TA##, a new trader must be defined and authorized to enter all trade
types into SAP. In addition, create a new portfolio. This is a customizing exercise. Use
transaction code SPRO, and following the path to Treasury and Risk Management.
Note:
1. A new employee has joined your team and needs authorization for trading financial
transactions. Create a new trader (NewTrader##) in the system.
Traders are required before you can create a financial transaction in the Transaction
Manager. To do this, a trader must be created in customizing, user assigned, and then the
trader needs to be authorized to enter trades into SAP.
a) Choose Financial Supply Chain Management → Treasury and Risk
Management → Transaction Manager → General Settings → Organization → Define
Traders.
b) Select the company code TA##, and to confirm the selection, press Enter.
c) Choose New Entries, and enter the trader NewTrader## and a trader name Trader
##.
d) Choose Save.
The customizing is saved in a transport request. At the Prompt for customizing request
popup, the user should select the Create icon to create a transport request. The
customizing changes will go into the transport created.
e) Go back to the SAP Customizing Implementation Guide.
2. Assign the SAP user (S4F51-##) to the new trader.

In customizing, assign your user S4F51-## to the NewTrader## that you have just
created.
a) In the SAP Customizing Implementation Guide, choose Financial Supply Chain
Management → Treasury and Risk Management → Transaction Manager → General
Settings → Organization → Define User Data.
b) Choose New Entries, and enter your user name, and M and T in the relevant fields.
c) Assign the NewTrader## that you have just created to this user.

d) Choose Save.
e) Go back to the SAP Customizing Implementation Guide.
3. On the application side, authorize the new trader for all available product types.
Return to the application side and authorize the NewTrader## that you have created in
company code, TA##.
b) Choose the Manage Trader Authorizations tile from group Treasury - Master Data.
c) Enter the Company Code TA## and Trader NewTrader##, and to confirm the
selection, press Enter.
d) In the left-hand column at the top level, select the indicators for Money Market, Foreign
Exchange, and Securities and Derivatives.
e) Choose Save.
f) Go back to the SAP Fiori Launchpad.
4. A new portfolio is need, which is to be called S4F51-##. Create the portfolio S4F51-## in
company code TA##.
Settings → Organization → Define Portfolio.
b) Select company code TA##, and to confirm the selection, press Enter.
c) Choose New Entries, and enter the portfolio name S4F51-## (long name: Portfolio
##).
d) Choose Save.
e) Return to the SAP Customizing Implementation Guide. This concludes the exercise.

LESSON SUMMARY

Unit 4
Lesson 2
Defining Trade Types
LESSON OBJECTIVES
Financial Transactions Overview
Figure 143: Understanding Financial Transactions
As covered in the second chapter, the Transaction Manager module consists of the following
sub-modules:
● Money market
● Foreign exchange
● Derivatives
● Securities
● Commodities
● Trade Finance

Transaction Manager configuration is consistent wherever possible across different trade

types and sub-modules. For example, there are basic differences between money market
trades and derivative trades. Derivative trades have underlying assets, but money market
trades do not. The configuration required for the different trade types is going to be different.
However, understanding the configuration for intercompany loans, which is in the Money
Market submodule, greatly expedites the understanding of processing other trade types using
Transaction Manager.
The building blocks to defining financial instruments are product type, transaction type, flow
types, condition types, and update types. Settings are made at each of these levels to control
the functionality of the financial instrument. How to make the settings for these components
is a key point of implementing the Treasury and Risk Management module.
At this point, each of the components is defined. Keep in mind, for each component, there are
key settings which drive the functionality and processing for the trade type. Each submodule
in Transaction Manager will be considered, with emphasis placed on the ways the submodule
is different from previous sub-modules covered.
Product types - The product type classifies a financial instrument in SAP Treasury and Risk
Management. Differentiation is necessary as the individual instruments are subject to
different processing rules and/or to create different levels for reporting. Examples of product
types are intercompany loans, FX spot trades, FX forward trade, etc.
Transaction types - Transaction types are defined with respect to a product type and sub-
divide the product types by type of transaction. For example, the transaction types for a
product type representing a bond may be BUY and SEL.
Flow types - Flow types define the flows of a trade. For example, an FX forward contract has a
buy currency side (buy flow type) and a sell currency side (sell flow type).
Condition types - Condition types control how flows calculated by the system are handled,
such as interest, dividends, repayments, and charges.
Update types - The update type identifies the flow in position management and controls the
flow to the operative and parallel valuation areas. Each update type has a direction associated
with it.
Note: In Transaction Manager configuration, an element that has "type" in the name is an
element that can be defined in configuration. An element that has "category" in the name is
something that is predefined by SAP and not changeable. The categories are used in the
definition of types, (product types, transaction types, and flow types). For example, the SAP
system provides product categories that are used to define product types.

Lesson: Defining Trade Types
Figure 144: Financial Transactions Overview
Animation: Financial Transactions Overview

For more information on Financial Transactions Overview, please view the
animation in the lesson Defining Trade Types, online in the SAP Learning Hub.
Once you understand the processing and configuration for one trade type, it is easy to expand
that knowledge to other trade types, such as foreign exchange or derivative trades.
For example, the configuration for types of trades across all Transaction Manager sub-
modules requires the following:
Note: The above list is not meant to be an exhaustive list. There are other configuration nodes
that are relevant to all Transaction Manager trade types.
In addition, the valuation class, position management procedure, and account assignment
reference are required fields for trades across all Transaction Manager sub-modules.
Although the settings for each of the above configuration nodes could be different across the
different trade types, understanding the structure of the trades and the configuration process

for money market trades is going to be helpful in understanding how to configure foreign
exchange or derivative trades.
After the different trade types are defined, the other configuration such as account
determination, field status, etc., is the same across sub-modules.
Number Ranges
Figure 146: Understanding Product Types
Different number ranges can be used, which makes easier in the TM standard reporting to
select financial transaction positions. For example, intercompany loan transactions.
It is a good practice to use different number ranges for different categories of trades. For
example, have external money market trades fall into the number range of 10000000 to
19999999, and foreign exchange trades be assigned to the number range 20000000 to
29999999, etc. This way, just by knowing the trade number, Treasury users know what type
of trade it is.
Number intervals have to be specified in the context of the company code to ensure that the
transactions can be uniquely identified. The assignment of the number ranges are done per
product and transaction types, and is done by company code. Therefore a trade number is
unique within a company code.
Separate number ranges have to be created for transaction types with an underlying, and
these number ranges have to be assigned to the corresponding derivative product types.
Press the Status button to make changes to the current number. (Only use this function in the
test systems because consecutive numbering of the transactions must be guaranteed for
auditing reasons.)
It is possible to have the number ranges externally assigned. This could be used if, for
example, a front-office trading system is used and the front-office trading system determined
the trade number.
Follow customizing menu path Financial Supply Chain Management → Treasury and Risk
Management → Transaction Manager → Money Market → Transaction Management →
Transaction Types → Define Number Ranges. There is a corresponding path for Foreign
Exchange, Securities, Derivatives, etc.

Product and Transaction Types for Money Market
Figure 147: Understanding Product Types and Transaction Types
In Transaction Manager configuration, an element that has "type" in the name is an element
that can be defined in configuration. An element that has "category" in the name is something
that is predefined by SAP and not changeable. The categories are used in the definition of
types, (product types, transaction types, and flow types). For example, the SAP system
provides product categories that are used to define product types.
Below are the different types of money market product categories delivered with SAP:
● 510 - Fixed term deposit
● 520 - Deposit at notice
● 530 - Commercial paper
● 540 - Cash flow transaction
● 550 - Interest rate instrument
● 560 - Facility
● 580 - Current account-style instrument
Based on the different product categories, different product types are defined. For example,
using the facility product category, bilateral or syndicated credit facilities can be defined.
Using the interest rate instrument product category, a loan type instrument can be created.
Based on if the loan would be made with an external or internal party, the product type(s)
would be named accordingly.
The cash flow structures are different for the different money market product categories. For
example, facilities, interest instruments, cash flow transaction and deposit at notice, all have
different cash flow structures.
Time Deposits for Money Market
Time deposits can be subdivided into the following areas:
● Fixed-term deposits: Complete repayment and interest in a single amount.

● Interest rate instruments (used to flexibly map money market transactions that include
different forms of interest payments and repayments.) Interest rate instruments are used
to map money market transactions, which include different forms of interest calculations
and repayments. Interest rate instruments are typically used for intercompany loans.
- Start term and end term are fixed
- Fixed or variable interest rate
- Repayment
- Final repayment
- Annuity payment
- Installment payment
- No built-in rollover functionality
● Cash flow transactions (enable you to represent a wide range of transactions flexibly in the
money market. You enter the term manually and also the cash flow that results from the
particular structure of the transaction. This includes position changes, expenses,
revenues, and payments.)
- Variable payments at different times
- Different interest rates
● Facilities (enable you to map master credit lines between a lender and a fixed business
partner for a series of drawings on a credit facility). A line of credit is an agreement
between a lender and borrower to control the general conditions for a series of drawings
against a credit line. Overnights, fixed-term deposits, deposits at notice and interest rate
instruments can be assigned. Functions for changes, displays, history and reversals are
available.
- Unconfirmed facilities: Lender does not guarantee a credit limit. Usually no charges are
made for this.
- Confirmed facilities: Lender guarantees the availability of a limited credit amount at any
time. The borrower has to pay a charge for this.
Product Types and Transaction Types Overview

A product type is represented by a product key, such as 51A. The product type is assigned to
the product category that is used to control the transaction within the system. The product
types are mapped to product categories. These categories form the technical basis for ABAP
coding. Only this key information (for example, nominal amount, interest and maturity) is
required to describe the fixed-term deposit by 100%. Each product type can be assigned a
default interest calculation method. This setting may change when a new transaction is
created.
Typically, to distinguish intercompany from external transactions, different product types are
defined.

Figure 148: Product Types and Transaction Types Overview
Animation: Product Types and Transaction Types Overview

For more information on Product Types and Transaction Types Overview, please
view the animation in the lesson Defining Trade Types, online in the SAP Learning
Hub.
As mentioned previously, financial instruments are created by combining product type,

transaction type, flow types, condition types, and update types.
Keep in mind, for each component, there are key settings which drive the functionality and
processing for the trade type. Each sub-module in Transaction Manager will be considered,
with emphasis placed on the ways the sub-module is different from previous sub-modules
covered.
After the different trade types are defined, the other configuration such as account
determination, field status, etc., is the same across sub-modules.
Transaction types - Transaction types are defined with respect to a product type and sub-
divide the product types by type of transaction. For example, the transaction types for a
product type representing a bond may be BUY and SELL.
Derived flows are rules defined and assigned that are automatically created based on a flow in
the trade. A use of the derived flow functionality is for taxes, e.g. withholding taxes on
investments. For example, a derived flow rule can be customized to have a withholding tax
flow automatically be created to be 20% of the interest flow in the financial transaction. This
type of derived flow would then be automatically created in the trade based on the interest
flow in the financial transaction.

Flow types - Flow types define the flows of a trade. For example, an FX forward contract has a
buy currency side (buy flow type) and a sell currency side (sell flow type).
Condition types - Condition types control how flows calculated by the system are handled,
such as interest, dividends, repayments, and charges.
Update types - The update type identifies the flow in position management and controls the
flow to the operative and parallel valuation areas. Each update type has a direction associated
with it.
Figure 150: Product and Transaction Types for Money Market
Animation: Product and Transaction Types for Money Market

For more information on Product and Transaction Types for Money Market,
please view the animation in the lesson Defining Trade Types, online in the SAP
Learning Hub.
One of the first steps in configuring the system is having clear requirements of the types of
financial transactions that should be customized. Take the example of a fixed term deposit
investment.
A fixed-term deposit includes the following information:
● An amount is paid at the inception of the trade
● Interest is paid at maturity
● Repayment of principal is paid at maturity
With the help of this information, the system is able to create the cash flow structure.
Additional cash flows can be matched, but this is not necessarily required.
The cash flow structure of a fixed-term deposit can be structured as follows:

● Position cash flows, for example, investment, borrowing happen at inception and at
maturity
● Periodic condition cash flows, for example, interest
● Charges
● Taxes
● Cash flows from period-end closing, for example, accrued interest and valuations
With difference procedure (also known as incremental postings), the incremental interest
accrual amount from the last accrual date or month-end date to current month-end date is
booked on the last day of the month.
With reset procedure (also known as book and reverse postings), the full interest accrual
amount from the inception of the trade or last interest payment to month-end date on the last
day of the month is booked (T0), and then the full amount is reset the next day (T1). This
approach is the cleanest when dealing with foreign currency accruals as there is no chance for
there to be exchange rate issues that would produce false gains and losses.
Figure 152: Define Product Types
The default interest calculation method can be specified at the product type level. If it is not
specified here, it can be specified manually at trade entry. Note: If one interest calculation
method is not always used, it may be best not to default it, as this may risk it be set
incorrectly.
Define money market product types in customizing by following the path Financial Supply
Chain Management → Transaction Manager → Money Market → Transaction Management →
Product Types → Define Product Types.

Figure 153: Order-Settlement-Contract
The number ranges are assigned to the transaction types.

You also specify information on the processing for the trade by assigning in the Processing
Category field which processes a transaction must pass through, for instance, from order
(bid), to contract, to settlement. There are a number of different Processing Categories to
choose from. The Processing Category drives the different status of a trade.
The Settlement step can be used as an approval step. If the Processing Category includes a
Settlement step, the trade cannot be posed to the SAP general ledger until the trade has been
settled, e.g. has been moved to the settlement category.
The Processing Categories is defined per transaction type. The process chain is specified
using the processing control entry.
If you use the new correspondence, you can automatically settle transactions when the
counterconfirmation is received for the correspondence sent. If this automatic settlement for
counterconfirmation is to take place for a transaction type, you must set the Automatic
Settlement for Counterconfirmation indicator.
Figure 154: Define Transaction Types
Transaction types are defined and assigned with respect to a product type. Every transaction
type must be assigned to its relevant product type at the time it is created. Transaction types
define how an instrument is to be used. For example, a transaction type for money market

trades typically indicates the direction of the trade, e.g. buy or sell, and drive the direction of
the product cash flows.
A transaction category is assigned to the transaction type. The possible transaction
categories depend on the product category, which was assigned to the product type.
`Number ranges are assigned at the transaction type level.
The processing category is assigned at the transaction type level. The processing category
determines the possible process steps for the financial transaction, which often is driving if
there will be bid (offer) tracking and whether or not the transaction will need to be "SAP
settled" (released to accounting) after creation; that is, the processing category defines the
individual steps to be carried out for a transaction. The status transitions available as activity
categories in the area of money market are the following:
● Order - Contract: 00001
● Order - Contract - Settlement: 00002
Additionally, the posting release for individual cash flows can be left on or turned off. If the
Automatic posting release is selected, the trade must be released before it is posted to the
ledger. This will be covered in the Deal Release Workflow objective of this course.
If required, a limit group can also be assigned. Using limit product groups, different product
and transaction types can be grouped in order to update the default risks of these
transactions in the Credit Risk Analyzer. This will be covered in the Credit Risk Analyzer
lesson of this course.
If using the correspondence functionality, you can have the trade automatically settled when
the counterconfirmation is received for the correspondence sent. If this automatic settlement
for counterconfirmation is to take place for a transaction type, you must set the Automatic
Settlement for Counterconfirmation indicator.
Define money market transaction types in customizing by following the path Financial Supply
Transaction Types → Define Transaction Types.
How to Configure an Interest Rate Instrument Product Type and Transaction

Type
Simulation: How to Configure an Interest Rate Instrument Product Type and

Transaction Type
For more information on How to Configure an Interest Rate Instrument Product
Type and Transaction Type, please view the simulation in the lesson Defining
Trade Types online in the SAP Learning Hub.
Maintain Product and Transaction Types in Money Market
Simulation: Maintain Product and Transaction Types in Money Market

For more information on Maintain Product and Transaction Types in Money
Market, please view the simulation in the lesson Defining Trade Types online in


Unit 4
Exercise 5
Maintain Product and Transaction Types in
Money Market
Business Example
For prototyping purposes, you would like to create a new custom fixed term deposit product
type and transaction type. This is a customizing exercise. Use transaction code SPRO, and
following the path to Treasury and Risk Management.
Note:
1. Create a product type 5## (your group number) with the product category 510 (fixed-
term deposit). Assign the interest calculation method act/360 to this product type.
Table 17: Product Type

Field Name Value
Product Type 5##
Text Fixed-term deposit 5##
Product Category 510 Fixed-Term Deposit
Interest calculation method act/360
Fee calculation Do not include competitive bids
2. Assign transaction types 100 (investment) and 200 (borrowing) to this product type.
From the process point of view, do not specify a cash flow release, and counter
confirmation and settlement is required.
Table 18: Transaction Type 100

Field Name Value
Product Type 5##
Transaction Type 100 (Investment)
Transaction Category 100 (Purchase)
Number ranges
Transactions 05

Field Name Value

Processing
Processing Cat. 00001
Automatic posting release Yes (Select the indicator)
Automatic settlement for counter confir- No (Do not select the indicator)
mation

Field Name Value
Product Type 5##
Transaction Type 200 (Borrowing)
Transaction Category 200 (Sale)
Number ranges
Transactions 05
Processing
mation
3. Create a Cash Management connection for the new product type 5## so new trades
reflect in the cash position. Use planning level TM.
Table 20: Planning Level

Field Name Value
Product Type 5##
Status <Leave blank>
Activity Category 10
Level bank(known) TM
Level bank (unknown) TM

Unit 4
Solution 5
Money Market
Business Example
For prototyping purposes, you would like to create a new custom fixed term deposit product
type and transaction type. This is a customizing exercise. Use transaction code SPRO, and
following the path to Treasury and Risk Management.
Note:
1. Create a product type 5## (your group number) with the product category 510 (fixed-
term deposit). Assign the interest calculation method act/360 to this product type.

Field Name Value
Product Type 5##
Text Fixed-term deposit 5##
Product Category 510 Fixed-Term Deposit
Fee calculation Do not include competitive bids
a) Use transaction SPRO to switch to customizing.
b) In the SAP Customizing Implementation Guide, choose Financial Supply Chain

Management → Treasury and Risk Management → Transaction Manager → Money
Market → Transaction Management → Product Types → Define Product Types.
c) To create product type 5##, choose New Entries.
d) Enter the data provided in the table, Product Type.
e) Choose Save.
2. Assign transaction types 100 (investment) and 200 (borrowing) to this product type.
From the process point of view, do not specify a cash flow release, and counter
confirmation and settlement is required.


Field Name Value
Product Type 5##
Transaction Category 100 (Purchase)
Number ranges
Transactions 05
Processing
mation

Field Name Value
Product Type 5##
Transaction Type 200 (Borrowing)
Transaction Category 200 (Sale)
Number ranges
Transactions 05
Processing
mation

Market → Transaction Management → Transaction Type → Define Transaction Type.
b) To create a new transaction type, choose New Entries.
c) Enter the data provided in the table, Transaction Type 100.
d) Choose Save.
e) To create the second transaction type, choose New Entries.
f) Enter the data provided in the table, Transaction Type 200.
g) Choose Save.

h) Return to the SAP Customizing Implementation Guide.
TE QUEDASTE AQUI 3. Create a Cash Management connection for the new product type 5## so new trades
reflect in the cash position. Use planning level TM.
Table 20: Planning Level

Field Name Value
Product Type 5##
Status <Leave blank>
Activity Category 10
Level bank(known) TM
Level bank (unknown) TM

Settings → Link to Cash Management → Assign Planning Level.
b) Select the company code TA##, and choose New Entries.
c) Enter the data provided in the table, Planning Level.
d) Repeat this setting for Activity Category 11, 20, and 21.
e) Choose Save.

Flow Types for Money Market
Figure 157: Define Flow Types for Money Market
Money market products can be structured into investment and borrowing transactions by
using the transaction type field. Related to the structure of money market products, in this
step, you will define different flow types to represent the cash flows and structures of the
products. After defining the flow types, you will assign these flow types to the associated
product and transaction types.
Flows describe various payment flows arising from transaction conclusion, valuation and
accrual/deferral functions as well as transfer postings. They are classified through flow types
that you define in customizing.
The sum of all transaction flows forms the basis for generation of the cash flow and describes
possible changes to the updated payment flows. They also form the basis for updating
transactions in FI and Cash management and for analysis in Market risk management.
Possible flow types include interest rates, repayments, principal increases, and fees.
It is the Flow Category setting that controls how the individual financial flows are handled in
the system.
Different flow types can be created and edited in this step.
Settings at Flow Type Level
Below are the different settings at the flow type level:
● Classify structure characteristics.
● Structure characteristics have to be selected for an investment/increase.
● Accrual/deferral is used if, for example, interest payments have to be accrued/deferred
for a month
● Valuation is selected for all flows resulting from a valuation.

● Transfer, for example "held for trading" transferred to "available for sale", only to be used if
the assignment to the balance sheet items is altered.
● The other fields (flow type, relevant to Cash Management, and so on) control the internal
handling of the cash flows.
For example, an investment/increase flow is relevant to:

● Cash management
● The position
● Valuation
● Posting
but not to profit or accrual/deferral.

● It also would, in many cases, generate a payment request.
Payment request:
● If for outgoing payments is selected, payments can be generated for amounts due,
provided this has been set in the business partner or transaction.
● If for incoming payments is selected, it is to be used in the context of direct debits or other
incoming payments.
Note the specification of whether a payment request is created at the time of posting to
create a payment request. This is a required setting to generate a payment request.
To define flow types, follow the customizing menu path Financial Supply Chain Management
→ Treasury and Risk Management → Transaction Manager → Money Market → Transaction
Management → Flow Types → Define Flow types.
Assign Flow Types for Money Market
Figure 158: Assign Flow Types for Money Market
After you have defined flow types, you have to assign these to the transaction and product
types. Only the cash flows for condition, nominal and derived flows are assigned. Flows for

valuation and accrued interest are not assigned, because there are additional flows which are
not required to describe the product.
To assign flow types to product and transaction types, follow the customizing menu path
Financial Supply Chain Management → Treasury and Risk Management → Transaction
Manager → Money Market → Transaction Management → Flow Types → Assign Flow types to
Transaction Type.
Assign Flow Types
Simulation: Assign Flow Types

For more information on Assign Flow Types, please view the simulation in the
lesson Defining Trade Types online in the SAP Learning Hub.

Unit 4
Exercise 6
Assign Flow Types
Business Example
You receive some requirements from the front office departments, to set up a new money
market product type. Continuing from the last exercise where a new fixed term product type
and transaction types were created, you now need to assign flow types to the product type
and transaction types.
This is a customizing exercise. Use transaction code SPRO, and following the path to Treasury
and Risk Management.
Dependencies
This exercise uses the following objects that were created in previous exercises:
Table 21: Dependencies

Product Type Transaction Type
5## 100
5## 200
In this exercise, you continue to build your own fixed term deposit product type. To be able to
use this new fixed term deposit product type, it must have the correct condition types
assigned to it, which is done in this step.
Note:
1. Implement the relevant cash flow structure for product type 5## with transaction type
100 and 200.
Table 22: Flow Types

Field Name Value
1100 Investment/ Increase
1120 Final Repayment
1150 Interest Capitalization
1200 Nominal Interest
1900 Charges
1901 Commission

Field Name Value

1905 (for transaction type 100) Withholding tax 1 (for example, state)
1906 (for transaction type 100) Withholding tax 2 (for example, region)
5000 (for transaction type 100) Interest income tax
5001 (for transaction type 100) Reunification tax (Germany)

Unit 4
Solution 6
Assign Flow Types
Business Example
You receive some requirements from the front office departments, to set up a new money
market product type. Continuing from the last exercise where a new fixed term product type
and transaction types were created, you now need to assign flow types to the product type
and transaction types.
Dependencies

5## 100
5## 200
Note:
1. Implement the relevant cash flow structure for product type 5## with transaction type
100 and 200.
Table 22: Flow Types

Field Name Value
1100 Investment/ Increase
1200 Nominal Interest
1900 Charges
1901 Commission

Field Name Value


Market → Transaction Management → Flow Types → Assign Flow Types to
Transaction Type - MM Transactions.
b) Assign the existing flow types to product type 5## and to transaction types 100 and
200.
c) Choose New Entries.
d) Enter the data provided in the table, Flow Types.
e) Choose Save.
Note:
It is no longer necessary to assign the update types because we can use
the update types that are already available. They are automatically
determined from the assignment to the flow types.

Condition Types for Money Market
Figure 160: Define Condition Types for Money Market
At the base of the cash flow structure, you will define different condition types. Behind each
condition types, different mathematical formula can be assigned. This formula gives more
flexibility for the cash flow generation.
Condition types control how flows calculated by the system are handled, such as interest,
repayments, and charges. For example, they enable you to individually control interest rate
flows. Condition types automatically generate flows which are the basis for further processing
in FI and Cash management as well as for analysis in Market risk management.
To your condition types, you assign:
● a classification
● a condition category, and
● a flow type.
The classification divides up the condition types according to business criteria. Via the chosen
classification, you restrict the possible condition categories. Condition categories allow the
system to interpret and process your settings.
There is a 1:1 relationship between the condition types and flow types. In other words,
precisely one flow type has to be created for each condition type. However, a flow type does
not have to be assigned to a condition type if no cash flows that are to be calculated are
mapped using the flow type.
Conditions can be classified using the following categories:
● Structure characteristics
● Accrual/deferral
● Valuation

● Transfer
To define condition types, follow the customizing menu path Financial Supply Chain
Management → Treasury and Risk Management → Transaction Manager → Money Market →
Transaction Management → Condition Types → Define Condition Types.
Figure 161: Assign Condition Types for Money Market
After condition types have been defined, they have to be assigned to the product and
transaction types.
To assign condition types to product and transaction types, follow the customizing menu path
Manager → Money Market → Transaction Management → Condition Types → Assign
Condition Types to Transaction Type.
Assign Condition Types and Default Valuation Class
Simulation: Assign Condition Types and Default Valuation Class

For more information on Assign Condition Types and Default Valuation Class,
please view the simulation in the lesson Defining Trade Types online in the SAP
Learning Hub.

Unit 4
Exercise 7
Assign Condition Types and Default Valuation
Class
Business Example
Continuing with building your fixed term deposit product type, assign all required condition
types to it. Also, assign a default valuation class to your new product type so this field does
not need to be set manually by users at trade entry.
This is a customizing exercise. Use transaction code SPRO, and follow the path to Treasury
Dependencies
Table 23: Dependencies 1

5## 100
5## 200
In addition, the following flow types were assigned to your product type and transaction
types:

Field Name or Data Type Long Text
1100 (for transaction type 100) Investment / Increase
1105 (for transaction type 200) Borrowing / Increase
1110 Decrease
1901 Charges
1902 Commission

Note:
1. Assign the relevant condition types to product types 5##, with transaction type 100 and
200.
Table 25: Condition Types

Field Name Value
1150 Interest capitalization
1200 Nominal interest
2. Assign a general valuation class to your product type.
Table 26: General Valuation Class 100

Field Name Value
Company code TA##
Product type 5##
Transaction type 100(Investment)
General valuation class Short-term debt/investment: 001 AMC;
002 AMC (211)

Field Name Value
Company code TA##
Product type 5##
Transaction type 200(Borrowing)
002 AMC (211)

Unit 4
Solution 7
Assign Condition Types and Default Valuation
Class
Business Example
Continuing with building your fixed term deposit product type, assign all required condition
types to it. Also, assign a default valuation class to your new product type so this field does
not need to be set manually by users at trade entry.
This is a customizing exercise. Use transaction code SPRO, and follow the path to Treasury
Dependencies

5## 100
5## 200
In addition, the following flow types were assigned to your product type and transaction
types:

Field Name or Data Type Long Text
1100 (for transaction type 100) Investment / Increase
1105 (for transaction type 200) Borrowing / Increase
1110 Decrease
1901 Charges
1902 Commission

Note:
1. Assign the relevant condition types to product types 5##, with transaction type 100 and
200.

Field Name Value
1150 Interest capitalization

Market → Transaction Management → Condition Types → Assign Condition Types to
Transaction Type - MM Transactions.
b) To assign the condition types, choose New Entries.
c) Enter the data provided in the table, Condition Types, to your product Type and
transaction type>
d) Choose Save.
Note:
It is not necessary to assign the update types because the update types
that are already available can be used. They are automatically taken from
the flow types.
2. Assign a general valuation class to your product type.

Field Name Value
Company code TA##
Product type 5##
Transaction type 100(Investment)
002 AMC (211)


Field Name Value
Company code TA##
Product type 5##
Transaction type 200(Borrowing)
002 AMC (211)

Market → Transaction Management → Assign General Valuation Class - MM
Transactions.
b) Assign the relevant general valuation classes to your product type. You can copy the
entries.
c) Assign the general valuation classes provided in the tables to your product type 5##.
d) Choose Save.

Update Types and Assignment to Flow Types
Figure 163: Update Types for Money Market
The three steps covered in this section are shown above.
Figure 164: Define Update Types
Like flow types, update types correspond to cash flows. Update types control the posting of
individual flows.
A wide variety of update types are available in the system. The names of the types have been
clearly selected so that all update types that start with MM belong to the money market area.
The different submodules in Transaction Manager have different naming conventions.
The name and update type of the usages (such as transaction management or valuation) are
assigned here. The update types are no longer module-dependent and have an implicit
direction. This means, for example, that incoming and outgoing charges must be represented
as two different update types.
The new update types consist of the definition itself. No further indicators are defined directly
with the update types.
To define condition types, follow the customizing menu path Financial Supply Chain
Transaction Management → Condition Types → Define Condition Types.

Figure 165: Update Types and Assignment to Flow Types
In this configuration step, you define the update types. It is a two-step process. The first step
defines the update types. The second step assigns a usage to the update type. Update types
can be defined based on the defined flow types which represent the cash-flow structure of the
transaction. Update types include additional information about direction and sub-module.
The screenshot above shows the assign usages step, which is the second step. The update
type usage is set to Transaction Management for the transactional update types. In most
cases, the SAP delivered update types can be used.
The possible usage types are:
● Transaction management
● Securities account management
● Securities account transfer
● Corporate action
● Valuation class transfer
● Exercising rights
● Key date valuation
● Derived business transactions
● Other flows
The assignment of money market update types can be customized by following the menu
path Financial Supply Chain Management → Treasury and Risk Management → Transaction
Manager → Money Market → Transaction Management → Update Types → Define Update
Types and Assign Usages.

Figure 166: Assign Update Types to Flow Types
The link to Accounting for the trade types is created in this step. The account determination
on SAP is done by update type. In other words, the posting specification is at the update type
level. Flow types do not have a direction assigned to them, but update types do imply a
direction of flow.
When creating a new assignment, there is a differentiation between inflows and outflows by
update type.
The Contract Type is subdivided into the following areas:
● Money market
● Derivatives (tradable and non-tradable positions)
● Securities
● Commodities (tradable and non-tradable positions)
To assign flow types to update types, follow the customizing menu path Financial Supply
Chain Management → Treasury and Risk Management → Transaction Manager → Money
Market → Transaction Management → Update Types → Assign Flow Types to Update Types.
How to Create an External Loan Trade Type and Sample Trade
Simulation: How to Create an External Loan Trade Type and Sample Trade
For more information on How to Create an External Loan Trade Type and Sample
Trade, please view the simulation in the lesson Defining Trade Types online in the
SAP Learning Hub.
Create Fixed-Term Deposit Transaction
Simulation: Create Fixed-Term Deposit Transaction

For more information on Create Fixed-Term Deposit Transaction, please view the
simulation in the lesson Defining Trade Types online in the SAP Learning Hub.

Unit 4
Exercise 8
Business Example
After finishing the customizing activities, you should test the new fixed-term deposit product
type in the application. In the trade, on the Status tab, verify that a release is required. All
financial transactions need to be integrated into the daily cash position. Validate that the new
trade is reflected in the cash position.
To create a money market trade, select the Create Financial Transaction tile (Treasury –
Trade Processing).
Dependencies
The following dependencies exist:
● In the exercise Create a Business Partner, the business partner BP## was created.
● In the exercise Create Securities Class Data, the following product type 500 and
transaction type 100 were created.
● In the exercise Create Trader and Portfolio, flow types were assigned to product type 500
and transaction type 100.
● In the exercise Maintain Product and Transaction Types in Money Market, condition types
were assigned to the 5## product type and the 100 transaction type.
● In the exercise Assign Condition Types and default Valuation Class, a general valuation
class was assigned to the product type 500 and transaction type 100.
Note:
replace it with your two-digit group number
1. Create a new financial transaction. Enter product type 5## and transaction type 100 in
your company code TA##. Use the BP## business partner you created.
Use of the following data to create the transaction:
Table 28: Transaction data

Field Name Value
Payment Amount 50 million EUR
Percentage rate 2.6%
Start Date Today
End Date 3 months starting from today

Field Name Value

Interest calculation method Act/360
(Interest) frequency <At end of term>
Portfolio S4F51-##

Unit 4
Solution 8
Business Example
After finishing the customizing activities, you should test the new fixed-term deposit product
type in the application. In the trade, on the Status tab, verify that a release is required. All
financial transactions need to be integrated into the daily cash position. Validate that the new
trade is reflected in the cash position.
To create a money market trade, select the Create Financial Transaction tile (Treasury –
Trade Processing).
Dependencies
The following dependencies exist:
● In the exercise Create a Business Partner, the business partner BP## was created.
● In the exercise Create Securities Class Data, the following product type 500 and
transaction type 100 were created.
● In the exercise Create Trader and Portfolio, flow types were assigned to product type 500
and transaction type 100.
● In the exercise Maintain Product and Transaction Types in Money Market, condition types
were assigned to the 5## product type and the 100 transaction type.
● In the exercise Assign Condition Types and default Valuation Class, a general valuation
class was assigned to the product type 500 and transaction type 100.
Note:
1. Create a new financial transaction. Enter product type 5## and transaction type 100 in
your company code TA##. Use the BP## business partner you created.
Use of the following data to create the transaction:
Table 28: Transaction data

Field Name Value
Payment Amount 50 million EUR
Percentage rate 2.6%
Start Date Today
End Date 3 months starting from today

Field Name Value

(Interest) frequency <At end of term>
Portfolio S4F51-##
a) Logon to the SAP Fiori Launchpad.
b) Choose theCreate Financial Transaction tile (Treasury – Trade Processing).
c) At the Create Financial Transaction screen, enter the values for product type 5## and
transaction type 100 in your company code (TA##). Use the BP## business partner
you created. Choose Create.
d) Enter the values provided in the table, Transaction data, and to verify the values, press
Enter.
e) Choose Conditions, and check the condition details of your contract and then choose
Back.
f) Choose the Cash Flow tab, and check the flows automatically created for your
contract.
g) Choose the Payment Details tab, and ensure that the payment request box is selected
for the outgoing flow.
h) Choose the Status tab, and verify that no settlement and no release is required in the
lower part of the Transaction section.
i) Choose Save.
Note the transaction number for later settlement activities and postings.
[Correct answer]
j) Return to the SAP Fiori Launchpad.

Overview of Credit Facilities
Figure 169: Key Terms Related to Credit Facilities
Most companies have credit facilities with their primary bank. SAP's Transaction Manager
module can be used to support the life cycle of credit facilities-tracking of trades, validation of
invoices from the banks, accounting entries, payment of fees, and reporting.
Credit facilities are borrowing vehicles for companies. Most companies have either a
committed or uncommitted credit facility to support their liquidity needs. The extent to which
a company has a committed or uncommitted credit facility depends on conditions such as its
liquidity situation, bank fees, or type of business. SAP supports committed, uncommitted,
and syndicated credit facilities.
The credit facility trade is the vehicle to calculate the use and fees of a credit facility. The only
cash flows triggered by a credit facility trade are the fees. Separate trades are created for
borrowings against the credit facility and letter-of-credit trades. These separate trades are
linked to a credit facility trade and affect the credit facility's utilization numbers. The interest
on a borrowing can take the form of a fixed amount, fixed rate, or variable rate.
Key Terms Related to Credit Facilities
Below are the definitions of terms related to credit facilities:
● Facility: a term used for credit facility.
● Revolver: a term used for credit facility.
● Syndicated credit facility: A syndicated bank facility is a loan offered by a group of lenders
— referred to as a syndicate — that work together to provide funds for a single borrower.
The amount of one syndicated loan is so big that one lender cannot fund or take on the
debt alone. Corporations are usually the borrowers for this type of loan. There will be a lead
lender or arranger for each consortium.
● Bilateral credit facility: With a bilateral business loan, the only two parties are the lender
and the borrower. Instead of multiple lenders with the syndicated credit facility, the
borrower deals directly with one bank.
● Committed credit facility: A committed credit line is a monetary spending loan balance
offered by a financial institution that cannot be suspended without notifying the borrower.
A committed credit line is a legal agreement between the financial institution and the
borrower outlining the conditions of the credit line. Once signed, the agreement requires
the financial institution to lend money to the borrower, provided that the borrower does
not break the conditions.

● Uncommitted credit facility: An uncommitted facility is an agreement between a lender

and a borrower in which the lender agrees to make short-term funding available to the
borrower; this is in contrast to a committed facility that involves clearly defined terms and
conditions set forth by the lending institution and imposed on the borrower. An
uncommitted credit facility does not include quarterly fees. It is possible for the
uncommitted lines of credit to have the upfront and miscellaneous fees.
● Draw: A draw is a borrowing against a credit facility. It is sometimes also referred to as a
tranche.
● Swingline: A swingline borrowing is a borrowing from one of the syndicated partners on a
syndicated credit facility as opposed to from the main syndicate bank.
Understanding Facilities
Figure 170: Understanding Syndicated Facilities
Syndicated facilities are credit lines between a lender and a consortium of different business
partners. The facility contract is signed only with the consortium leader. A partner ranking is
required for the structuring of the different business partners.
Bilateral facilities have one borrower and one lender, whereas syndicated facilities have a
borrower and several lenders, each contributing to the total credit facility amount. For
syndicated credit facilities where there are multiple lenders, you must specify which tasks the
business partners can take on in connection with the facility. The different type of roles are
defined with the Define Partner Rank customizing.
The Define Partner Rank customizing can be found in the IMG under Treasury and Risk
Syndicated Facility → Define Partner Rank.

Figure 171: Understanding Facilities - Product Category
SAP provides the Product Category facility to support the management of credit facilities.
This product category is able to establish limits, has the ability to attach specific borrowings
or drawings, and will, if applicable, calculate fees associated with the agreement. In
configuration, the credit facility product types must be defined with the Product Category
Facility (560). The Facility product category represents a revolving line of credit available to a
company. It allows for the management and tracking of fees and utilization of the line based
on individual draws.
The product type is assigned to the product category that is used to control the transaction
within the system. The product types are mapped to product categories. Only this key
information (for example, nominal amount, interest and maturity) is required to describe the
fixed-term deposit by 100%. Each product type can be assigned a default interest calculation
method. This setting may change when a new transaction is created.
There should be separate product types to track committed versus uncommitted credit
facilities. In addition, a product type for the draws or borrowings against the credit facility
needs to be created.
Define money market product types in customizing by following the path Financial Supply
Product Types → Define Product Types.
Figure 172: Understanding Facilities - Transaction Category

A facility transaction type has transaction category 200 indicating a borrowing or liability
position, as shown above.
Define money market transaction types in customizing by following the path Financial Supply
Transaction Types → Define Transaction Types.
Note: The remaining customizing related to facilities follows the same steps and framework
as the other product types.
Figure 173: Structure of Credit Facilities
You can use the Charges tab to specify charges. Depending on utilization, for example, you
can apply a different interest rate. In order to do this, you must have defined condition types
(for example, Facility fee unutilized, Facility fee due, Facility fee overdrawn, and Facility fee
available).
The only cash flows triggered by a credit facility trade are the fees. A number of different fees
are associated with credit facilities. The different fees depend on the type of credit facility
being tracked (i.e., committed versus uncommitted credit facility).
The up-front fee, annual administration fee, miscellaneous fee, and terminated contract fees
are entered as Other Flows in the credit facility trades (for example, they are entered in the
Other Flows tab in the trades).
Uncommitted lines of credit do not generate quarterly fees because there are no commitment
fees directly associated with them. Uncommitted lines of credit can have up-front and
miscellaneous fees.
The credit facility fees are often accrued monthly, which is supporting using the Treasury and
Risk Management Accrual functionality outlined later in this unit.
How to Use Credit Facility Functions
Simulation: How to Use Credit Facility Functions

For more information on How to Use Credit Facility Functions, please view the

Product and Transaction Types for Foreign Exchange
Figure 175: Structure of FX Financial Transactions
Foreign Exchange Transaction is used for hedging and for investment activities.
The splitting of both activities is done via the portfolio settings.
● Spot Transaction:
A spot transaction is an agreement between two participants to buy and sell a fixed
defined amount at a future date. The maturity of this contract type is 2-3 days. The current
spot market rate is used to calculate the exchange rate.
● Forward Transaction:
A forward transaction is an agreement between two participants to buy and sell a fixed
defined amount at a future date. The maturity of this contract type is longer than 3 days.
The current forward market rate is used to calculate the exchange rate.
● FX Swap:
Foreign exchange swap transactions are an important part of foreign exchange
management. When you create a foreign exchange swap in the SAP system, a spot
transaction and a forward transaction are created simultaneously. The foreign currency
bought today is sold at a later date, or the foreign currency sold today is bought back at a
later date.
Note: Because specifying if an FX financial transaction is relevant to hedge management is

done at the product type level, separate product types should be created for FX trades that
will be used as hedges versus those that will not. This will be covered more in Unit 7 Hedge
Management and Accounting.

FX Product Types and Transaction Types Overview
Figure 176: FX Product Types and Transaction Types Overview
Animation: FX Product Types and Transaction Types Overview

For more information on FX Product Types and Transaction Types Overview,
Learning Hub.
The slide above shows the distinction between "category" components, e.g. transaction
category, that are defined by SAP, and "type" components, e.g. transaction types, that are
defined in customizing.
Unlike in money market trading, condition types are not necessary in foreign exchange
trading.
Figure 178: FX Product Types and Transaction Types

Animation: FX Product Types and Transaction Types

For more information on FX Product Types and Transaction Types, please view
the animation in the lesson Defining Trade Types, online in the SAP Learning
Hub.
Before you should start the customizing of FX product and transaction types, the process
chain per product type should be decided upon, as these settings are made at the transaction
type level.
With the processing category, you can decide if a settlement is necessary or not. Additionally,
you define if you would use the deal-release workflow, the counter-confirmation, and the
manual cash-flow release procedure for posting. You can define if the counter-confirmation is
available in SAP and can be matched automatically to the transaction, the contract is then
settled automatically by the system.
Define Product Types
We can differentiate between the following foreign exchange transactions:

● Spot transactions, which have the following characteristics:
- Due immediately, that is, on the second bank workday after conclusion of the contract.
- Mainly intended for processing international payment transactions.
- If no value date is specified in the transaction, the system automatically assumes that a
spot transaction is to be created and moves the value date two days forward.
● Forward transactions:
- Transaction fulfilled on the agreed date.
- Settlement rate/forward rate is fixed upon conclusion of the transaction.

- Intended for hedging of exchange rate risks - reliable calculation basis, especially in
international trade.
● Foreign exchange transactions are used to hedge foreign currency fluctuations. To
structure the categorization more clearly, products are subdivided into product
categories. For example, product type 60A is assigned to product category 600.
Each product type in the foreign exchange area has a different settlement structure. The
possible settlement types include:
● Cash settlement (Non-deliverable forwards are cash settled.)
● Physical settlement
The FX product types can be customized by following the menu path Financial Supply Chain
Management → Treasury and Risk Management → Transaction Manager → Foreign
Exchange → Transaction Management → Product Types → Define Product Types.
Note: FX option contracts will be discussed when the Derivatives submodule is covered -
Objective: Derivative Trade Types.
Define Transaction Types
The spot and forward transactions are differentiated via transaction type. The following
transaction types are relevant for foreign exchange transactions:
● Netting
● Rollover
● Premature settlement
● Fixing
The FX transaction types can be customized by following the menu path Financial Supply
Chain Management → Treasury and Risk Management → Transaction Manager → Foreign
Exchange → Transaction Management → Transaction Types → Define Transaction Types.

FX Product Types and Transaction Types Attributes
Figure 182: FX Product Types and Transaction Types Attributes
In this step, you maintain the attributes for foreign exchange transactions:
● Choose New entries. Enter the relevant product type/transaction type.
● Enter the rate type (for example, M for middle rate) for translating foreign currency
amounts.
● If you want the system to automatically propose a rate in the spot field when you create a
forex transaction, flag the relevant indicator.
● Enter the transaction types which are to be used for rollover or premature settlement of
forward or offsetting transactions.
● If you want the fields local currency amount and local currency rate for foreign currency
flows to be filled automatically when you create a transaction, flag the field Translation of
foreign currency flow.
The Forex Attributes can be customized by following the menu path Financial Supply Chain
Exchange → Transaction Management → Transaction Types → Assign Forex Attributes.

Figure 183: FX Product Types and Transaction Types
Animation: FX Product Types and Transaction Types

For more information on FX Product Types and Transaction Types, please view
Hub.
The leading currencies for various currency pairs is defined, that is the currency that is
identified first when quoting the rate. The system uses these settings to determine the rate
notation when you enter foreign exchange transactions and foreign exchange options. For
example, the EUR leads all other currencies, USD leads JPY, etc.
Additionally, the number of days between conclusion of a foreign exchange transaction and
the value date for spot transactions can be defined. Usually, this is typically two working days,
however, depending on the currency, there may be deviations from this rule. Entries should
only be made in this field if practices on the international foreign exchange market follow a
different rule other than the usual two day rule.
The Forex Attributes can be customized by following the menu path Financial Supply Chain
Management → Treasury and Risk Management → Transaction Manager → General Settings
→ Transaction Management → Currencies → Define Leading Currency.
Maintain Product and Transaction Types in Foreign Exchange
Simulation: Maintain Product and Transaction Types in Foreign Exchange

For more information on Maintain Product and Transaction Types in Foreign
Exchange, please view the simulation in the lesson Defining Trade Types online in

Unit 4
Exercise 9
Foreign Exchange
Business Example
You receive a requirement from your manager to create a new foreign exchange product type
in SAP.
Note:
1. Create a product type 6## (use your group number) with product category 600 (foreign
exchange). Assign the transaction types 101 (spot) and 102 (forward contract) to this
product type in the same way as was done for product type 60A.

Field Name Value
Product Type 6##
Text Individual
Product Category 600 Forex
Table 30: Transaction Types

Field Name Value
Product Type 6##
Transaction Type 101(Spot) or 102 (Forward)
Transaction Cat. 100 (Forex Transaction)
Table 31: Number Ranges

Field Name Value
Transactions 04

Field Name Value

Underlying 19
Table 32: Processing

Field Name Value
Processing Cat. 00101 (Include settlement step)
Automatic posting release Yes (Select indicator)
Automatic settlement on counter confirma- No (Do not select indicator)
tion
2. Assign FX attributes to product type 6## and transaction types 101 and 102. Use the
exchange rate type M.
Table 33: FX attributes

Product Type 6##

Transaction Type 101 (Spot) or 102 (Forward)
Exchange Rate Type M
Offsetting Transaction <blank>
Rollover <blank>
Premature Settlement <blank>

Unit 4
Solution 9
Foreign Exchange
Business Example
You receive a requirement from your manager to create a new foreign exchange product type
in SAP.
Note:
1. Create a product type 6## (use your group number) with product category 600 (foreign
exchange). Assign the transaction types 101 (spot) and 102 (forward contract) to this
product type in the same way as was done for product type 60A.

Field Name Value
Product Type 6##
Text Individual
Product Category 600 Forex

Field Name Value
Product Type 6##
Transaction Type 101(Spot) or 102 (Forward)
Transaction Cat. 100 (Forex Transaction)
Table 31: Number Ranges

Field Name Value
Transactions 04

Field Name Value

Underlying 19
Table 32: Processing

Field Name Value
Processing Cat. 00101 (Include settlement step)
Automatic posting release Yes (Select indicator)
Automatic settlement on counter confirma- No (Do not select indicator)
tion

Exchange → Transaction Management → Product Type → Define Product Types.
b) Create product type 6##. To create a new product type, choose the New Entries
button.
c) Enter the values provided in the table, Product Type.
d) Choose Save your entries.
e) In the SAP Customizing Implementation Guide, choose Financial Supply Chain

Exchange → Transaction Management → Transaction Type → Define Transaction
Types.
f) Assign the transaction types 101/spot transaction and 102/forward transaction to

product type 6##. Use the data provided in the tables, Transaction Type, Number
Ranges, and Processing.
g) Choose Save your entries.
2. Assign FX attributes to product type 6## and transaction types 101 and 102. Use the
exchange rate type M.
Table 33: FX attributes

Product Type 6##

Transaction Type 101 (Spot) or 102 (Forward)
Exchange Rate Type M
Rollover <blank>
Premature Settlement <blank>


Exchange → Transaction Management → Transaction Type → Assign Forex Attributes.
b) Start the transaction and use the exchange rate M for your settings. Enter the data
provided in the table FX attributes.
c) Choose Save.

Flow Types for Foreign Exchange
Figure 186: Define Flow Types for Foreign Exchange
The cash flow structure from FX transactions is significantly different than that of money
market financial transactions. At start date, no position cash flow exists. For the background
processing, technical open-and-close cash flows are generated, which are visible in the
position indicator of each transaction. A start foreign exchange transaction has only three
cash flows:
● Physical delivery:
- Sale amount at maturity
- Purchase amount at maturity
● Cash settlement:
- Netting outgoing and incoming cash flows at due date
- Cash settlement is done, by using the Edit Financial Transaction tile once the cash
settlement amount is known at the time of maturity of the financial transaction.
To your flow types, you assign:

● a classification,
● flow category and
● calculation category.
The classification divides the flow types according to business criteria. The flow category
allows the system to interpret your settings, the calculation category determines the
representation in the cash flow. The classification subdivides flows and conditions according
to business definitions on which the related flows and conditions are based:
● Terms - The terms of the transactions, to which the flows and conditions belong.

● Accrual/deferral - Expenses and revenues resulting from the transaction are accrued/
deferred.
● Valuation - Transactions are valued, for example, taking account of price gains and losses
arising from foreign-currency transactions.
Alongside the settings which determine whether the flows are to be updated in Cash
management and FI (i.e they are cash forecast and posting relevant), this step allows you to
consider data for valuation, accruals/deferrals and display in the drilldown reporting tool.
Furthermore, you establish whether payment requests and individual payments should be
possible for certain flows.
Note: If flows are set as Individual payment, they will not net with any other payment what the
Treasury payment program is run.
Flow types that you mark as valuation relevant are considered in the valuation run.
Note: For payment requests, you can initiate payments via an enhanced payment program.
For this, payment details must be maintained correspondingly in the transaction. For
individual payments, you determine whether this flow may be settled together with others or
whether they must be processed individually. Here you must note that for payment requests,
optional conditions are involved whereas for individual payments, required conditions are
involved. This means that if the indicator is set for the payment request, then a payment
request CAN be generated. However, the indicator for the individual payment means that an
individual payment MUST take place.
Note the specification of whether a payment request is created at the time of posting to
create a payment request. This is a required setting to generate a payment request.
To define flow types, follow the customizing menu path Financial Supply Chain Management
→ Treasury and Risk Management → Transaction Manager → Foreign Exchange →
Transaction Management → Flow Types → Define Flow types.
Figure 187: Assign Flow Types for Foreign Exchange
After you have defined flow types, you assign the flow types to the transaction and product
types, which is assignment of relevant cash flows. It is important to define the direction for the
sales and purchase amount.

The direction field defines whether the flow type belongs to the incoming or outgoing side of
the transaction, or if it belongs to both sides of the transaction.
To assign flow types to product and transaction types, follow the customizing menu path
Manager → Foreign Exchange → Transaction Management → Flow Types > Assign Flow types
to Transaction Type.
Note: The definition and assignment of condition types is not necessary for FX transactions.
Maintain Flow Types for FX Transactions
Simulation: Maintain Flow Types for FX Transactions

For more information on Maintain Flow Types for FX Transactions, please view
the simulation in the lesson Defining Trade Types online in the SAP Learning
Hub.

Unit 4
Exercise 10
Business Example
Continuing with building FX spot and forward 6## product types, you now need to add the
flow types to the product and transaction types.
Dependencies
6## 101
6## 102
Note:
1. Assign the flow types for buy currency and sell currency to product type 6## with
transaction type 101 and 102.
Flow Type Long Text Direction
1000 Buy foreign exchange 2
1031 Cash settlement <blank>
2000 Foreign exchange sales 1

Unit 4
Solution 10
Business Example
Continuing with building FX spot and forward 6## product types, you now need to add the
flow types to the product and transaction types.
Dependencies
6## 101
6## 102
Note:
1. Assign the flow types for buy currency and sell currency to product type 6## with
transaction type 101 and 102.
1000 Buy foreign exchange 2
1031 Cash settlement <blank>
2000 Foreign exchange sales 1

Exchange → Transaction Management → Flow Types → Assign Flow Types to
Transaction Type.
b) Choose New Entries. Enter the data provided in the table.
c) Choose Save.

Update Types for Foreign Exchange
Figure 189: Update Types for Foreign Exchange
The three steps covered in this section are shown above.
Figure 190: Update Types for Foreign Exchange
defines the update types. The second step assigns a usage to the update type. Update types
can be defined based on the defined flow types which represent the cash-flow structure of the
transaction. Update types include additional information about direction and sub-module.
The screenshot above shows the assign usages step, which is the second step. The update
type usage is set to Transaction Management for the transactional update types. In most
cases, the SAP delivered update types can be used.
The foreign exchange update types can be defined by following the menu path Financial
Foreign Exchange → Transaction Management → Update Types →Define Update Types and
Assign Usages.

Figure 191: Assign Flow Types to Transaction Types
Update types can be defined based on the defined flow types which represent the cash-flow
structure of the transaction. Update types include additional information about direction and
sub-module.
The foreign exchange update types can be assigned to flow types in customizing by following
the menu path Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → Foreign Exchange → Transaction Management → Update Types →
Assign Flow Types to Update Types.
Figure 192: Assign Update Types for Position Update
In this step, the update types for open and close transactions are assigned to each product
type and transaction type. At the inception of an FX spot or forward contract, no position
posting exists. This makes it necessary to generate open and close cash flows automatically
to be able to calculate valuation results, which is done in this step. These update types are
only used for background procedures and are not relevant for posting. The cash flows
associated with these update types can be reviewed in the position indicator but not in the
SAP standard reports.
The foreign exchange flow types can be customized by following the menu path Financial
Foreign Exchange → Transaction Management → Update Types → Assign Update Types for
Position Update.
Define Open and Close Position Cash Flows
Simulation: Define Open and Close Position Cash Flows

For more information on Define Open and Close Position Cash Flows, please view
the simulation in the lesson Defining Trade Types online in the SAP Learning
Hub.

Unit 4
Exercise 11
Business Example
Continuing with building FX 6## product type, you now need to update the open and close
position cash flows customizing to ensure that the system properly manages the position with
buy and sell transactions.
Dependencies
6## 101
6## 102
Note:
1. Assign the relevant update types for open and close position to product type 6## with
transaction type 101 and 102. Use the existing update types OTC001 and OTC002.
Update Type for Open OTC001

Update Type for Close OTC002

Unit 4
Solution 11
Business Example
Continuing with building FX 6## product type, you now need to update the open and close
position cash flows customizing to ensure that the system properly manages the position with
buy and sell transactions.
Dependencies
6## 101
6## 102
Note:
1. Assign the relevant update types for open and close position to product type 6## with
transaction type 101 and 102. Use the existing update types OTC001 and OTC002.


Exchange → Transaction Management → Update Types → Assign Update Types for
Position Update.
b) Enter product type 6## with transaction type 101 and assign the update types
provided in the table for stock update.
c) Choose Save.
d) Repeat these settings with product type 6## and transaction type 102.
e) Choose Save.

How to Create a Foreign Exchange Spot Transaction
Simulation: How to Create a Foreign Exchange Spot Transaction

For more information on How to Create a Foreign Exchange Spot Transaction,
Learning Hub.
Create a Foreign Exchange Forward Contract
Simulation: Create a Foreign Exchange Forward Contract

For more information on Create a Foreign Exchange Forward Contract, please
view the simulation in the lesson Defining Trade Types online in the SAP Learning
Hub.


Unit 4
Exercise 12
Business Example
You now want to test your customizing of the FX transaction. Create a foreign exchange
forward transaction using the newly created FX product and transaction types.
Dependencies
● The business partner BP## was created.
● The portfolio S4F51-## was created.
● The product type 6## in combination with transaction type 102 were created.
● The flow types were added to the product type 6## and transaction type 102.
● The open and close position update types were configured.
Note:
1. Enter an FX forward financial transaction with product type 6## and transaction type 102.
Purchase 1M USD and sale EUR in 1 months. Use business partner BP1000 or BP##
(business partner standing instruction authorization is necessary). The current market
rate for a USD/EUR contract is 1.30 and the forward rate for a 1-month contract is 1.31.
Use the following information to create the transaction:
Table 34: Transaction Data

Field Name Value
Rate EUR / USD / 1.3 (This is the forward rate
for the trade.)
Buy / Sell Buy
Traded Amount USD / 1M
Spot Rate 1.28
Swap Rate <blank> The system calculates this value.
Value Date ++1 (one month in the future)
Portfolio S4F51-##

Field Name Value

General Valuation Class (on Administr. FX Derivatives: 001 FVTPL; 002 No Valua-
Tab) tion

Unit 4
Solution 12
Business Example
You now want to test your customizing of the FX transaction. Create a foreign exchange
forward transaction using the newly created FX product and transaction types.
Dependencies
● The portfolio S4F51-## was created.
● The product type 6## in combination with transaction type 102 were created.
● The flow types were added to the product type 6## and transaction type 102.
● The open and close position update types were configured.
Note:
1. Enter an FX forward financial transaction with product type 6## and transaction type 102.
Purchase 1M USD and sale EUR in 1 months. Use business partner BP1000 or BP##
(business partner standing instruction authorization is necessary). The current market
rate for a USD/EUR contract is 1.30 and the forward rate for a 1-month contract is 1.31.
Use the following information to create the transaction:

Field Name Value
Rate EUR / USD / 1.3 (This is the forward rate
for the trade.)
Buy / Sell Buy
Traded Amount USD / 1M
Spot Rate 1.28
Swap Rate <blank> The system calculates this value.
Value Date ++1 (one month in the future)
Portfolio S4F51-##

Field Name Value

General Valuation Class (on Administr. FX Derivatives: 001 FVTPL; 002 No Valua-
Tab) tion
b) In the Treasury - Trade Processing group, choose the Create Financial Transaction
(FTR_CREATE) tile (Treasury - Trade Processing).
c) At the Create Financial Transaction screen, enter the values for product type 6## and
transaction type 102 in your company code (TA##). Use the BP## business partner
you created, and choose Create.
d) Enter the data provided in the table, Transaction Data.
e) At the top menu bar, choose Conditions. Check the condition details of your contract
and to return to the main screen, choose Back.
f) Choose the Cash Flow tab. Check the flows automatically created for your contract.
g) Navigate to the Payment Details tab. Check the payment details data.
h) Choose the Status tab.
i) Choose Save.
Note of the transaction number for later settlement activities and posting.

Product and Transaction Types for Derivatives
Figure 196: Overview of Derivatives
Animation: Overview of Derivatives

For more information on Overview of Derivatives, please view the animation in
the lesson Defining Trade Types, online in the SAP Learning Hub.
Based on the details of the item to be hedged, the hedging instruments will be selected. For
example, to eliminate currency risk, interest rate risk, or price risk, different hedging
instruments would be selected.
Derivative financial instruments can roughly be divided into exchange transactions (upper
half) and option-related transactions (lower half) on the currency and interest side. The latter
can also be further subdivided into listed (exchange traded) and OTC (over-the-counter)
options.
The building block concept applies here, as it did to money market and foreign exchange
trade types.
The following additional values can also be included in the options area:
● Knock-out/knock-in Option must or must not increase or fall beyond a certain limit during
the term.
● Barrier options:
Securitized options that either expire (knock out) or arise (knock in) if the base value
reaches a rate specified in advance.
● Digital warrants:
Securitization of the buyer's right to disbursement of a fixed amount specified in advance if
the rate of the base value exceeds (call option) or falls below (put option) the agreed base
value, either at the end of term (European option) or at any point during the option's term
(American option)

● Bottom up/top down:

For each day that the rate for the base value is identified as above (bottom up) or below
(top down) the limit specified in the issue conditions, the investor is credited a fixed
amount.
● Single range:
For each day that the rate of the base value is identified as above the lower limit and below
the upper limit, the investor is credited a fixed amount.
● Dual range:
Like single range, except a corresponding amount is deducted for each day on which the
value is above the upper limit or below the lower limit.
Figure 198: Process Flow of FX Option
This slide shows the process flow for an FX option, which is a type of derivative trade. As is
clear from above, and will be clear after completing this section, the process flow and
customizing for over-the-counter (OTC) trades is very similar to other trade types such as
money market and foreign exchange, with just minor differences.

Figure 199: European FX Option with Physical Delivery
Animation: European FX Option with Physical Delivery

For more information on European FX Option with Physical Delivery, please view
Hub.
The slide above shows the cash flows for a European FX option with physical delivery. Before
you can start the customizing, the process and cash flow structure per product type must be
defined. In this section, you will find examples only for commodity forward, cross-currency
swap, and FX options.
Figure 201: Process Flow of Cross Currency Interest Rate Swap

Animation: Process Flow of Cross Currency Interest Rate Swap

For more information on Process Flow of Cross Currency Interest Rate Swap,
Learning Hub.
The slide above shows the process flow of a cross currency interest rate swap.
The Derivatives are subdivided in the system into the following financial instruments:
● OTC interest rate derivatives
● OTC options, forwards
● Repos, securities lending
● Listed derivatives
● Commodity forwards
● Security forwards
● Forward Loans
● OTC Swap
Entries Characterizing OTC Interest Rate Derivatives

OTC interest rate derivatives are characterized by the following possible entries:
● Cap/floor:
A cap/floor is a series of interest options that you can fit to the period's term of the
transaction that you want to hedge. Both caps and floors are examples of a type of interest
insurance. The purchaser of the cap wants to hedge against rising interest rates. An upper
limit for the interest rate is agreed for which the purchaser pays an insurance premium.
The purchaser of a floor wants a minimum interest rate and agrees a lower limit for the
interest rate to protect against falling interest rates.
- Cap: Agreement between the seller (option writer) and buyer of the cap.

The seller agrees, in the case of a rise in the reference interest rate above the agreed
fixed interest rate (strike), to pay the difference in the interest rates to the holder of the
cap. If the agreed interest rate is not attained, a settlement payment is not made.
- Floor: The purchase only receives a settlement payment if the agreed interest rate
lower limit is not attained.
- Restrictions:
Upper limit
Lower limit
● Swaps:
A swap is an exchange of interest cash flows (without nominal transfer) over a fixed period
of time. The cash flow are defined when the swap is concluded, but the absolve value may
depend on events in the future. Swaps offer comparative cost advantages, which are
achieved by two partners on the basis of their different positions in different financial
market segments, and could not be achieved individually. For a process description, look
at the chapter cap/floor above.
- Payer: Outgoing interest payment fixed, incoming variable
- Receiver: Incoming interest payment fixed, outgoing variable
- Basic: Variable versus variable interest payments
- Fix to Fix: Fixed versus fixed interest payment
The following swap types exist:

- Currency swap
- Interest rate swap
Variable interest rate
Fixed interest rate
Variable/Fixed interest rate
- Cross-currency interest-rate swap
- Discount swap
● FRA:
Forward rate agreements are financial instruments with which purchasers and sellers
agree today on a fixed interest rate even though the start term is in future. Amounts,
currencies, and terms can be determined by the parties to the contract, and the interest
rate reflects the forward interest rate curve. The FRA is based on a fictitious money-
market transaction in which the capital amount is merely used for calculation purposes.
● FX Options:
Using an FX option provides the flexibility to both reduce the risk of loss and, at the same
time, to participate in the market. A premium is paid (when purchased) or collected (when
sold) for this. At maturity, a cash settlement or a physical delivery of the underling (FX spot
transaction) could choose. OTC derivative options can be classified using the following
selection criteria:

- Settlement (physical execution / cash settlement)

- Exercise type (European / American)
- Option category
- Underlying type - product type must be assigned (such as interest rate instrument)
SAP Supported OTC options, Forwards and Derivatives

SAP supports the following OTC options and forward product categories:
● 710 External underlying
● 712 Security as underlying
● 760 OTC options
● 780 Forward
SAP supports the following listed derivatives product categories:

● 700 Futures
● 750 Listed options
The settlement method determines whether margin payments are calculated for listed
options and futures:
● Future style:
Close margin flows are generated for a close transaction. As a result of the variation
margin run, additional variation margin flows are generated.
● Normal style:
Neither variation margin flows nor close margin flows are generated.
The OTC Derivatives product types can be customized by following the menu path Financial
OTC Derivatives → Transaction Management → Product Types → Define Product Types.
Assign Underlyings to Product Types
Figure 204: Assign Underlyings to Product Types
In customizing for the product type of OTC options, you must specify the type of underlying.
This assignment only applies to financial instruments that, either as an option or a forward
transaction, are based on at least two underlying transactions.
Note: An assignment of 1:n is not possible in product type Customizing.
The OTC Derivatives and Commodity product types can be customized by following the menu

Manager → OTC Derivatives → Transaction Management → Product Types → Assign

Underlyings to Product Types.
The settings at the transaction type level are the same as are at the define transaction type
customizing level for other trade types.
Processing step settings at the transaction type level:
● With or without settlement → Processing category (Define transaction types)
● Counter confirmation → Correspondence settings (Define correspondence activities)
● Deal-Release workflow → Define workflow settings
● Release cash flow → Define transaction type
The define transaction type customizing can be found by following the customizing menu
Manager → OTC Derivatives→ Transaction Management → Transaction Types → Define
Transaction Types.

Defining Number Ranges
Figure 206: Defining Number Ranges
For derivatives, three different types of number ranges are defined:

● Define Number Range for OTC Options Underlying
● Define Number Ranges for Transaction (covered previously)
● Define Number Ranges for Underlying Transaction
In this step, you can define number range intervals for the class data of options and futures.
The numbers can either be assigned internally by the system, or you can assign them
externally. You assign options and futures to a number range in customizing activity Define
Product Types.
The following are the customizing menu paths:
● Financial Supply Chain Management → Treasury and Risk Management → Transaction
Manager → OTC Derivatives → Transaction Management → Product Types → Define
Number Range for OTC Options Underlying.
Manager → OTC Derivatives → Transaction Management → Transaction Types → Define
Number Range for Underlying Transaction.
Number Ranges for Transaction.
How to Create a Foreign Exchange Option Transaction
Simulation: How to Create a Foreign Exchange Option Transaction

For more information on How to Create a Foreign Exchange Option Transaction,
Learning Hub.

Define Product and Transaction Types for Derivatives
Simulation: Define Product and Transaction Types for Derivatives

For more information on Define Product and Transaction Types for Derivatives,
Learning Hub.


Unit 4
Exercise 13
Define Product and Transaction Types for
Derivatives
Business Example
New interest rate swap product types need to be set up based on the requirements from your
front-office department.
Note:
1. Document the requirements of a new interest rate derivative product type. You need to
configure a new payer interest rate swap, without nominal transfer.
Write down the cash flow structure and processing flow for each product type. Workflow
settings, a counter confirmation, and a cash flow release for posting are not required
2. After finishing documenting the requirements for a new interest rate derivative product
type, create (in Customizing) a new product type 7## (your group number) with product
category 620 (interest rate swap). Based on the specified process chain, define and
assign the transaction type 300.

Field Name Value
Product Type 7##
Long Text ## IR Swap
Short Text ## IR Swap
Product Category 620 interest rate swap
3. Assign the existing transaction types 300 (Payer) to product type 7##.

Field Name Value
Product Type 7##
Transaction Type 300 (Payer)

Field Name Value

Transaction Cat. 300 (Swap)
Number ranges
Transactions 06
Underlying 19
Processing
Processing Cat. 00002 (with settlement)
Automatic posting release Yes
Automatic settlement on counter confirma- No
tion

Unit 4
Solution 13
Define Product and Transaction Types for
Derivatives
Business Example
New interest rate swap product types need to be set up based on the requirements from your
front-office department.
Note:
1. Document the requirements of a new interest rate derivative product type. You need to
configure a new payer interest rate swap, without nominal transfer.
Write down the cash flow structure and processing flow for each product type. Workflow
settings, a counter confirmation, and a cash flow release for posting are not required
2. After finishing documenting the requirements for a new interest rate derivative product
type, create (in Customizing) a new product type 7## (your group number) with product
category 620 (interest rate swap). Based on the specified process chain, define and
assign the transaction type 300.

Field Name Value
Product Type 7##
Long Text ## IR Swap
Short Text ## IR Swap
Product Category 620 interest rate swap

Management → Treasury and Risk Management → Transaction Manager → OTC
Derivatives → Transaction Management → Product Types → Define Product Types.
b) Choose the OTC Interest Derivative tab.
c) To create a new product type, choose New Entries.

d) Enter the data provided in the table, Product Type.
e) Choose Save.
3. Assign the existing transaction types 300 (Payer) to product type 7##.

Field Name Value
Product Type 7##
Transaction Type 300 (Payer)
Transaction Cat. 300 (Swap)
Number ranges
Transactions 06
Underlying 19
Processing
Processing Cat. 00002 (with settlement)
tion

Derivatives → Transaction Management → Transaction Type → Define Transaction
Type.
b) Assign the existing Transaction types 300 (Payer) to product type 7##. Choose New
Entries.
c) Enter the data provided in the table, Transaction Type 300.
d) Choose Save.

Flow Types for Derivatives
Figure 209: Define Flow Types
The cash flow structures from derivatives are quite different to money market. At the
inception of the contract, no posting is made. At the maturity of the contract, the current
market value is calculated.
Assign flow types to each product type at the transaction-type level that are necessary in
order to completely portray a financial product.
The category refines the classification of flows and conditions. Together with the
classification, the category is used by the system to interpret the concrete business-
management significance of flows and conditions.
The following categories belong to the classification "terms":
● Nominal interest
● Final repayment
The following categories belong to the classification "accrual/deferral":

● Accrual Deferral
The following categories belong to the classification "valuation":

● Realized price gains and losses from foreign-currency transactions
Manager → OTC Derivatives → Transaction Management → Flow Types → Define Flow Types.

Figure 210: Assign Flow Types
In the previous lesson we defined the cash flow structure of a FX option and of a cross
currency Swap (CCS). In this step, all relevant cash flows which represent the basic
transactional product are assigned. Cash flows for valuation, interest accrued and derived
busses transactions are not to be assigned in this customizing activity.
The assign flow types to the product and transaction types customizing can be found by
following the customizing menu Financial Supply Chain Management → Treasury and Risk
Management → Transaction Manager → OTC Derivatives → Transaction Management →
Flow Types → Assign Flow Types to Transaction Type.
Assign Flow Types for Derivative Product Types
Simulation: Assign Flow Types for Derivative Product Types

For more information on Assign Flow Types for Derivative Product Types, please
Hub.

Unit 4
Exercise 14
Assign Flow Types for Derivative Product
Types
Business Example
Continuing with building the interest rate swap product types, you now need to assign the
required flow types to the product and transaction type.
Dependencies
This exercise uses objects that were created in previous exercises.
In the exercise Define Product and Transaction Types for Derivatives, the following product
and transaction type was created:
Product Type Transaction Type Description
7## 300 IR Swap
Note:
1. Assign flow types to the product type 7## (interest rate swap) with transaction type 300
(Payer).
Use the information from the table to complete the task.
Table 37: Flow Types Payer

1105 Nominal amount increase <blank>
(not relevant for posting)
1115 Nominal amount dec. (not <blank>
rel.)
1900 Charges <blank>

Unit 4
Solution 14
Assign Flow Types for Derivative Product
Types
Business Example
Continuing with building the interest rate swap product types, you now need to assign the
Dependencies
This exercise uses objects that were created in previous exercises.
and transaction type was created:
7## 300 IR Swap
Note:
1. Assign flow types to the product type 7## (interest rate swap) with transaction type 300
(Payer).
Use the information from the table to complete the task.
Table 37: Flow Types Payer

1105 Nominal amount increase <blank>
(not relevant for posting)
1115 Nominal amount dec. (not <blank>
rel.)
1900 Charges <blank>

Derivatives → Transaction Management → Flow Types → Assign Flow Types to
Transaction Type.

b) Choose New Entries.
c) Enter the data provided in the table, Flow Types Payer.
d) Choose Save.

Condition Types for Derivatives
Figure 212: Condition Types for Derivatives
The definition of conditions types and assigning of condition types to the product and
transaction types defined here will look very similar to this topic covered for money market
instruments. It is the same process as was described for money market instruments.
Define and assign condition types for all cash flows, which need to be calculated by using a
mathematical formula. Condition types control how flows calculated by the system are
handled, such as interest, repayments, and charges. For example, condition types enable you
to individually control interest rate flows.
classification, the category is used by the system to interpret the concrete business
significance of flows and conditions.
The Define Condition Types customizing can be found by following the customizing menu
Manager → OTC Derivatives → Transaction Management → Condition Types → Define
Condition Types.

Figure 213: Assign Condition Types to Transaction Type
Assign the relevant condition types to product/transaction type. In connection with the
product structure, you can see, that condition types are defined only for swap transactions.
The general rule is, for all cash flows which need a mathematical formula, condition types are
defined. Cash flows from valuation runs are not included here.
The Assign Condition Types to Transaction Type customizing can be found by following the
customizing menu Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → OTC Derivatives → Transaction Management → Condition Types →
Assign Condition Types to Transaction Type.
Note: The same three steps regarding update types that applied to foreign exchange trade
types, also apply to derivative update types. The three steps are:
1. Define and Assign Usage to Update Types
2. Assign Flow Types to Update Types
3. Assign Update Types for Position Update
As these steps were covered for foreign exchange, they will not be covered again for
derivatives.
Assign Condition Types for Derivatives
Simulation: Assign Condition Types for Derivatives

For more information on Assign Condition Types for Derivatives, please view the


Unit 4
Exercise 15
Business Example
Continuing with building the interest rate swap product type, you now need to assign the
required condition types to the product and transaction type.
Dependencies
and transaction types were created.
7## 300 IR Swap
In exercise Assign Flow Types for Derivative Product Types, flow types were assigned to the
product and transaction types provided in the table.
Note:
1. Assign the relevant condition types to product types 7## (interest rate swap), with
transaction type 300 (Payer).

Field Name Value
1125 Closing(not rel. to posting)
1210 Interest rate adjustment

Unit 4
Solution 15
Business Example
Continuing with building the interest rate swap product type, you now need to assign the
required condition types to the product and transaction type.
Dependencies
and transaction types were created.
7## 300 IR Swap
In exercise Assign Flow Types for Derivative Product Types, flow types were assigned to the
product and transaction types provided in the table.
Note:
1. Assign the relevant condition types to product types 7## (interest rate swap), with
transaction type 300 (Payer).

Field Name Value
1125 Closing(not rel. to posting)
1210 Interest rate adjustment

Derivatives → Transaction Management → Condition Types → Assign Condition Types

c) Enter the data provided in the table, Condition Types.
d) Choose Save .
Note:
It is not necessary to assign the update types because we can use the
update types that are already assigned to the flow types.

Define Derivative Open and Close Position Update Types
Simulation: Define Derivative Open and Close Position Update Types

For more information on Define Derivative Open and Close Position Update
Types, please view the simulation in the lesson Defining Trade Types online in the
SAP Learning Hub.

Unit 4
Exercise 16
Define Derivative Open and Close Position
Update Types
Business Example
Continuing with building interest rate swap 7## product type you now need to update the
open and close position cash flows customizing to ensure that the system properly manages
the position with buy and sell transactions.
Dependencies
This exercise uses the following product and transaction types:

7## 300
Note:
1. Assign to product type 7## with transaction type 300 the relevant update types for open
and close position. Use the existing update types OTC001 and OTC002.
Table 40: Product Type 7##

Field Name Value

Unit 4
Solution 16
Define Derivative Open and Close Position
Update Types
Business Example
Continuing with building interest rate swap 7## product type you now need to update the
open and close position cash flows customizing to ensure that the system properly manages
the position with buy and sell transactions.
Dependencies
This exercise uses the following product and transaction types:

7## 300
Note:
Table 40: Product Type 7##

Field Name Value
a) In the Customizing Implementation Guide, choose the path Financial Supply Chain
Derivatives → Transaction Management → Update Types → Assign Update Types for
Position Update.
b) Start the transaction, and select product type 7## with transaction type 300, and then
assign the update types using the data provided in the table, Product Type 7##.
c) Choose Save.

Create Derivative Transactions
Simulation: Create Derivative Transactions

For more information on Create Derivative Transactions, please view the


Unit 4
Exercise 17
Business Example
The creation of the interest rate swap is complete. Test the customizing by creating an
interest rate swap trade.
To create financial transactions, select the Create Financial Transaction tile (Treasury – Trade
Processing).
Dependencies
and transaction types were created:

7## 300
● In the exercise Assign Flow Types for Derivative Product Types, flow types were assigned
to the product and transaction types provided in the table.
● In the exercise Assign Condition Types for Derivatives, condition types were assigned to
the interest rate swap product and transaction type.
● In the exercise Define Derivative Open and Close Position Update Types, open and close
position update types were assigned.
Note:
1. Based on the customizing settings for product type 7## with transaction types 300, you
would like to create a new financial transaction. You would like to sell 1 million EUR now
and be paid back in 2 months. The fixed interest rate is 2.3% and the variable interest rate
is EURM01EUR. The interest is paid monthly. Choose business partner BP1000 or BP##
(authorization is required).
Table 42: 7## Financial Transaction

Field Name or Data Type Values
Company Code TA##

Product Type 7##
Transaction Type 300

Business Partner BP1000
Table 43: 7## Transaction Data

Field Name Values
Start of term Today

End of term ++2
Outgoing Interest
Nominal amount 1M EUR
Variable Rate EURM01EUR
Frequency 1 (monthly)
1st due date ++1
Incoming Interest
1st due date ++1
Fixed Interest Rate 2,3%

Unit 4
Solution 17
Business Example
The creation of the interest rate swap is complete. Test the customizing by creating an
interest rate swap trade.
Processing).
Dependencies
and transaction types were created:

7## 300
● In the exercise Assign Flow Types for Derivative Product Types, flow types were assigned
to the product and transaction types provided in the table.
● In the exercise Assign Condition Types for Derivatives, condition types were assigned to
the interest rate swap product and transaction type.
● In the exercise Define Derivative Open and Close Position Update Types, open and close
position update types were assigned.
Note:
would like to create a new financial transaction. You would like to sell 1 million EUR now
and be paid back in 2 months. The fixed interest rate is 2.3% and the variable interest rate
is EURM01EUR. The interest is paid monthly. Choose business partner BP1000 or BP##
(authorization is required).
Table 42: 7## Financial Transaction

Company Code TA##

Product Type 7##

Table 43: 7## Transaction Data

Field Name Values
Start of term Today

End of term ++2
Outgoing Interest
Nominal amount 1M EUR
Variable Rate EURM01EUR
1st due date ++1
Incoming Interest
1st due date ++1
Fixed Interest Rate 2,3%
a) Launch the SAP Fiori Launchpad.
b) Choose the Create Financial Transaction tile (Treasury - Trade Processing).
c) Enter the data provided in the table, 7## Financial Transaction, and press Enter.
d) Enter the data provided in the table, 7## Transaction Data.
e) Navigate to the Administration tab, and choose the general valuation class (533)
Interest Derivatives: 001 FVTPL; 002 FVTPL.
f) Choose Save.
Note the transaction number for later settlement activities and posting.

Securities and Listed Derivatives Overview
Figure 217: Securities and Listed Derivatives Overview (1)
Securities and listed derivatives are different from the over-the-counter trade types
discussed to this point in that securities and listed derivative contracts are exchange traded
and have characteristics, e.g. interest rate, maturity date, etc., defined in the external market.
For example, the U.S. Treasury bond that has the CUSIP 912810QZ4 has a maturity date of
2/15/2043 and an interest rate of 3.125. Aspects of any trade in this U.S. Treasury bond will
be the same regardless on when the bond is purchased or sole. Whereas other-the-counter
trade types are always unique.
Because securities and listed derivatives have externally defined characteristics, these
characteristics are defined in class data.
SAP supports a variety of listed and non-tradable securities products, which can be managed
as active and passive positions. Passive position management is limited to stocks and bonds.
You can define individual conditions and class controls for each securities product in order to
meet individual requirements.

Animation: Securities and Listed Derivatives Overview (2)

For more information on Securities and Listed Derivatives Overview (2), please
Hub.
To form the basis for securities management in SAP, you have to create master data in the
following areas:
● Securities accounts
● Classes
● Business partner (roles: counter party, depository bank, and issuer)
In securities management, we differentiate between transaction management and position

management. Transaction management is used to map the business transaction itself, the
investment payment minus a charge and/or interest income payment. Position management
is used to transfer the conditions (such as interest, repayment) from the securities class to
the individual position. This differentiation also exists in customizing.
Securities management enables you to manage securities transactions and positions. The
resulting posting activities are automatically transferred to the Financial Accounting
component.
To use the management processes, you must first enter master data. For example, before
you can represent the purchase (or sale) of a security in the system, you first have to enter it
as a class with the relevant structure and condition characteristics.
You can use master data as well as transactions and positions to create reports in the
information system.

Securities management in the Transaction Manager can be used to structure automatic

integration with Cash Management, Financial Accounting and Controlling.
You conclude transactions (purchases and sales) for a particular security (ID number) with a
particular business partner in a company code. All the necessary information about interest
rate flows, repayment modalities, and changes to positions is taken from the class master
data information (ID number). You use existing securities positions in your securities
accounts as a basis for position-managing activities, such as corporate actions or valuations.

Hub.
The transaction and position management processes are split into the following areas:
● In the Front Office area, you create transactions and exercise rights and carry out a limit
check. This is followed by integration with the credit Risk Analyzer.
● In the Middle Office area, you settle and check the transactions you entered. You also
manage processes relating to position management, such as securities account transfers.
● In the Back Office/Accounting area, you perform accounting activities. These include
posting transactions, incoming payments (such as interest earned or dividends), or write-
downs that result from a position valuation. In addition, accounting is responsible for
creating the end-of-month and year-end statements, as well as carrying out interest
accruals/deferrals and valuations.
After the transactions have been successfully processed in the Back Office, a workflow can be
set up (principle of dual or triple control).


Hub.
Before we can start the customizing activities, the process and cash flow structure of fixed-
interest bond must be defined.
The main difference to money market and non listed derivatives are:
● Master Data:
- Business Partner (Role: Counterparty, Issuer, Depository Bank)
- Security Class
- Security Account
● Corporate Actions
● Correspondence:
- Confirmation
- Dealing Slip
● Posting:

- Transaction Position
- Manual or automatic Debit Position
- Manual Posting

Hub.
The slides above shows the cash flows for a fixed-rate bond (product type 04I) where there
are multiple purchases and one sale.
Cash flow structures from security transaction can be split into two parts:
● Cash flow from transaction management:
- Accrued interest
- Nominal amount (Purchase/Sales)
- Charges per transaction
- Derived business transactions (realized gain/loss from Sales)
● Cash flow from position management:
- Interest accrual
- Valuation

- Corporate actions
- Interest/dividends
- Repayment
- Tax
- Charges per position
- Derived Business Transactions (for example, unrealized valuation results)
Securities Basic Settings
Figure 226: Securities Basic Settings
Animation: Securities Basic Settings

For more information on Securities Basic Settings, please view the animation in
The above slide shows example product types that are supported by SAP's Treasury and Risk
Management module in the area of securities.

Define Condition and Group Types
In this step, condition types for the securities area are defined. It is unlikely any changes will
be needed to the SAP delivered condition types.
For each condition type, a three-character key is created and assigned the appropriate flow
type to it. The system then assigns the flow category and the FiMa calculation category from
the flow type to the condition type automatically.
In order to ensure correct cash flow processing, a reference condition type must be entered
for some condition types. For floating rate instruments, for example, the interest rate
adjustment date or the fixing of the maximum or minimum interest rate refers to the variable
interest rate. You must enter the indicator of the corresponding reference condition type in
the RefC (in this case, "Variable interest").
For some condition types you only need to enter the FiMa calculation category.
You use field selection control to define which fields should appear for each condition type
and whether they should be mandatory, optional or just display fields. For example, the field
"Ref.int.rate" is required for the condition type "Variable interest", but can be hidden for the
condition type "Fixed interest".
This customizing node is located in the IMG under Treasury and Risk Management →
Transaction Manager → Securities → Master Data → Product Types → Condition Types →
Define Condition Types.

In this step, condition groups are defined. In the next step, the conditions defined in the last
step are assigned to the condition groups defined in this step. The condition groups are then
assigned to product types. It is the conditions that drive the cash flows associated with a
securities financial transaction.
You use condition groups to initially create sets of condition types that can be used jointly in a
financial instrument. For example, you can create a condition group for fixed-interest bonds
that consists of the two condition types for interest and final repayment. You assign the
condition groups, in turn, to the product types. You can enter conditions in the class master
data for condition types of an assigned condition group only.
In this step, you define the various condition groups, to which you then assign your condition
types in the next customizing step.
Examples:
● You define a condition group (01) and assign all condition types that are related to a floater
to this condition group.
● In a second condition group (02), you group all condition types relevant for partly paid
stocks.
You then assign condition groups to different product types (such as "floating rate
instruments" or "partly paid stock"). Depending on the product type, only certain condition
types can be maintained or displayed by default. You make these settings in the next step.
Define Condition Groups.

Assign Condition Types to Condition Groups
In this customizing step, the conditions types are assigned to condition groups. In the next
step, the condition groups are assigned to the securities product types.
Assign Condition Types to Condition Groups.

In this step, product types are defined, and assigned to a condition group, a product category,
and a number range. All the entries you make here are valid across all company codes.
By assigning product types to condition groups, you ensure that only certain conditions types
can be maintained or displayed as standard conditions for each product type.
Product Category
The product category is an internal key that controls how the product type assigned to it is
processed. The following product categories are available for the securities area:
● 010 Stock
● 020 Investment certificate
● 030 Subscription right
● 040 Bond
● 060 Warrant bond
● 070 Convertible bond
● 111 Index warrant
● 112 Equity warrant
● 113 Currency warrant
● 114 Bond warrant

● 160 Shareholding
Several product types can refer to one product category: The product types "Partially-Paid
Stock" and "Fully-Paid Stock" are, for example, both assigned to product category 010.
Similarly, the product types "Fixed-Interest Security" and "Floater" are both assigned to the
product category 040.
By assigning the product type to a number range, you can control how numbers are assigned
when you create class data. If you opt for external number assignment, the system assigns
numbers sequentially from the predefined interval. If you opt for external number assignment,
the system checks whether the number entered manually is already being used for a class
within this number range.
Field Selection Control Settings for Product Type
By making field selection control settings (Field Selection button), you can control which
fields are relevant for the class data of each product type. You can specify whether each field
should be displayed or suppressed, and whether the entries are mandatory.
You can also make the following settings for each product type:
● Define default values for the yield method and the interest calculation method. These
predefined settings can be overwritten in the application, if necessary.
● Specify which alternative keys can also be used (for example, ID numbers used by Reuters
or Telerate).
● Assign the product type to a limit group.
When you define drawable bonds (product category 041: Bonds with redemption schedule),
you also need to specify a product type for the automatically-generated classes for the drawn
positions.
The field selection control function (Field Selection button) for inputting the condition is also
linked with the condition type.
Transaction Manager → Securities → Master Data → Product Types → Define Product Types.

Assign Repayment Types to Product Types
In order to ensure that the basic investment is repaid mid-term (such as an annuity) or at the
end of the term (such as maturity), you have to specify repayment conditions in the context of
the product type. To do this, you assign repayment types that are defined in the SAP standard
system.
The following repayment types are currently supported for securities:
● 1 = Maturity
● 2 = Installments
● 3 = Annuity
● 4 = Perpetual bond
The product types are defined in customizing by following the menu path Financial Supply
Chain Management → Transaction Manager → Securities→ Master Data → Product Types →
Assign Repayment Types to Product Types.

Company Code-Dependent Settings
In these settings, you define company code specific settings for each product type in the
following areas:
● Generation of incoming payment flows
● Cash management
● Accounting
● Tax generation
● Valuation parameters
All settings that were defined previously were defined globally for all company codes. In the
next step, you specify company-code-specific settings for each product type. The advantage
of this is that you can use local taxes and different planning levels.
The company code dependent settings are defined in customizing by following the menu path
Financial Supply Chain Management → Transaction Manager → Securities → Master Data →
Product Types → Define Company Code-Dependent Settings for the Product Type.

General Classification for Securities
You can define general classification for securities to use in grouping or classifying securities
contracts. The slide above shows the SAP delivered classifications for securities.
Note: The classification information can be included in the Define Account Assignment
Reference Determination configuration, which helps to post to different position accounts.
The general classifications for securities are defined in customizing by following the menu
path Financial Supply Chain Management → Transaction Manager → Securities → Master
Data → Product Types → Define General Classification for Securities.

Security classes can be represented by a free defined security ID, which can be defined as the
CUSIP number, the international ISIN number, or a freely definable ID. As the number can be
numerical or alphanumeric, the associated number interval should be defined as such. For
example, if security class data is uploaded from Reuters, an external number range logic is
used. The number range definition above shows how externally generated number ranges
could be define for an alphanumeric ID.
Note: This number range is used for securities and listed derivatives.
The security class number ranges are defined in customizing by following the menu path
Financial Supply Chain Management → Transaction Manager → Securities → Master Data →
Product Types → Define Number Ranges for Security Classes.
Define a Securities Product Type
Simulation: Define a Securities Product Type

For more information on Define a Securities Product Type, please view the


Unit 4
Exercise 18
Business Example
The traders at your company want to start trading a new type of security. You must define a
new product type for them.
Note:
1. Create a product type 4## with the product category 40 (fixed-interest bond). Assign the
interest calculation method act/360 to this product type.
Table 44: Securities

Field Name Value
Product Type 4##
Text Bond 4##
Short Text Bond 4##
Product Category 040 (fixed-interest securities)
Condition group 040 (fixed interest percentage)
Number Range 10
2. Assign a repayment type 1 Full repayment on maturity to product type 4##.
Table 45: Repayment

Field Name Value
Product type 4##
Repayment type 1 “Full repayment on maturity”
3. Define company code dependent settings for product type 4## in company code TA##.

Table 46: Company Code Settings

Field Name Value
Product Type 4##
Planning Type -
CM period 5
FI posting 4
Posting control 01
Incoming Payment <blank>
Settings for tax generation Yes (select)
4. Your company code TA## was copied from a template company code. The field
selections for security accounts must be checked. An entry is required for the House Bank
field. Make the appropriate customizing changes.

Unit 4
Solution 18
Business Example
The traders at your company want to start trading a new type of security. You must define a
new product type for them.
Note:
1. Create a product type 4## with the product category 40 (fixed-interest bond). Assign the
interest calculation method act/360 to this product type.
Table 44: Securities

Field Name Value
Product Type 4##
Text Bond 4##
Short Text Bond 4##
Product Category 040 (fixed-interest securities)
Condition group 040 (fixed interest percentage)
Number Range 10

Management → Treasury and Risk Management → Transaction
Manager → Securities → Master Data → Product Types → Define Product Types.
c) Enter the data provided in the table, Securities.
d) Choose Save.
2. Assign a repayment type 1 Full repayment on maturity to product type 4##.

Table 45: Repayment

Field Name Value
Product type 4##
Repayment type 1 “Full repayment on maturity”

Manager → Securities → Master Data → Product Types → Assign Repayment Types to
Product Types.
b) To assign repayment types to product type 4##, enter the data provided in the table,
Repayment.
c) Choose Save.
3. Define company code dependent settings for product type 4## in company code TA##.
Table 46: Company Code Settings

Field Name Value
Product Type 4##
Planning Type -
CM period 5
FI posting 4
Posting control 01
Incoming Payment <blank>
Settings for tax generation Yes (select)

Manager → Securities → Master Data → Product Types → Define Company Code-
Dependent Settings for the Product Type.
c) Enter the data provided in the table, Company Code Settings.
d) Choose Save.
4. Your company code TA## was copied from a template company code. The field
selections for security accounts must be checked. An entry is required for the House Bank
field. Make the appropriate customizing changes.
Manager → Securities → Master Data → Securities Account Management → Maintain
Field Selection for Security Account Master Data.

b) The field selection needs to be changed, select the tab for company code TA##, and
choose Field selection control.
c) Select Bank Data, and change the settings for the House Bank field from Optional entry
to Required entry.
d) Choose Save and back out of the configuration node.

Transaction Management
Figure 237: Transaction Management
As with the Money Market, Foreign Exchange, and Derivative trade type definitions, you define
financial transaction types and assign them to product types. Additionally, in this step, you
specify the fundamental organizational aspects of a financial transaction that you can carry
out with the product types. Much of the settings here and in this objective should be familiar
at this point in the course.
In this section, you define your transaction types and assign these to the product types. You
also define the important technical aspects of managing a transaction using the product
types you have defined.
The fields to be populated are the following:
1. Select a product type for which you want to define a transaction type. (Do not enter a long
name since it is copied automatically from the product type).
2. Enter a short key (three-character alphanumeric field) as the name of the transaction
type.
3. Enter the long name for your transaction type.
4. Assign a transaction category to the transaction type. You can use transaction categories
100 (purchase) and 200 (sale) for each product category in the securities area.
5. Assign a number range interval to the transaction type for the transactions and a number
range for the underlying.

6. Assign your transaction type to a processing category. The processing category

determines which activity categories are intended for a transaction type and reflects the
individual steps you must perform for a transaction. You can choose between the
following two processing categories:
7. 00001: Order - Contract
8. 00002: Order - Contract - Settlement
9. A transaction can pass through different activity categories depending on which

processing category you choose.
10. If you set the Automatic posting release indicator, you can post the transaction flows
generated without explicitly releasing them.
11. If you do not set this indicator, you must release a transaction before you can post it.
12. In the Status management section you can specify a Status profile. You define the status
profiles themselves in the IMG for the Transaction Manager by choosing General Settings
→ Transaction Management → Status Management → Define Status Profiles.
13. In the Automatic date determination section you can specify a date rule. This rule is used
to determine the default proposals for the fields Position value date, Calculation date and
Payment date in the screen for entering the transaction. You define the date rules in the
IMG by choosing Securities → Transaction Management → Transaction Types → Define
Date Rules.
Differentiating Transaction Types

We can also differentiate between various transaction types, buying and selling for securities.
You can save a number interval for each transaction and product type. As these are global
settings, you should manage the number range logic identically for each company code.
In the back office area, you can specify how the corresponding product is processed. For
securities, we differentiate between "order contract" and "order-contract settlement". This
means that for processing type 0002, the transaction must always be settled before it is
posted.
Additionally, you can select the Automatic posting approval checkmark to control whether
each individual cash flow must be approved outside the workflow before the posting.
With the automatic determination of payment details settings you control whether, and if
necessary how, the payment details should be determined in security transactions. You can
choose either not to have the payment details determined automatically, to have them drawn
only from the business partner standing instructions, or, additionally, to determine them from
the securities account, providing no payment details have been defined in the standing
instructions.
The following settings are possible:
● 1. From Standing Instructions and 2. Security Account
● Only from Standing Instructions
● No Account Determination
The security class number ranges are defined in customizing by following the menu path
Financial Supply Chain Management → Transaction Manager → Securities → Transaction
Management → Transaction Types → Define Transaction Types.

Define Flow Types
In this step, you define the flow types that are needed in securities transaction management.
You have to define different flow types for active and passive product types.
Each financial transaction is characterized by a certain number of basic flows. In SAP, these
are known as flow types. In the SAP standard system, a variety of flow types has been set up;
you have to adjust these to match your individual requirements.
You use the classification of the flow type, for example, to specify whether it is a fundamental
structure characteristic or an additional manual flow.
The security flow types are defined in customizing by following the menu path Financial
Supply Chain Management → Transaction Manager → Securities→ Transaction Management
→ Flow Types → Define Flow Types.

Assign Flow Types to Transaction Type
Once flow types have been adjusted to the individual requirements (see cash-flow structure),
there is a further work step where you assign them to the product and transaction types. Each
product is characterized by an individual number of flow types.
As with the topics concerning money market/foreign exchange/derivatives/commodities,
you must complete a second step where you assign the flow types to update types,
depending on the direction.
Supply Chain Management → Transaction Manager → Securities → Transaction
Management → Flow Types (Transaction) → Assign Flow Types to Transaction Type.

Define Update Types and Assign Usages
In the area of securities and derivatives traded on exchanges, direction-related update types
are defined in the area of securities account management and transaction management. Like
flow types, update types correspond to cash flows. Update types control the posting of
individual flows.
All update types for the securities account management area start with SAM, which ensures
that there is effective separation between transaction and position management at this point.
The update types displayed here are provided with the SAP standard system.
In the area of securities and derivatives dealt on the stock exchange, direction-related update
types are defined in the area of securities account management and transaction
management. All update types for the securities account management area start with SAM,
which ensures that there is effective separation at this point.
Double-clicking the Assign update type to usages folder takes you to the subsequent display.
The possible usage types are:
● Transaction management
● Securities account management
● Securities account transfer
● Corporate action
● Exercising rights
● Other flows

Update types have an implicit direction. For example, this means that incoming and outgoing
charges must be represented as two different update types.
The new update types consist of the definition itself and a language-dependent text. No
further indicators are defined directly with the update types.
Management → Update Types → Define Update Types and Assign Usages.
Assign Flow Types to Update Types
The link to Accounting is created with this table. When creating a new assignment, make sure
that inflows and outflows are taken into account. In certain cases, you can use different
update types for these.
The contract types are the following:
● Money market
● OTC Derivatives
● Listed Derivatives
● Securities
● Commodities
● Trade Finance
Not all update types for securities account management are assigned to flow types. We only
assign the update types that can be seen as a fundamental structure characteristic but that
are derived from the class information. All other update types are assigned in securities
account management.
Management → Update Types → Assign Flow Types to Update Types.

Basic Settings for Transaction Management
Simulation: Basic Settings for Transaction Management

For more information on Basic Settings for Transaction Management, please
Hub.

Unit 4
Exercise 19
Business Example
Continuing with the configuration of the fixed interest bond security product type, you would
now like to define buy and sell transaction types, assign flow types, and assign a default
general valuation class.
Dependencies
This exercise uses the Product Type 4## created in the exercise Define a Securities Product
Type.
Note:
1. After finishing the definition of product types 4##, you can assign transaction types 100
(investment) and 200 (borrowing) to this product type. Use number range 02 and the
processing category which required no settlement. All cash flows are automatically
released from the system before posting.

Field Name Value
Product Type 4##
Transaction Type 100(purchase)
Transaction Cat 100(purchase)
Number Range
Transactions 02
Underlying <blank>
Back Office
Proc. Category 00001
Automatic Posting Release Yes
Automatic Settlement on Counter confir- No
mation
Note Physical Delivery No

Field Name Value

Account Determination
Date Rule <blank>
Payment Details 1. Standing Instructions and 2. Security Ac-
count
2. Assign the relevant basic cash flows to product type 4## with transaction types 100 and
200. If required, write down the cash-flow structure of each transaction type. Include the
cash flows for tax calculation.
Table 48: Flow Type - Transaction Type

Flow Type - Transaction Type Name
0100/100 Purchase
0301/100 Brokerage capitalized
0302/100 Commission capitalized
0306/100 Interest income tax
0308/100 Reunification tax
0870/100 Accrued interest paid
0200/200 Sale
0870/200 Accrued interest
3. Assign the general valuation class IFRS: Available for Sale HGB: NCA to product type 4##.
Table 49: General Valuation Class

Field Name Value
Company Code TA##
Product Type 4##
Text Bond 4##
General Valuation Class 111 Long term debt/investment: 001 AMC;
002 AMC

Unit 4
Solution 19
Business Example
Continuing with the configuration of the fixed interest bond security product type, you would
now like to define buy and sell transaction types, assign flow types, and assign a default
general valuation class.
Dependencies
This exercise uses the Product Type 4## created in the exercise Define a Securities Product
Type.
Note:
1. After finishing the definition of product types 4##, you can assign transaction types 100
(investment) and 200 (borrowing) to this product type. Use number range 02 and the
processing category which required no settlement. All cash flows are automatically
released from the system before posting.

Field Name Value
Product Type 4##
Transaction Type 100(purchase)
Transaction Cat 100(purchase)
Number Range
Transactions 02
Underlying <blank>
Back Office
Proc. Category 00001
Automatic Posting Release Yes
Automatic Settlement on Counter confir- No
mation
Note Physical Delivery No

Field Name Value

Date Rule <blank>
Payment Details 1. Standing Instructions and 2. Security Ac-
count

Manager → Securities → Transaction Management → Transaction Types → Define
Transaction Types.
c) Enter the data provided in the table, Transaction Types.
d) Choose Save.
e) Repeat these settings with transaction type 200, but use transaction category 200.
f) Choose Save.
2. Assign the relevant basic cash flows to product type 4## with transaction types 100 and
200. If required, write down the cash-flow structure of each transaction type. Include the
cash flows for tax calculation.
Table 48: Flow Type - Transaction Type

Flow Type - Transaction Type Name
0100/100 Purchase
0870/100 Accrued interest paid
0200/200 Sale
0870/200 Accrued interest

Manager → Securities → Transaction Management → Flow Types → Assign Flow Types

c) Enter the data provided in the table, Flow Types - Transaction Type.
d) Choose Save.
3. Assign the general valuation class IFRS: Available for Sale HGB: NCA to product type 4##.
Table 49: General Valuation Class

Field Name Value
Company Code TA##
Product Type 4##
Text Bond 4##
General Valuation Class 111 Long term debt/investment: 001 AMC;
002 AMC

Manager → Securities → Transaction Management → Assign General Valuation Class -
Securities Transactions.
b) Apply the setting provided in table, General Valuation Class. Assign the Company Code
and General Valuation Class first in the Setting per Product Type folder by pressing the
New Entries button, press the Enter key, select the tab to the left of the entry added,
then add to the Setting per Company Code folder, by pressing the New Entries button
again.
c) Choose Save button once complete.
Note:
It is not necessary to assign the update types because we can use the
update types that are already available. They are automatically
determined from the assignment to the flow types.

Position Management
Figure 243: Position Management
In this section, the following settings are required:

● Assign update types to functions
● Assign update types to condition types (active and passive)
● Specify update types for security account management
● Assign update types for security account transfer
Overview of Treasury and Risk Management
Figure 244: Overview of Treasury and Risk Management

Animation: Overview of Treasury and Risk Management

For more information on Overview of Treasury and Risk Management, please
Hub.
With exchange traded instruments, it becomes necessary to discuss position management.

Position management is the tracking and management of positions on SAP. For example, if a
company owns $100,000 in an IBM bond, and buys $300,000 more in IBM today and buys
$100,000 more of that IBM bond tomorrow from the same account, the position of IBM has
likely increased today and tomorrow. Again, assuming the bonds were all bought from fund
from the same account, the external broker will pay interest and principal repayments on the
bond from a position basis and not from a financial transaction basis. In other words, from an
external basis, interest and principal repayments are paid on the $500,000 position.
Define and Assign Differentiations
Figure 246: Position Management
A position represents the smallest unit in a financial subledger. The position is the basis for
system valuations and for generating derived flows. Differentiation terms are used to
determine how the positions are set up. Some differentiation terms are predefined in the
system and others can be selected, depending on the transaction type.
Overview of Differentiation Terms:
● Transactions:
- Valuation area
- Special valuation class

- Accounting code
- Transaction number
● Listed options and futures:
- Valuation area
- Accounting code
- ID number
- Futures account
● Securities:
- Valuation area
- Accounting code
- ID number
● Additional Differentiation Terms:
- Securities account
- Securities account group
- Portfolio
- Lot (single position management)
For example, using this customizing, you enter a differentiation for securities that also
includes the differentiation term Securities Account. This is used together with the following
criteria to determine a securities position:
● Valuation area
● Special valuation class
● Accounting code
● ID number
● Securities account
You can determine whether to apply this differentiation rule for selected valuation areas/
accounting codes, or whether it should apply to all of them.
The Define and Assign Differentiations customizing can be found by following the menu path
Manager → Accounting → Settings for Position Management → Define and Assign
Differentiations.

Assign Update Types
Figure 247: Position Management (1)
Animation: Position Management (1)

For more information on Position Management (1), please view the animation in
The relevant update types for the securities account management area have to be specified in
terms of direction and calculation procedure. This logic is the same as for flow types in
position management.
In this step, you assign the update types that were assigned to securities account
management and transaction management (in the Assign Usages to Update Types) to the
following functions:
● Update types for debit position
● Update types for manual posting
● Assigning update type for debit position generation
● Update types for activation of div./distr.
● Update types for nominal adjustment
Some of the cash flows are defined for the transaction management area. These are the
update types that start with SE, e.g. SE3009. These update types are in connection with
condition cash flows, for example, interest which is generated from the position. To post
interest (and tax) via the debit position together, you define these settings here:

● Manual Posting:
Not all cash flows can be matched to a transaction or are part of the security class (for
example, charge of security account). An additional cash flow which is relevant for the
complete position could be defined here. Only these update types can be posted when
using the Manual Posting tile.
● Debit Position Generation
With these settings, you can create posting for one cash flow. For example, you can post the
interest cash flow into the P/L.
The Assign Update Types to Functions of Security Account Management customizing can be
found by following the menu path Financial Supply Chain Management → Treasury and Risk
Management → Transaction Manager → Securities → Position Management → Securities
Account Management → Update Types → Assign Update Types to Functions of Security
Account Management.
Specify Update Types for Securities Account Management
In this IMG activity, you specify the update types for securities account management.
When you specify the update types for securities account management, you can stipulate the
+/- sign for calculating the effective interest rate. This corresponds to the settings for a flow
type. In the SAP delivered customizing settings for the flow types, the sign is "+" for payment
outflows (such as purchase) and "-" for payment inflows (such as sale or
redemption). However, the update types for securities account management have been
defined differently. The +/- sign for the effective interest calculation depends on the payment
flow generated by the update type. For payment outflows, the sign is "-", and vice versa. You
can also make update type settings that differ from the sample Customizing settings.
However, you must ensure that your assignments are consistent (in other words, update
types with payment flows in the same direction must have the same +/- sign).
Note: With Asset-Backed Securities/Mortgage-Backed Securities, when you want to use the
Retrospective Adjustment of Redemptions function, you have to define update types with the
following settings:
● SAM1180A:
- Calculation type: AA
- Calculation-relevant
- +/- sign: -
- Classification: Period end (redemption schedule/date of notice)
● SAM1180S:
- Calculation type: SS
- Calcuation-relevant
- +/- sign: +
● SAM1180+:
- Calculation type: NOOP

- Direction: Incoming
● SAM1180-:
- Calculation type: NOOP
- Direction: Outgoing
The Assign Update Types to Condition Types customizing can be found by following the menu
Manager → Securities → Position Management → Securities Account Management → Update
Types → Specify Update Types for Securities Position Management.
In this step, you specify separately for active and passive position which update types the
system uses for condition-based flows (such as interest), depending on the underlying
condition type.
You determine, according to asset and liability positions, which update types the system uses
for the condition-based flows (for example, interest), depending on the condition type in
question. With these settings you can determine the cash flow for a position, based on flows
changing the position (for example, purchase or sale) and conditions for a security class.
In this step, you specify update types for active and passive positions separately.
Passive positions are only used by issuing securities and managing short positions.
Update types are assigned to condition types separately for active and passive position
management. This is important because the necessary condition types and update types are
very different. In the passive position management area, the update type logic is inverted, as
passive positions are on the selling/short side.
As the condition types are cash flows that are calculated using a financial mathematical
formula, there are no standardized flow types for this. As a result, these condition types must
be assigned a payment direction and the corresponding update types.

Active and passive position management can be set up separately.

The Assign Update Types to Condition Types customizing can be found by following the menu
Manager → Securities → Position Management → Securities Account Management → Update
Types → Assign Update Types to Condition Types.
In this IMG activity, you assign relevant update types to different functions:
● Update Types for Manual Posting
● Update Types for Debit Position Generation
● Update Types for Capitalization of Div./Prof.Dis.
● Update Types for Nominal Adjustment
The relevant update types for the securities account management area have to be specified in
terms of direction and calculation procedure. The logic is the same as for flow types in
position management.
All update types that are relevant to securities account start with SAM, e.g. SAM5013. If you
add update types using the New Entries button, you should retain the existing naming
conventions. This ensures that there is a strict separation between transaction (SE update
types) and position management (SAM update types).
The calculation type also plays a core role in specifying the update types that are relevant to
securities account management. It is important that the calculation logic is identical at all the
points described here.
When creating a transaction, you specify an effective interest rate. To ensure that all the
relevant cash flows are taken into account, the plus/minus sign and the calculation relevant
checkmark must be selected.
In the previous pages, we assigned the update types for the manual debit position area. For
this flow to be generated, it has to be activated at this point. Select the two checkmarks in the
debit position area.

The Specify Update Types for Securities Account Management customizing can be found by
following the menu path Financial Supply Chain Management → Treasury and Risk
Management → Transaction Manager → Securities → Position Management → Securities
Account Management → Update Types → Assign Update Types to the Functions of Securities
Account Management.
To enable securities account transfers within a company code, you have to define additional
update types and assign them to the Securities Account Transfer usage. The relevant security
account transfer update types start with SAT, e.g. SAT2010. In order to ensure that different
postings are possible for each product type and direction, you can store various different
update types.
After you have defined update types and assigned them to a usage, you have to assign the
individual product types. You need to ensure that the update type has the correct direction of
flow.
The Assign Update Types for Security Account Transfer per Product Type customizing is
found by following the menu path Financial Supply Chain Management → Treasury and Risk
Management → Transaction Manager → Listed Derivatives → Position Management →
Securities Account Transfer → Update Types → Assign Update Types for Security Account
Transfer.

Corporate Actions
In this activity, you define the corporate action types for the corporate action categories that
are predefined in the system. Using the corporate action types, you can specify additional
evaluation groups to classify corporate actions.
We have already examined the basic settings for customizing of transaction and position
management. For certain securities, it may also be necessary to take corporate actions
during the term.
Note: It is only necessary to set up corporate actions, if they are needed for the trade types,
e.g. stock financial transactions.
There is a wide variety of corporate actions available in the standard SAP system. After you
have defined the necessary number intervals, you define the corporate action types and
assign them to the standard corporate action categories. Make sure that you keep to a 1:1
relationship because the posting logic should always be identical for each corporate action.
The following corporate activity types are supported:
● Stock split
● Stock swap
● Capital reduction
● Capital increase
● Issue currency changeover
● Issue new stock
● Subscription rights
● Transaction currency conversion
● Manually generated

The Define Types of Corporate Actions customizing is found by following the menu path
Manager → Securities → Position Management → Corporate Actions→ Define Types of
Corporate Actions.
Animation: Position Management (2)

For more information on Position Management (2), please view the animation in
For a capital increase, existing stockholders have the right (in Germany) to obtain new stocks
in proportion to the number of stocks they currently hold. This enables existing stockholders
to maintain their share of voting rights and compensates for any negative price trend
resulting from the capital increase.
The subscription-right ratio indicates how many subscription rights are attached to an old
stock. One old stock usually has one subscription right (ratio 1:1).
The subscription ratio indicates how many subscription rights you need to obtain one new
stock, for example:
● Capital increase of 50 million EUR to 60 million corresponds to a ratio of 50:10 or 5:1.
● 5 old shares equals 5 subscription rights or 1 new share.
The Define Types of Corporate Actions customizing is found by following the menu path
Manager → Securities → Position Management → Corporate Actions→ Define Types of
Corporate Actions.

Update Types for Corporate Actions
The additional update types for the corporate actions defined previously need to be defined
and assigned to the corresponding usage. Update types are defined for each corporate action
category.
New update types have to be defined for accounting purposes and assigned to the usage
Corporate Action. The standard system is delivered with all update types in this area starting
with CA. The definition could be done in connection with the defined corporate action type.
In addition, the update types that are used when there is a change to a position need to be
defined and assigned.
The Assign Update Types to Corporate Action Categories customizing is found by following
the menu path Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → Listed Derivatives → Position Management → Futures Account
Management → Update Types → Assign Update Types to Corporate Action Categories.
Definition of relevant update types for future account management.

In this IMG activity, you define a value type for the update types. With the value type you
determine the effects that an update type has on the position value. You can select the
following values:
● Outflow position value options/futures
● Inflow position value options/futures
● No position changes
Note: When calculating variation margin, the position value is compared with the current
market value of a position, and a flow may be generated with an amount that corresponds to
this difference.
The Specify Update Types for Futures Account Management customizing is found by
following the menu path Financial Supply Chain Management →Treasury and Risk
Futures Account Management → Update Types → Specify Update Types for Futures Account
Management.
Margin management enables you to clear the profit and loss of any open market positions for
futures or listed options. SAP Treasury support margin management for future transaction.
You can automatically post the variation and close margin.
● Variation Margin:
The variation margin (key date margin) represents the daily gains and losses of open
futures positions and listed options (future style.) The settlement payment is derived by
comparing the values of the open items from the previous day with the values from the
current key date until market close. The profit and loss is paid out or received on a daily

basis. The variation margin ensures against an accumulation of losses over a long period of
time. It also prevents a repayment of high loss to the creditor.
● Closed Margin:
The closing margin represents the profit and loss of closing positions compared to the
previous day. If a closed transaction is used to either partially or completely close an open
position, the system compares the value of the closing position from the previous day with
that of the closed transaction and then determines the settlement payment (closed
margin).
Note: Initial Margin information are assigned as manual cash flows to each transaction.
You determine which update types should be used for variation margins and close margins for
each product type. You can select the following update types:
● Close Margin, Long Position, Incoming Payment
● Close Margin, Long Position, Outgoing Payment
● Close Margin, Short Position, Incoming Payment
● Close Margin, Short Position, Outgoing Payment
● Variation Margin, Long Position, Incoming Payment
● Variation Margin, Long Position, Outgoing Payment
● Variation Margin, Short Position, Incoming Payment
● Variation Margin, Short Position, Outgoing Payment
For example, the following update types are defined for a product type:
● Variation margin, long position, incoming: Update type DE1970+
● Variation margin, long position, outgoing: Update type DE1970-
● Variation margin, short position, incoming: Update type DE1971+
● Variation margin, short position, outgoing: Update type DE1971-
For a variation margin run, a position of the long position is processed. As an example, the
position value is 10,000 and the current market value is 11,000. A variation margin flow is
then generated for an incoming payment amounting to 11,000. The system determines the
value DE1970+ as the update type.
The Assign Update Types for Margin Management per Product Type customizing is found by
following the menu path Financial Supply Chain Management → Treasury and Risk
Futures Account Management → Update Types → Assign Update Types for Margin
Management per Product Type.
How to Navigate Securities Position Management
Simulation: How to Navigate Securities Position Management

For more information on How to Navigate Securities Position Management,
Learning Hub.

Create a Security Trade
Simulation: Create a Security Trade

For more information on Create a Security Trade, please view the simulation in
the lesson Defining Trade Types online in the SAP Learning Hub.


Unit 4
Exercise 20
Business Example
You are ready to start trading the new security configuration. Create security class master
data. Then, create a security trade using the new product type 4##.
Processing).
Dependencies
This exercise uses the security account SecACC_## that was created in the exercise, Create
a Securities Account.
Note:
1. Create a new securities account class DE02734647## for product type 4##.
Table 50: Class

Field Name Value
Without Reference <select>
ID number DE02734647##
Short name Bond##
Long name User defined
Product Type 4##
General Security Classification Government bond
Bond Classification <blank>

Field Name Value
Issuer BP1000
Issue currency EUR
Nominal value 1,000
Issue start 01/01 current year
End of Term 01/01/current year +5 years

Field Name Value

Issue rate 92
Table 52: Condition

Field Name Value
Int. calc. method act/360
Interest rate 2,3
Table 53: 100 - Interest

Field Name Values
Account
Int.calc.method act/360
Interest rate 2,3
Currency EUR
Dates (double click on the interest condi-
tion; Press the Dates tab)
Calendar 01
Calculation Date 31/12 current year; (regular/inclusive)
Currency EUR
Due Date 01/01 current year +1 year; (regular/next
working day)
Press the Back key ('<') to get back to the
Conditions tab
Frequency 12 (annual interest payments)
Table 54: 263 - Final Repayment

Field Name Values
Calculation Date 31/12 current year +4 year; (regular/inclu-
sive)
working day)

Table 55: Exchange

Field Name Values
Exchange
Exchange FFM
2. Create a new financial transaction in company code TA## with business partner BP##
and product type 4##.
Today, you decide to purchase 10M EURO from security class DE02734647##. The
current market price is 99. The position is managed via security account SecACC_##. If
BP## does not have the authorization for trading this product type, add the authorization
standing instructions for this business partner before starting this exercise (see lesson 2).
Table 56: ID Number

Field Name Value
Company Code: TA##
Product Type: 4##
Transaction Type: 100
Business Partner: BP##
ID Number: DE02734647##

Field Name Value
Security Account: SecACC_##
Position Value Date: tomorrow
Calculation Date: today
Payment Date: tomorrow
Nominal Amount: 10m
Price 99

Unit 4
Solution 20
Business Example
You are ready to start trading the new security configuration. Create security class master
data. Then, create a security trade using the new product type 4##.
Processing).
Dependencies
This exercise uses the security account SecACC_## that was created in the exercise, Create
a Securities Account.
Note:
1. Create a new securities account class DE02734647## for product type 4##.
Table 50: Class

Field Name Value
Without Reference <select>
ID number DE02734647##
Short name Bond##
Long name User defined
Product Type 4##
General Security Classification Government bond
Bond Classification <blank>

Field Name Value
Issuer BP1000
Issue currency EUR
Nominal value 1,000
Issue start 01/01 current year
End of Term 01/01/current year +5 years

Field Name Value

Issue rate 92
Table 52: Condition

Field Name Value
Int. calc. method act/360
Interest rate 2,3
Table 53: 100 - Interest

Field Name Values
Account
Int.calc.method act/360
Interest rate 2,3
Currency EUR
Dates (double click on the interest condi-
tion; Press the Dates tab)
Calendar 01
Calculation Date 31/12 current year; (regular/inclusive)
Currency EUR
working day)
Press the Back key ('<') to get back to the
Conditions tab
Frequency 12 (annual interest payments)
Table 54: 263 - Final Repayment

Field Name Values
Calculation Date 31/12 current year +4 year; (regular/inclu-
sive)
working day)

Table 55: Exchange

Field Name Values
Exchange
Exchange FFM
b) From the Treasury - Securities group, choose the Security Class (FWZZ) tile.
c) Choose Create
d) Enter the data provided in the table, Class, in the popup window. Press the Create
button. Enter the Gen. Sec. Classification.
e) Choose the Basic Data tab.
f) Enter the data provided in the table, Basic Data.
g) Choose the Conditions tab.
h) For Condition Type: 100 Interest Effective from: 01.01 current year, enter the data
provided in the table, 100 - Interest.
i) On your keyboard, press Enter.
j) For Condition Type: 263 Final Repayment Effective from: 01.01 current year, enter the
data provided in the table, 263 - Final Repayment.
k) To check the cash flows for this security choose the Cash Flow tab. Choose Back ('<') .
l) Choose the Exchanges tab, and enter the data provided in the table, Exchange.
m) Choose Save.
2. Create a new financial transaction in company code TA## with business partner BP##
and product type 4##.
Today, you decide to purchase 10M EURO from security class DE02734647##. The
current market price is 99. The position is managed via security account SecACC_##. If
BP## does not have the authorization for trading this product type, add the authorization
standing instructions for this business partner before starting this exercise (see lesson 2).
Table 56: ID Number

Field Name Value
Company Code: TA##
Product Type: 4##
Transaction Type: 100
Business Partner: BP##
ID Number: DE02734647##


Field Name Value
Security Account: SecACC_##
Position Value Date: tomorrow
Calculation Date: today
Payment Date: tomorrow
Nominal Amount: 10m
Price 99
b) Choose the Create Financial Transaction (Treasury - Trade Processing) tile.
c) Enter the data provided in the table, ID Number, and press Enter.
d) Enter the data provided in the table, Security Account, and press enter.
e) Choose the Administration tab, check that the General Valuation Class is set.
f) Assign any portfolio from the available list to your transaction.
g) Choose the Cash flow tab, and double-click the line Accrued interest (transaction).
On the Accrued Interest - Display screen, note the calculation of the interest.
h) Choose the Status tab. Review the data displayed.
i) Choose the Save button.
Note down the transaction number.
j) Return to the SAP Fiori Launchpad.

Money Market Funds
Figure 260: Money Market Funds
Animation: Money Market Funds

For more information on Money Market Funds, please view the animation in the
lesson Defining Trade Types, online in the SAP Learning Hub.
The above slide shows example product types that are supported by SAP's Treasury and Risk
Management module in the area of securities. The Investment Certificates product category
is used for fund trade types, such as money market fund.
The requirements of a money market fund could be the following (there are different types of
money market funds):
● The fund price remains constant at USD 1
● Dividends are declared daily
● Dividends are on an annualized percentage value
● The dividends should be accruable and paid at the beginning of the month.
Typical money market funds aim to maintain a net asset value (NAV) of $1 per share. Any
excess earnings that get generated by the way of interest received on the portfolio holdings
are distributed to the investors in the form of dividend payments.

Define Condition Types and Groups

In the Securities module, conditions are customized in three steps. First a new condition
group to be used for money market funds is defined. Then the condition types are defined.
The condition types are then assigned to the condition group. In a following step, the
condition group is assigned at the product type level.
When defining a condition type, a three-character key, text, and the appropriate FiMa
calculation category. The system then assigns the flow category and the FiMa calculation
category from the flow type to the condition type automatically.
In order to ensure correct cash flow processing, for some condition types, a reference
condition type is entered. For variable rate instruments, for example, the interest rate
adjustment date or the fixing of the maximum or minimum interest rate refers to the variable
interest rate. You must enter the indicator of the corresponding reference condition type in
the RefC (in this case, "Variable interest").
The condition types required for money market funds are the following:
● Condition type for accumulated dividends (using the FiMa Calc. category PSUM)
● Condition type for accrued dividends (using the FiMa Calc. category TD)
● Condition type for dividend adjustment (using FiMa Calc. category ZA) referencing the
accrued dividend condition type

There is field selection control to define which fields should appear for each condition type
and whether they should be mandatory, optional or just display fields.
After the condition group and condition types are defined, the conditions are assigned to the
conditions group.
In this customizing activity, the new product type Money Market Funds is defined and the
condition group defined above is assigned to the new product type. With this feature you can
define product types for money market funds (using existing product category for investment
certificates) with accrued and accumulated dividend conditions. By assigning product types
to condition groups, you ensure that only certain conditions types can be maintained or
displayed as standard conditions for each product type.
The product category is an internal key that controls how the product type assigned to it is
processed. The Investment Certificates product category is used for fund trade types, such as
money market fund.
The entire life-cycle starting with the purchase of fund shares in a securities account and
managing the positions including market data management for factor-based dividends is
supported.
All the entries made here are valid for all company codes.
The security product types are defined in customizing by following the menu path Financial
Supply Chain Management -> Transaction Manager -> Securities-> Master Data -> Product
Types -> Define Product Types.

Define Repayment Type

In this menu option you enter the repayment type for the product type. The repayment types
are defined under an internal key. The following are supported for securities at present:
1 = Final repayment
2 = Installments
3 = Annuity
4 = Perpetual bond
The repayment types are assigned in customizing by following the menu path Financial
Supply Chain Management -> Transaction Manager -> Securities-> Master Data -> Product
Types -> Assign Repayment Types Product Types.

Control Settings by Product Type
Figure 267: Control Settings by Product Type
When defining trade types using the Securities module, there are configuration settings that
are made at the general level and other settings that are made at the company code level, as
this slide shows.
There are control settings made by product type at two levels:
1. At the general level
2. At the company code level
This allows the most flexibility in supporting requirements.
Animation: Control Settings by Product Type

For more information on Control Settings by Product Type, please view the
animation in the lesson Defining Trade Types, online in the SAP Learning Hub.

Transaction types drive the direction of the trade, e.g. purchase or sale. There are a number
of settings made at the transaction type level.
With the automatic determination of payment details settings you control whether, and if
necessary how, the payment details should be determined in security transactions. (This is
only relevant to trades created in the Securities sub-module.) You can choose either not to
have the payment details determined automatically, to have them drawn only from the
business partner standing instructions, or, additionally, to determine them from the securities
account, providing no payment details have been defined in the standing instructions.
The following settings are possible:
● From Standing Instructions and 2. Security Account
● Only from Standing Instructions
● No Account Determination
The security transaction types are defined in customizing by following the menu path
Financial Supply Chain Management -> Transaction Manager -> Securities-> Transaction
Management -> Transaction Types -> Define Transaction Types.

Define Fund Type

In this step you can define an additional reporting element for funds. Fund types are defined
to categorize different types of funds being traded. This is a freeform categorization.
For example, the following shows different types of funds that may be created. The fund type
is used in the definition of the class master data for the investment certificate.
1 Real est. Real estate fund
2 Bond Bond fund
3 Equity Equity fund
The customizing activity Enter Factor Values is available under Treasury and Risk
Management -> Transaction Manager -> Securities -> Master Data -> Specific Class Data ->
Settings for Special Types of Securities -> Investment Certificates -> Define Fund Types.

Customizing Settings
Each product is characterized by an individual number of flow types. At this point forward,
once the flow types have been adjusted to the individual requirements, there is a further work
step where you assign them to the product and transaction types.
Supply Chain Management -> Transaction Manager -> Securities-> Transaction Management
-> Flow Types -> Define Flow Types.
-> Flow Types (Transaction) -> Assign Flow Types to Transaction Type.
Next, you must complete the step where you assign the flow types to update types,
depending on the direction. Update types have an implicit direction. For example, this means
that incoming and outgoing charges must be represented as two different update types.
-> Update Types -> Define Update Types and Assign Usages.
To accrue the dividend at month-end, the accrual/deferral customizing is done. The gains and
losses on the purchase and sale of the investment certificates / funds are defined as derived
business transaction flows. Both of these topics will be covered in the following objectives.

Class Master Data
After all customizing is complete for the money market fund product type, the class data is
entered using the Securities Class tile. After the class data has been defined for the money
market fund, the purchase and sale trades are entered.

Process Flow Steps
After the trade is entered, it then fits into the Treasury and Risk Management framework
described throughout in this course, which includes the following steps:
● Use "Post Flows" tile (TBB1) for posting the purchase and sale cash flows
● Run "Accrual/Deferral" tile (TPM44) for daily accrued flows (this includes foreign currency
adjustments)
● Capitalize the period-end accumulated flows, with "Execute Debit Position"(FWZE)
● Fix daily accrued flows with the "Automatic Debit Position" (FWSO) - this changes to fixed -
no postings are needed
● Update position flows in a batch and background way with "Update Planned Records for
Securities"(FWUP) based on the newest "Factor Values"


Trade Finance Overview
Figure 276: Trade Finance Trade Types
The term "trade finance" is generally reserved for bank products that are specifically linked to
underlying trade transactions (exports or imports). As such, a working capital loan not
specifically tied to trade is generally not included in this definition. Trade finance products
typically carry short-term maturities.
One of the most common and standardized forms of bank-intermediated trade finance is a
letter of credit. Letters of credit reduce payment risk by providing a framework under which a
bank makes (or guarantees) the payment to an exporter on behalf of an importer once
delivery of goods is confirmed through the presentation of the appropriate documents.
A bank guarantee is a promise from a bank or other lending institution that if a particular
borrower defaults on a loan, the bank will cover the loss. Note that a bank guarantee is not the
same as a letter of credit.
The letter of credit and bank guarantee are two product categories supported in Trade
Finance. Below are the product and transaction types delivered with the Trade Finance
submodule of Treasury and Risk Management.
● Product category 850 - Letter of Credit
- Letter of Credit in Applicant View
● Product Type: 85A, Transaction Type: 100
- Letter of Credit in Beneficiary View
- Standby Letter of Credit in Applicant View
● Product Type: 85B, Transaction Type: 100
- Standby Letter of Credit in Beneficiary View
● Product Type: 85B, Transaction Type: 200
● Product category 860 - Bank Guarantee
- Bank Guarantee in Applicant View


- Bank Guarantee in Beneficiary View
Figure 277: Trade Finance Trade Types Customizing
Note: The remaining customizing related to trade finance follows the same steps and
framework as the other product types.

LESSON SUMMARY

Unit 4
Lesson 3
Maintaining Derived Flows
LESSON OBJECTIVES
Overview Derived Flows
Figure 278: Understand Derived Flows
Learn about the derived flows from transactions on the next pages.

Derived flows are flows that are calculated from other flows within a trade. This could be, for
example, withholding taxes, fees, or an exchange tax.
Similar to "other flows" in a trade, derived flows also should be assigned with the Other flow/
condition flow category.
To create derivation procedures and rules in customizing, follow the path Treasury and Risk
Management → Transaction Manager → Money Market → Transaction Management → Flow
Types → Derived Flows → Define Derivation Procedures and Rules. These rules determine the
flow type from which the flows are derived and the structure they have.
For the business partner in the counterparty role, you must specify the derivation procedure
to be used in the corresponding company code in using the Maintain Business Partner tile
(transaction code BP). In setting up the derived flow standing instructions, you assign the
relevant derivation procedure to the product type. When a financial transaction is entered
with the business partner in the company code, the derived flows will automatically be
created.

Lesson: Maintaining Derived Flows
The derived flows (such as for taxes) and the underlying calculations are set in the calculation
procedure. You can use the calculation procedure to set specific calculations for country-
specific tax regulations or for the calculation of country/business partner-specific charges.
First, create the derivation procedure, which is nothing more than the name of the derivation
procedure. After the calculation procedures have been defined, you double click on the
Derivation Rules folder (after selecting the tab to the left of the calculation procedure), to
assign the detailed derivation rules (containing the percentage, for example) using the flow
types.
In the example above, the derivation procedure is effective from 01/01/1998 and is triggered
from a positive (Inflow) interest (flow type 1200) cash flow in the trade. The derived flow is an
outgoing (Outflow) cash flow of flow type 5000, and is calculated as 25% of the interest cash
flow.
Save the new entry and go back into the application to set the derived flow standing
instructions at the business partner and company code level. Start the Maintain Business
Partner tile (transaction code BP) and go to the standing instructions (by pressing the
Company Code button after selecting the Counterparty role). On the Derived Flows tab, you
can assign the created derived procedure to a product/transaction type. The selection is
done by company code. Make sure that the account determination for the derived cash flows
is available so there will be no accounting errors when posting the trade to the general ledger.
To define calculation procedures and rules, follow the customizing menu path Financial
Money Market → Flow Types → Derived Flows→ Define Derivation Procedures and Rules.
Figure 281: Derived Flows Standing Instructions
Animation: Derived Flows Standing Instructions

For more information on Derived Flows Standing Instructions, please view the
animation in the lesson Maintaining Derived Flows, online in the SAP Learning
Hub.

Use the Maintain Business Partner tile to assign the derivation procedure to a business
partner when processing in a specific company code. (As with all standing instructions,
assigning the derived flow standing instructions is done by company code.)
Figure 283: Derived Flows in Financial Objects
When derived flows have been customized and the derived flow standing instructions have
been set-up, when the trade is entered, the derived flow cash flows are automatically
generated by the system. As shown on the Cash Flow tab above.
When double clicking on the derive flow, the system will display how the derived flow was
calculated. In our example, you can see the derived cash flow (taxes) is calculated as 25% of
1,250 EUR, which is the interest flow (1200). If you look at the definition of the Derivation
Procedure, you will see that it is 25% of the interest flow. (Look back two slides to see this.)
How to Configure Derived Flows
Simulation: How to Configure Derived Flows

For more information on How to Configure Derived Flows, please view the
simulation in the lesson Maintaining Derived Flows online in the SAP Learning
Hub.
LESSON SUMMARY

Unit 4
Lesson 4
Using the Deal Release Workflow
LESSON OBJECTIVES
Deal Release Workflow
Figure 285: Deal Release Workflow
When considering the deal release workflow, it is important to consider the process flow,
which is shown below. The deal release workflow requires an approval — by someone
authorized to approve and someone other than the person who entered the transaction —
before the financial transaction posts the general ledger.
This is an explicit approval or release before trades move from front office processing to back
office processing.
Note that this workflow configuration step is optional. A company may decide that if this
functionality is required for them or not.
With the approval step, a second processor must approve the financial transaction before it
can be updated in to accounting. Using the deal release workflow, you can further stress the
separation between front office and back office and introduce additional controls in your
Treasury department.

Figure 286: Define Release Procedure
By defining the release procedure, you determine which product and transaction types
require a release.
You then specify the release conditions for each release procedure. Here, you specify at which
level and for which activities the transaction authorization is required.
The workflow is activated at the activity category level and activity. The activity category
indicates the status of the trade, e.g. offer, simulation contract settlement are all activity
categories. The activity is the operation being performed, e.g. creation, change, or reversal.
For example, in the customizing, it is specified if a release is needed for a creation or change,
but not for a reversal, and based on what is the current status of the financial transaction, e.g.
contract or settlement. Only the product and transaction types defined here are subjected to
workflow selection.
The possible transaction activity categories for money market are:
● Offer
● Simulation
● Contract
● Rollover
● Contract settlement
● Rollover settlement
We differentiate between various activities for each transaction type:

● Add or create
● Change
● Reversal
The define release procedure customizing can be found by following the IMG path Financial
General Settings → Transaction Management → Release → Define Release Procedure.

Lesson: Using the Deal Release Workflow
Figure 287: Workflow Template Settings
After the release procedures have been defined, the workflow roles and the users have to be
assigned to the individual workflow roles. With the next step, the standard role 20000034 is
adapted. The second step is to adjust the release workflow 20000139 and 20000138. After
finishing these activities, the event will be activated.
Select the menu item shown here. A pop-up menu appears where you can Define standard
role(s) and Adjust workflow. First, choose Transaction release: adjust workflow.
Open the standard role 20000034 and create a new responsibility rule for TRTMTR_DEAL.
Make a selection in the following areas:
● Company code
● Current appr. level
● Product type
● Release appr. levels
● Transaction type
Save the settings and assign the relevant user to this rule.
Workflow settings are not transported automatically. Use the transport button to capture all
changes into a transport request.
The workflow agents (approvers) are assigned to the workflow. Please note that user
assignments cannot be transported. They must be made in each client.
The workflow template customizing can be found by following the IMG path Financial Supply
Chain Management → Treasury and Risk Management → Transaction Manager → General
Settings → Transaction Management → Release → Adjust/Copy Workflow Template.

Figure 288: Deal Release Workflow Status
The status tab in financial transactions includes information about the process chain,
correspondence activities and deal-release workflow. In the slide above, the deal-release
workflow status is highlighted.
The slide above shows a money market trade on the left that requires a release, and an FX
trade on the right that does not require release.
Implement the Deal Release Workflow
Simulation: Implement the Deal Release Workflow

For more information on Implement the Deal Release Workflow, please view the
simulation in the lesson Using the Deal Release Workflow online in the SAP
Learning Hub.

Unit 4
Exercise 21
Business Example
You would like to implement the 4-eyes principle deal release workflow so that all trades must
be released through workflow by a separate user before the deals post to the SAP general
ledger.
Dependencies
This exercise has the following dependencies executed in previous exercises:
● Product type 5## and transaction type 100 were created.
● Flow types were assigned to product type 5## and transaction type 100.
● Condition types were assigned to product type 5## and transaction type 100.
Note:
1. Set up your product type to require a workflow release.
Table 58: Release Procedure

Product Type 5##

Release Procedure Yes
Table 59: Release Conditions

Activity Category 10 Contract and 11 Rollover

Activities 01 Add or Generate
02 Change
85 Reverse
Release require Yes

Release steps 1- level release

Trans. processing 2 - Ongoing transaction processing possi-

ble, workflow is
2. Test the workflow release by entering a financial transaction using your product type 5##
and transaction type 100 (purchase).
Amount 50 million EUR

Interest rate 2.6%
Start Date Today
End Date ++3 (3 months starting from today)
(Interest) frequency <Leave the default>
Portfolio S4F51-##
3. Check your neighbor’s transaction (group number minus 1) and release it in the deal
release workflow.

Unit 4
Solution 21
Business Example
You would like to implement the 4-eyes principle deal release workflow so that all trades must
be released through workflow by a separate user before the deals post to the SAP general
ledger.
Dependencies
● Product type 5## and transaction type 100 were created.
Note:
1. Set up your product type to require a workflow release.
Table 58: Release Procedure

Product Type 5##

Release Procedure Yes
Table 59: Release Conditions

Activity Category 10 Contract and 11 Rollover

Activities 01 Add or Generate
02 Change
85 Reverse
Release require Yes

Release steps 1- level release

Trans. processing 2 - Ongoing transaction processing possi-

ble, workflow is

Settings → Transaction Management → Release → Define Release Procedure.
b) Select company code TA##, choose New Entries.
c) Enter the data provided in the table, Release Procedure, and press Enter.
d) Choose Save.
e) Assign the release conditions provided in the table, Release Conditions, to each
release procedure.
f) Choose Save.
2. Test the workflow release by entering a financial transaction using your product type 5##
and transaction type 100 (purchase).
Amount 50 million EUR

Interest rate 2.6%
Start Date Today
End Date ++3 (3 months starting from today)
(Interest) frequency <Leave the default>
Portfolio S4F51-##
a) Choose the Create Financial Transaction tile (Treasury - Trade Processing).
b) Create a fixed-term deposit with product type 5## and transaction type 100 in your
company code (TA##). Use the BP## business partner you created. Enter the
transaction data provided in the table.
c) Save the financial transaction.
Note of the transaction number for later settlement activities and postings.
3. Check your neighbor’s transaction (group number minus 1) and release it in the deal
release workflow.
a) Proceed to the group Treasury - Master Data and choose the Approve Workflow
(SBWP) tile.
If the workflow is activated and the user assigned, a transaction displays in the
Business Workplace inbox.

Lesson: Using the Deal Release Workflow
b) Double-click your neighbor’s transaction to select it. Validate the details of the
financial transaction, and then choose the back arrow.
You then have the option of releasing the transaction or rejecting the release.

LESSON SUMMARY

Unit 4
Lesson 5
Defining Position Management
LESSON OBJECTIVES
Position Management Procedure
Figure 290: Position Management Procedure
Learn on the next pages how you would accomplish to set up different position management
procedures.

Figure 291: Definition of Key Terms
Animation: Definition of Key Terms

For more information on Definition of Key Terms, please view the animation in
the lesson Defining Position Management, online in the SAP Learning Hub.
A valuation area on SAP is an accounting principle that needs to be maintained on SAP.

Examples of valuation areas are IFRS, US GAAP, and local GAAP. When multiple valuation
areas are defined, they are independent, parallel views of the values of the financial
instruments.
The position management procedure field is the most important attribute of the ledger
position. It controls how the ledger position is handled in internal position management and
indicates how a position is valued. It is also used to calculate price gains or losses for outflows
and specifies the components that the system manages for a position.
All trades have a position indicator, which holds the attributes of the position for the trade,
which includes the position management procedure, valuation area, and account assignment
reference.
Derived business transactions change the values of a ledger position because of a business
transaction, e.g. a transfer, an amortization, etc. Derived business transactions are
dependent on a valuation area.

Lesson: Defining Position Management
The primary task of internal position management is to value financial instruments for
accounting purposes. We also balance values on the positions of internal position
management, the ledger positions. Accounting rules that are often country-specific control
how these values must be calculated. The accounting principle sometimes requires the ledger
positions to differ from each other according to criteria other than external positions, which is
accomplished by using different valuation areas.
It is the position management procedure that holds and drives the specific accounting
principles (IFRS, U.S. GAAP, local accounting requirements).
The position management procedure determines how positions are managed and valued both
in the operative valuation area and in the parallel valuation areas. You first have to define the
key date valuation procedures required by the relevant accounting regulations.
The first step is to define the position management procedure needed or determine the SAP
delivered position management procedure that will be used.
Within the definition of the position management procedure, the basic rules for managing the
positions, that is, how the positions are valued, and how the derived business transactions are
generated for position outflows and balance sheet transfers.
You then set the sequence of the key date valuation procedures within the position
management procedures. In this way, you can combine the relevant procedures for
amortizations, one-step price valuations, security price valuations, and foreign currency
valuations according to the respective accounting rules.
In a later configuration step, rules for assigning the position management procedures to
trades are configured. For example, the position management procedures are assigned to
trades based on the valuation area, valuation class, or product type.
Double-clicking on an entry displays the details of the position management procedure.
To get to this customizing step, follow the IMG path Financial Supply Chain Management →
Transaction Manager → General Settings → Accounting → Settings for Position Management
→ Define Position Management Procedure.

After double clicking on the position management procedure, a screen with the details of the
position management procedure is displayed.
The steps for valuation are defined in the position management procedure, which is assigned
to the position in the subledger position indicator. In other words, in the position management
procedure definition, you also define how an assigned ledger position is to be valued. The
valuation is determined by up to the five valuation steps specified here.
In addition to a description, you assign such values to a category that controls the important
properties (Position Management Category field). The position management category mainly
determines which key figures you can query for the position. Most components make sense
only for certain financial instruments, so the position management categories are
characterized according to financial instruments.
The following categories are available:
● Securities/Loans/Money Market (without index-linked bonds):
This position management category is suitable for financial instruments of the areas
mentioned and for normally managed listed options. However, do not use this category for
financial instruments that contain installment repayments.
● Securities/Loans with Installment Repayments:
This category is available for loans from the SAP Loans Management module (FS-CML)
and for bonds of the Installment with Repayment product category. It provides the
Repayments component specifically for financial instruments with installment
repayments. The requirements for an amortization in accordance with US GAAP and IFRS
can be met using only this position management category. It can also be used for financial
instruments that have just a final repayment.
● Index-linked bonds:
This position management category is specifically intended for index linked bonds.
● Futures:

This position management category is suitable for futures and listed options that are
managed like futures.
● Foreign exchange transactions:
This position management category is intended only for foreign exchange transactions.
● Forwards/Repos:
This position management category is suitable for forward contracts and repo
transactions.
● OTC derivatives (profit/loss posting):
This position management category is suitable for all OTC derivatives. The Profit/Loss
Posting addition indicates that the book value of the option is posted into the P&L when an
option is physically exercised.
● OTC options (transfer posting to underlying):
This position management category corresponds to the preceding category. When you
physically exercise an OTC option, the book value is transferred to the underlying and not
cleared into the P&L.
The Steps 1 to 5 specify the order the valuation steps are processed.
You can also see that only a two-step valuation is set up for "IFRS Trading/FX (securities),"
consisting of a securities valuation and a foreign currency valuation. The sequence is very
important because amortization always has to be carried out first and a foreign currency
valuation always has to be carried out last.
The indicator "Perform for Key Date Valuation" specifies whether the step is carried out in a
key date valuation.
Transaction Manager → General Settings → Accounting → Settings for Position Management
→ Define Position Management Procedure.
Figure 295: Assign Position Management Procedures
After the position management procedures have been defined, they are assigned to the trade
fields the position management procedure should apply to.
Below is the list of fields that can be used to assign the position management procedures to
trades, which enables you to take different statutory requirements into account for valuation.
● Accounting code (company code)
● Valuation area

● Valuation class
● Product category
● Product type
● Portfolio
● Security account group
For all newly created positions, the position management procedure is initially derived from
the settings here. The position management procedure can be changed within the position
indicator within the trade or can be manually changed or assigned using the Maintain Position
Management Procedures application.
To ensure that a position management procedure is found in all cases, you can define a
default procedure (where all influencing factors have their initial value). If, for example, you do
not specify the accounting code area, these settings apply for all areas.
It is important to save a position management procedure for all products to ensure valuation
and position management takes place without errors.
By not filling in a field, the setting applies to all values for that field.
Transaction Manager→ General Settings→ Accounting→ Settings for Position Management
→ Assign Position Management Procedure.
Assign Update Types for Position Update
Figure 296: Key Date Valuation Update Types
Update types describe trade flows, and they carry information about the trade flows to
accounting for Transaction Manager. How a flow posts to the SAP general ledger is driven by
the account determination done for the update type.
Depending on the valuation steps that are assigned to the position management procedure,
the different update types for carrying out the key date valuation need to be defined.
In this step, the update types for valuations are created. Note that the SAP system will come
delivered with the update types needed for most processing.
When defining update types, first the update type is define with a long description, then the
usage of the update type is assigned to the update type. The usage for the update types for
valuations is Key Date Valuation. Always when defining update types, these two steps are
followed. First define the update type, then assign how the update type will be used.

Treasury and Risk Management → Transaction Manager → General Settings → Accounting →
Key Date Valuation → Update Types → Define Update Types and Assign Usages.
Figure 297: Update Types for Valuation - Amortization
Depending on which valuation steps are assigned in the position management procedure, the
corresponding update types for carrying out the key date valuation are assigned. Notice that
this step is done by position management procedure.
The relevant update types start with V or, for the reset, with RV. Before the update types can
be assigned, they need to be defined following the same logic as described in the previous
chapter.
In our example, position management procedure, the following valuation steps were included:
● Foreign Exchange Valuation
● Amortization
Therefore, the update types relevant to each of the above steps need to be assigned here.
Transaction Manager→ General Settings→ Accounting → Key Date Valuation → Update
Types → Assign Update Types for Valuation.
Figure 298: Update Types for Valuation - Foreign Exchange

In addition to the amortization update type settings, the foreign exchange valuation update
type settings also need to be made.
In the example, position management procedure, the following valuation steps were included:
● Amortization
Again, the assignments are done by position management procedure.

Notice that the reset update types are also specified. These would be used if the Valuation
Category is specified "with Reset" when the valuation is executed (Run Valuation tile is
executed).
Transaction Manager→ General Settings→ Accounting→ Key Date Valuation → Update
Effects of the update type on the position components
Figure 299: Set the Effects of the Update Types on the Position Components
Update types of flows that originate from external positions or transaction management must
be assigned to a position change category.
This assignment is only relevant for those update types that are not generated in the financial
subledger but are required there. If no assignment is made for an update type here, the
update type is not taken into account when determining the position component.
You normally enter the Incoming Payment-Position Outflow (1002) position change category
or the Outgoing Payment-Position Outflow (1020) position change category for outflows,
such as sales or final repayments. This implies that the system determines rate gains caused
by this outflow. You can avoid this for installment repayments if you instead use the Post
Repayment (1023) position change category for asset positions or the Clear Repayment
(1024) position change category for liability positions.
If you want to ensure that a flow does not appear in internal position management, you can
enter Excluded from Position Management (9999) position change category.
The assignment can be made by valuation area and accounting code, or by leaving these
fields blank, they apply to all valuation areas and accounting codes.

To assign a position management procedure, use the customizing path: Financial Supply
Settings → Accounting → Settings for Position Management → Set Effects of Update Types
on Position Components.
Position Indicator
Figure 300: Position Indicator
Animation: Position Indicator

For more information on Position Indicator, please view the animation in the
lesson Defining Position Management, online in the SAP Learning Hub.
The position indicator is an aspect of all financial transactions. The position indicator drives
key aspects of accounting for positions. Within the position indicator are the settings for the
parallel accounting, position management procedure, and the account assignment reference.
All over-the-counter trades have their own unique position indicator because each over-the-
counter trade is a unique position.
For instruments that are exchange trades, multiple trades may share a position indicator. For
example, if you own IBM stock in your account 123, and you buy more IBM stock in account
123, you are adding to an existing position and not creating a new position. In other words,
with the first purchase of IBM stock a new position indicator is created, but with the second
purchase of IBM stock, the existing position indicator is used for the second trade.
The attributes included in the position indicator serve to identify the position (company code,
ID number) or manage the position (position management procedure, account assignment
reference).
Figure 302: Position Indicator Generation

The generation of the position indicator can be created automatically via customizing settings
described here or manually.
You define per transaction, product group, accounting code and valuation area how the sub-
ledger position indicator should be created. Below are the settings to choose from:
● Generate position indicator automatically - If you select this setting, the sub-ledger
position indicator is always created automatically according to your settings in
Customizing.
● Generate position indicator manually - If you select this setting, you must always create
the sub-ledger position indicator manually.
● POPUP (manual/automatic) - If you select this setting, a dialog box appears whenever it is
necessary to create a new sub-ledger position indicator.
● A dialog box asks you whether you want to generate the position indicator manually
(branches to manual generation) or automatically.
If the position indicator is generated automatically, it is created, if necessary, as the

transaction is saved.
To define the generation of position indicator, use the customizing path: Financial Supply
Chain Management → Treasury and Risk Management → Transaction Manager → Foreign
Exchange → Position Indicator → Define Generation of the Subledger Position Indicator.
Note: If you do not make any settings here, the subledger position indicator is always created
automatically.
Figure 303: Position Indicator Generation
From financial transactions, the position indicator can be found by following the menu path
Environment → Position Indicator, as shown above.

Create a Position Management Procedure
Simulation: Create a Position Management Procedure

For more information on Create a Position Management Procedure, please view
the simulation in the lesson Defining Position Management online in the SAP
Learning Hub.


Unit 4
Exercise 22
Business Example
You must carry out the accounting customizing settings that are necessary for your new
fixed-term deposit product type. Create a new position management procedure and the key
date valuation configuration for your new product type.
Dependencies
This exercise has the following dependencies:
● The following product type 5## and transaction type 100 were created.
● The flow types were assigned to product type 5## and transaction type 100.
● The condition types were assigned to product type 5## and transaction type 100.
● The general valuation class was assigned to product type 5## and transaction type 100.
Note:
1. Create a new key-date valuation procedure 10## for single-level rate/price valuation and
define the following entries for it:
Procedure 10##
Text individual
Rate/Price type 01 Spot
NPV type 001 Standard & hedge accounting
Rate type M
Write-Up Rule Write-up to market value/present value
Write-Down Rule Write-down to market value/present value
2. Create a new position management procedure 40## for IFRS. Assign the defined 10##
valuation rule for one-step rate/price valuation.

Position management procedure 40##

Name individual
Position Management category Security/loan/money market/list option
normal style (without index-linked bonds)
Transfer category Only post to used Components
Step 1
Type of Step 001
Procedure 10##
Carry Out for Key Date Valuation Yes
3. Assign the position management procedure to your accounting code (company code)
TA##, to your valuation areas 001 with valuation class Loans & Receivable, and to your
product type 5##. Assign the position management procedure 3ILG to valuation area 002
with valuation class (211) Short term debt/investment.
Field Name Values (IFRS) Values (HGB)
Accounting Code TA## TA##

Valuation Area 001 IFRS 002 HGB
Valuation Class 0021 (Short term debt / in- 0021 (Short term debt / in-
vestment: Amortized cost) vestment: Amortized cost)
Product Category 510 510
Product Type 5## 5##
Position Management Pro- 40## 3ILG - HGB: Debt and in-
cedure vestment; Amortized Cost
(LAC Gross)
4. Assign the update types for key-date valuation to position management procedure 40##.
One Step Overall write down “Valuation”
Adjust Write Down, Security V100

Security Write Down V101
Adjust Write Down, Forex V102
Forex Write Down V103
One Step Overall write down “Reset”
Adjust Write Down, Security VR100
Security Write Down VR101
Adjust Write Down, Forex VR102


Forex Write Down VR103
One Step Overall write up “Valuation”

Security Write up V150
Adjust Write up, Security V151
Forex Write up V152
Adjust Write up, Forex V153
One Step Overall write up “Reset”
Security Write up VR150
Adjust Write up, Security VR151
Forex Write up VR152
Adjust Write up, Forex VR153
5. Assign the update types for derived business transactions to position management
procedure 40##. Use position management procedure 1FFP as a template.

Unit 4
Solution 22
Business Example
You must carry out the accounting customizing settings that are necessary for your new
fixed-term deposit product type. Create a new position management procedure and the key
date valuation configuration for your new product type.
Dependencies
● The following product type 5## and transaction type 100 were created.
● The flow types were assigned to product type 5## and transaction type 100.
● The condition types were assigned to product type 5## and transaction type 100.
● The general valuation class was assigned to product type 5## and transaction type 100.
Note:
1. Create a new key-date valuation procedure 10## for single-level rate/price valuation and
define the following entries for it:
Procedure 10##
Text individual
Rate/Price type 01 Spot
NPV type 001 Standard & hedge accounting
Rate type M
Write-Up Rule Write-up to market value/present value
Write-Down Rule Write-down to market value/present value
a) Navigate to the SAP Customizing Implementation Guide, choose Financial Supply

Chain Management → Treasury and Risk Management → Transaction

Manager → General Settings → Accounting → Settings for Position

Management → Key Date Valuation → Define One-Step Price Valuation Procedure.
c) Enter the data provided in the table.
d) Choose Save.
2. Create a new position management procedure 40## for IFRS. Assign the defined 10##
valuation rule for one-step rate/price valuation.
Position management procedure 40##

Name individual
Position Management category Security/loan/money market/list option
normal style (without index-linked bonds)
Transfer category Only post to used Components
Step 1
Type of Step 001
Procedure 10##
Carry Out for Key Date Valuation Yes

Management → Define Position Management Procedure.
b) Select the appropriate customizing transaction, and choose New Entries.
c) At the system prompt, enter the data provided in the table.
d) Choose Save.
3. Assign the position management procedure to your accounting code (company code)
TA##, to your valuation areas 001 with valuation class Loans & Receivable, and to your
product type 5##. Assign the position management procedure 3ILG to valuation area 002
with valuation class (211) Short term debt/investment.
Accounting Code TA## TA##

Valuation Area 001 IFRS 002 HGB
Valuation Class 0021 (Short term debt / in- 0021 (Short term debt / in-
vestment: Amortized cost) vestment: Amortized cost)
Product Category 510 510
Product Type 5## 5##

Position Management Pro- 40## 3ILG - HGB: Debt and in-

cedure vestment; Amortized Cost
(LAC Gross)

Management → Assign Position Management Procedure.
b) Assign the position management procedure to your accounting code (company code)
TA##, to your valuation areas 001 and 002, and to your product type 5##. Use the
data provided in the table.
c) Choose Save.
4. Assign the update types for key-date valuation to position management procedure 40##.
Adjust Write Down, Security V100

Security Write Down V101
Adjust Write Down, Forex V102
Forex Write Down V103
One Step Overall write down “Reset”
Adjust Write Down, Security VR100
Security Write Down VR101
Adjust Write Down, Forex VR102
Forex Write Down VR103
One Step Overall write up “Valuation”
Security Write up V150
Adjust Write up, Security V151
Forex Write up V152
Adjust Write up, Forex V153
One Step Overall write up “Reset”
Security Write up VR150
Adjust Write up, Security VR151
Forex Write up VR152
Adjust Write up, Forex VR153


Manager → General Settings → Accounting → Key Date Valuation → Update
b) Choose New Entries, and select position management procedure 40##.
c) Assign the update types provided in the table.
d) Choose Save.
5. Assign the update types for derived business transactions to position management
procedure 40##. Use position management procedure 1FFP as a template.
Manager → General Settings → Accounting → Derived Business
Transactions → Update Types → Assign Update Types for Derived Business
Transactions.
b) Select position management procedure 1FFP.
c) Choose Copy as and enter position management procedure 40##, and copy all the
dependent entries.
d) Choose Save.

LESSON SUMMARY

Unit 4
Lesson 6
Valuing Trades
LESSON OBJECTIVES
Key date valuation
Figure 305: Treasury Process Flow - Key Date Valuations
Animation: Treasury Process Flow - Key Date Valuations

For more information on Treasury Process Flow - Key Date Valuations, please
view the animation in the lesson Valuing Trades, online in the SAP Learning Hub.
Before proceeding, consider the treasury process flow shown here. At period-end, key date
valuations and accruals are booked to the SAP general ledger. Both of these processes are
typically performed by an Accounting department.

Figure 307: Period-End Process Steps
Animation: Period-End Process Steps

For more information on Period-End Process Steps, please view the animation in
the lesson Valuing Trades, online in the SAP Learning Hub.
The slide above shows the typical period-end process steps, which are:
1. Upload period-end market data into SAP. This includes updated exchange rates, interest
rates, security prices, etc. The exact market data that should be loaded is based on the
outstanding trade types a company has.
2. Execute accruals. These are typically interest accruals but could be accruals of fees, etc.
This topic will be covered in the Understanding Interest Accruals section.
3. Calculate the Net Present Value (NPV) of the outstanding trades.
4. Execute the valuation run, which posts the current market values to the SAP general
ledger.

Lesson: Valuing Trades
Figure 310: Key Date Valuation
The key date valuation is performed on the basis of the position management procedure
determined for the relevant position. With the parallel valuation areas, you have three options
for key date valuation.
● Year-end valuation (always without reset)
The key-date valuation without reset is normally used for year-end valuation as part of
year-end closing. A key-date valuation without reset permanently changes the book value

of the position. For example, the book value after the key-date valuation is the starting
point for all subsequent calculations of rate gains as well as for future valuations.
● Mid-year valuation without reset
● Mid-year valuation with reset
You can use this key-date valuation with reset for monthly or quarterly accounts. The results
of the valuation are reset on the next day. The key-date valuation with reset does not
therefore change the position permanently, but only for the period between the valuation key
date and the reset key date.
In the case of a "valuation with reset," the reset automatically occurs and is posted in the
same run as the valuation. The reset key date is one day after the valuation key date.
It is important to clarify the difference between the two procedures "with" and "without" reset.
"With reset" means that the valuation result is completely reset on the first day of the
following month. "Without reset" means that the difference between the previous months
valuation is posted from month to month.
Valuation Methods
Figure 311: Key Date Valuation (1)
Animation: Key Date Valuation (1)

For more information on Key Date Valuation (1), please view the animation in the
lesson Valuing Trades, online in the SAP Learning Hub.
SAP supports two methods of accruals and deferrals. They are the reset or the difference
(incremental) method.

With difference procedure (also known as incremental postings), the incremental interest
Figure 313: Key Date Valuation (2)
Animation: Key Date Valuation (2)

For more information on Key Date Valuation (2), please view the animation in the
lesson Valuing Trades, online in the SAP Learning Hub.
With a key-date valuation, all the relevant valuation steps defined in the position management
procedure - such as amortization, security and forex valuation - are performed.

Period-End Process Steps
Figure 315: Key Date Valuation Customizing Steps
The slide above shows the typical period-end process steps, which are:
1. Upload period-end market data into SAP. This includes updated exchange rates, interest
rates, security prices, etc. The exact market data that should be loaded is based on the
outstanding trade types a company has.
2. Execute accruals. These are typically interest accruals but could be accruals of fees, etc.
This topic will be covered in the Understanding Interest Accruals section.
3. Calculate the Net Present Value (NPV) of the outstanding trades.
4. Execute the valuation run, which posts the current market values to the SAP general
ledger.

One-Step Valuation
The one-step valuation procedure specifies which rate basis is used for valuation.
The SAP system differentiates between various net present value types:
● Current valuation
● End-of-day valuation
● Current valuation: ask rate
● End-of-day valuation: middle rate
● End-of-day valuation: bid rate
● End-of-day valuation: ask rate
● Hedge accounting
● Write-down
The write-down rule defines how a negative difference between the market and book value is
handled in a valuation step in the context of a key date valuation:
● No write-down:
No flow is generated.
● Write-down to market value:
A write-down is generated amounting to the difference between the book and market
values.

● Write-down to purchase value:

The market value is less than the purchase value plus previous amortizations; a write-
down is generated only to the amount of the difference between these two amounts.
● Write-up rule:
The write-up rule defines how a positive difference between the market and book value is
handled in a valuation step in the context of a key date valuation:
● No write-up:
No flow is generated.
● Write-up to market value:
A write-up is generated amounting to the difference between the market and book values.
● Write-up to purchase value:
If the market value is greater than the purchase value plus previous amortizations, a write-
up is generated only to the amount of the difference between these two amounts.
The one step valuation include interest and FX component only one cash flow is generated.
To enter the configuration settings, follow the customizing menu path Financial Supply Chain
→ Accounting → Settings for Position Management → Key Date Valuation → Define One-Step
Price Valuation Procedure.
Amortization, Security and Forex Valuation
With a key-date valuation, all the relevant valuation steps defined in the position management
procedure — such as amortization, security and forex valuation — are performed.
We distinguish between the following amortization methods:

● LAC (Linear Amortized Cost): The premium or discount (difference between the payment
premium and the repayment amount) is linearly distributed across the term.
● SAC (Scientific Amortized Cost): This method is also known as the "effective interest
method." Essentially, the amortized acquisition value of a position is identified as follows:
The effective interest for a cash flow used to discount the interest on future payments on
the amortization key date. The following variants of this method are supported:
- Interest not included: Here, interest payments are not included when determining the
effective interest and when discounting future payments. This results in an exponential
distribution of the premium or discount over the term.
- Interest included, accrued interest correction (for securities only): Here, the interest
payments are included in the calculation of the effective interest and they are taken into
account when discounting future payments. To avoid leaps in the amortized acquisition
value on interest dates, a linear accrued interest correction is carried out for the
amortized acquisition value. If this variant is selected, interest accrual/deferral is
carried out in addition to the amortization.
- Effective interest method as per IAS 39: Here, interest payments is taken for the
calculation of the effective interest rate, which is the basis for the amortization.
Therefore, no additional interest accrual/deferral is necessary. The effective interest is
identified here using Newton's iteration.
An amortization can be carried out at the following times:

● On key date valuations:
These amortizations are triggered by the user.
● For each business transaction that changes a position:
These amortizations are generated by the system. For example, with a partial divestiture
(partial sale), the entire position is first amortized before the partial divestiture, and then
the position value (including the amortization that was previously generated) is posted pro
rata on the basis of the partial divestiture. This ensures that the amortized acquisition
value has the current value at the time of each change to the position.
● For IFRS, the SAC gross amortization method applies.
→ Accounting → Settings for Position Management → Key Date Valuation → Define
Amortization Procedure.

In the security valuation, only the securities income is examined on the basis of the interest
rate trends or the securities price trends.
Securities valuation procedures specify how individual securities are valued in the portfolio.
The essential attributes are identical to those of the individual valuation procedure.
In addition to the attributes mentioned previously, it is also possible to enter a net present
value type:
● Initial or "dirty":
The value in the NPV field of the net present value table is used for the valuation.
● "Clean":
The value in the Clean Price field of the net present value table is used for the valuation.
● Depreciate costs fully:
If this check is selected, the activated costs are completely written down in the event of a
write-down in the valuation.
The difference between a security valuation and, for example, a one-step valuation is, that
with the one-step valuation only the interest component is valued. Normally, this one-step
valuation is used in combination with a foreign currency valuation.
→ Accounting → Settings for Position Management → Key Date Valuation → Define Security
Valuation Procedure.

A foreign currency valuation procedure is only used if the transaction contains foreign
currency transactions, which are transactions that are in a currency other than the local
currency.
As not all balances can be managed in the local currency, foreign currency valuation
procedures need to be defined. These procedures specify how balances in foreign currencies
are valued.
In the foreign currency valuation procedure, only the foreign currencies are valued, not the
exchange rates, as in the securities valuation procedures.
For example, a company in the Eurozone would hold a 100 US dollars position. This would
incorporate a FX Exposure risk. In case these USD 100 were bought for EUR 80 and the FX
rate would change both a profit or loss in EUR would have to be posted, depending on the rate
change.
The main basis for the valuation is a rate type. The rate type specifies the daily exchange rates
for the local currency.
Write-up and write-down rules also have to be stored here. The values are the same as for the
valuation procedure above.
→ Accounting → Settings for Position Management → Key Date Valuation → Define Foreign
Currency Valuation Procedure.

defines the update types. The second step assigns a usage to the update type. This usage
defines how the system uses the update type. For example, if an update type will be used in
the interest accrual functionality, a usage of Accrual/Deferral is assigned to the update type.
The screenshot above shows the assign usages step. The update type usage is set to
Valuation for the valuation update types. All update types that are to be used for accrued
procedure must assign the accrued/deferrals usages. For securities, derivatives, and money
market, the same update type can be used.
Follow IMG menu path Financial Supply Chain Management → Treasury and Risk
Update Types → Define Update Types.

Depending on which valuation steps are assigned to the position management procedure,
different update types are assigned to carry out the key date valuation.
In this configuration step, you define the update types that are used in the valuation process.
It is a two-step process. In the first step, the update types are defined. The second step
assigns a usage to the update type. This usage defines how the system uses the update type.
For example, if an update type will be used in the interest accrual functionality, a usage of
Accrual/Deferral is assigned to the update type.
Accrual/Deferral for the accrual/deferral update types. All update types that are to be used
for accrued procedure must assign the accrued/deferrals usages. For securities, derivatives,
and money market, the same update type can be used.
The relevant update types start with V or, for the reset, with RV. Before the update types can
be assigned, they need to be defined following the same logic as described in the previous
chapter.
The figure shows our example of money market. For IFRS and product type 51A, we have
assigned the position management procedure 4530. This position management procedure
includes the following valuation steps:
● Security Valuation
● Amortization
The relevant update types area assigned to each valuation step.

The same procedure applies for the other valuation steps. The assignments are done per
position management procedure. For our example, the update types for valuation must be
assigned to position management procedure 5580.

The screenshots above show the execution of a key date valuation.
How to Customize Valuations
Simulation: How to Customize Valuations

For more information on How to Customize Valuations, please view the
simulation in the lesson Valuing Trades online in the SAP Learning Hub.
LESSON SUMMARY

Unit 4
Lesson 7
Defining Derived Business Transactions
LESSON OBJECTIVES
Derived Business Transactions
Figure 324: Derived Business Transaction Configuration
This lesson will cover the above steps related to derived business transaction configuration.
Figure 325: What is a Derived Business Transaction?
Derived business transactions are triggered by operative business transactions and

complement them. The derived business transactions are specific to the given valuation area.
This means that the derived business transactions can be different for different valuation
areas, even if they stem from the same operative business transactions.
Below are examples of when derived business transactions are generated:

● When you enter a security purchase or loan disbursement involving a discount or premium
and manage the position using the gross procedure. The derived business transaction is
used to generate the discount or premium flow.
● When you enter position outflows (sale, repayment, exercise, stock swap with payment,
and any other position outflows that are not transfer postings), the price gains and losses
are generated as derived business transactions.
● If amortization is required by LAC and SAC amortizations for the position, and the
operative business transaction changes the amortized acquisition value of the position
(purchase value + capitalized costs + amortizations), the system generates amortization
flows for the total position.
● If you make internal transfer postings (securities account transfers, valuation class
transfers, corporate actions, exercising rights, exercising OTC options), the system
generates derived business transactions that transfer the positions per position
component.
● When you change the issue currency or the contract currency, currency swap flows are
generated to clear the old currency amounts in the general ledger and post the
corresponding amounts in the new currency.
Control of Processing of Derived Business Transactions
Figure 326: Derived Business Transactions
Animation: Derived Business Transactions

For more information on Derived Business Transactions, please view the
animation in the lesson Defining Derived Business Transactions, online in the
SAP Learning Hub.
The SAP naming convention of the update types corresponding to the Derived Business
Transaction folders is the following:
● Inflows → A
● Realized Gains Losses → B
● Amortizations → C

Lesson: Defining Derived Business Transactions
● Transfers → D
● Etc.
On each tab above, the update types are numbered sequentially.
Animation: Derived Business Transactions

For more information on Derived Business Transactions, please view the
animation in the lesson Defining Derived Business Transactions, online in the
SAP Learning Hub.
In this step, depending on which valuation steps are assigned to the position management
procedure, the different update types for carrying out the key date valuation as assigned.
In the example above, the update types for SAC Net amortizations are populated with the
corresponding update types to be used for SAC Net amortization cash flows.
Note that the derived business transactions are assigned by position management procedure.
Derived Business Transactions → Update Types → Assign Update Types for Derived Business
Transactions.

Figure 330: Control of Derived Business Transactions
Derived business transactions can have either a plan (planned) or fixed status, which
indicates if the update type has been posted to the SAP general ledger or not. (Note: there
may be some update types that should not post to the SAP general ledger, in which case they
will always remain in plan (planned) status.)
Depending on the requirements and on the volume of positions and business transactions,
the control of the calculation and posting of derived business transactions is set in
customizing.
There are the following three options:
● 1. "Online" settings with "Same Status"
The system updates the derived business transactions with each new or changed business
transaction and the statuses of both jointly change. For example, when you post a sale, the
price gain or loss is recalculated and immediately posted.
● 2. "Online" settings with "Status of plan"
Although the system immediately updates the derived business transactions, it leaves
them in the Planned status. The derived business transactions must be posted using the
Post Derived Business Transactions tile (Transaction code TPM18).
● 3. "Offline" settings with "Same Status"
For performance reasons, the system must not update the derived business transactions
each time the original business transactions are changed. The derived business
transactions must be created and posted using the Derived Business Transactions tile
(transaction code TPM27).
Derived Business Transactions → Control of Processing of Derived Business Transactions.

Lesson: Defining Derived Business Transactions
Figure 331: Derived Business Transactions in the Application
Update Types for Derived Business Transactions
Figure 332: Derived Business Transaction Update Types
Update types describe trade flows, and they carry information about the trade flows to
accounting for Transaction Manager. How a flow posts to the SAP general ledger is driven by
the account determination done for the update type.
complement them. The derived business transactions are specific to the given valuation area.
This means that the derived business transactions can be different for different valuation
areas, even if they stem from the same operative business transactions.
Depending on the valuation steps that are assigned to the position management procedure,
the different update types for carrying out the key date valuation need to be defined.
In this step, the update types for derived business transactions are created. Note that the
SAP system will come delivered with the update types needed for most processing.
When defining update types, first the update type is define with a long description, then the
derived business transactions is Derived Business Transactions. Always when defining update
types, these two steps are followed. First define the update type, then assign how the update
type will be used.

Derived Business Transactions → Update Types → Define Update Types and Assign Usages.
How to Configure Derived Business Transactions
Simulation: How to Configure Derived Business Transactions

For more information on How to Configure Derived Business Transactions,
please view the simulation in the lesson Defining Derived Business Transactions
LESSON SUMMARY

Unit 4
Lesson 8
Understanding Interest Accruals
LESSON OBJECTIVES
Interest Accrual Overview and Configuration
Figure 334: Interest Accrual Overview and Configuration
Figure 335: Understanding Interest Accruals - Process Flow

Animation: Understanding Interest Accruals - Process Flow

For more information on Understanding Interest Accruals - Process Flow, please
view the animation in the lesson Understanding Interest Accruals, online in the
SAP Learning Hub.
Before proceeding, consider the treasury process flow shown here. At period-end, valuations
and accruals are booked to the SAP general ledger. Both of these processes are typically
performed by an Accounting department.
On the application side, the Create Accruals/Deferrals tile is used for all accrued postings. To
reverse accrual postings, use the Reverse Accruals/Deferrals tile.
At period-end closing, the accruals program is carried out for all products. Before you can
start the accrued run, the contract must be settled (if settlement is required for the financial
transaction).
Note: The functionality described in this lesson applies to accruing interest, which is the most
common use of the functionality, but the accruals functionality could also apply to fees and
other charges that are being spread over the life-time of the instrument on periodic basis.

Lesson: Understanding Interest Accruals
Methods of Accruals and Deferrals
Animation: Interest Accrual Overview and Configuration

For more information on Interest Accrual Overview and Configuration, please
view the animation in the lesson Understanding Interest Accruals, online in the
SAP Learning Hub.
SAP supports two methods of accruals and deferrals. They are the reset and the difference
(incremental) methods.
With the difference procedure (also known as incremental postings), the incremental interest

In this configuration step, you define the update types, which is a two-step process. The first
step defines the update types. The second step assigns a usage to the update type. This
usage defines how the system uses the update type. For example, if an update type will be
used in the interest accrual functionality, a usage of Accrual/Deferral is assigned to the
update type.
Accrual/Deferral for the accrual/deferral update types. All update types that are to be used
for the accrual procedure must assign the accrual/deferrals usages. For securities,
derivatives, and money market, the same update types can be used.
To get to this customizing step, follow the IMG menu path Financial Supply Chain
Transaction Management → Update Types → Define Update Types.

In the next step, the interest flows are configured to be accrued (so the interest flow amounts
can be accrued at month-end). Enter the relevant company codes and product types that
have accrual flows. If the fields such as the Valuation Area or Position Management Procedure
are left blank, the entries apply across all valuation areas and position management
procedures.
When carrying out an accruals/deferrals run, the system differentiates between the reset and
a difference procedures. In the reset procedure, the accruals/deferrals are reset (an
offsetting posting is made) by the system on the next day. In the difference procedure, the
accruals/ deferrals remain and only the differences to the actual values are posted.
Update types that are relevant to accrual/deferral procedures are defined per accounting
code.
The customizing specifies, on the first screen, the update type that should be accrued for the
product types (based on the interest flows assigned to the product types), as well as the
update types used for the accrual postings (AD1000, AD1001, etc.), on the Update Types
folder. For the example above, the Reset Procedure (book and reverse) of accrual is specified.
→ Accounting → Accrual/Deferral → Money Market: Define Accrual.
Carry Out Settlement and Interest Accrual
Simulation: Carry Out Settlement and Interest Accrual

For more information on Carry Out Settlement and Interest Accrual, please view
the simulation in the lesson Understanding Interest Accruals online in the SAP
Learning Hub.


Unit 4
Exercise 23
Business Example
As part of period-end closing, interest accrual is carried out. To validate the postings for
interest accruals, create a new money market transaction, settle it, post its inception flows to
the ledger, then post interest accruals at the month-end date.
Note:
1. Create a fixed-term deposit in company code TA##. Use product type 51A with
transaction type 100. Investment of 3M EUR. The contract is started from the 15th of this
month and runs for two months. The current market rate is 2.3%. The contract is traded in
business partner BP1000.
Field name or data type Values
Company Code TA##

Product Type 51A
Currency EUR
Amount 3M
Start date 15th of this month
End date ++2
Interest rate 2.3%
Close date 15th of this month
2. Settle the transaction performed in the previous exercise step.
Note:
For product type 5##, the settlement step is not required.

Company Code TA##

Transaction Your transaction number.
3. Post the initial investment amount of this transaction. Select only company code TA##
and your transaction. The postings are done in all valuation areas.
Company Code TA##

Test Run yes, afterwards: no
Posting all valuation areas Yes
Up To And Including Due Date today +15 days
4. On the last day of this month, the accrued interest for this transaction is calculated and
posted to the ledger. Use the accrued interest procedure. Select only company code
TA## and your transaction. The reset takes place on the first day of the following months.
Company Code TA##

Transaction Your transaction number
Test Run Yes, afterwards: no
Accrual/Deferral Key Date last day of this month
Key Date Is Month End Yes
FI Posting Date <blank>
FI Document Date <blank>
Reset Key Date <blank>
Reset FI Document Date <blank>

Unit 4
Solution 23
Business Example
As part of period-end closing, interest accrual is carried out. To validate the postings for
interest accruals, create a new money market transaction, settle it, post its inception flows to
the ledger, then post interest accruals at the month-end date.
Note:
1. Create a fixed-term deposit in company code TA##. Use product type 51A with
transaction type 100. Investment of 3M EUR. The contract is started from the 15th of this
month and runs for two months. The current market rate is 2.3%. The contract is traded in
business partner BP1000.
Company Code TA##

Product Type 51A
Currency EUR
Amount 3M
Start date 15th of this month
End date ++2
Interest rate 2.3%
Close date 15th of this month
a) Choose the Create Financial Transaction tile.
b) Start the program and enter the settings provided in the table.
c) Choose Save.

Note the transaction number for later settlement activities and posting.
2. Settle the transaction performed in the previous exercise step.
Note:
For product type 5##, the settlement step is not required.
Company Code TA##

a) Choose the Process Treasury Transaction tile.
b) Choose Settle.
The Status tab shows the changed activity category: 20 (contract settlement).
3. Post the initial investment amount of this transaction. Select only company code TA##
and your transaction. The postings are done in all valuation areas.
Company Code TA##

Test Run yes, afterwards: no
Posting all valuation areas Yes
Up To And Including Due Date today +15 days
a) Start the transaction and enter the settings provided in the table, and press Execute.
b) Check the posting log.
c) Choose the Post Flows tile.
4. On the last day of this month, the accrued interest for this transaction is calculated and
posted to the ledger. Use the accrued interest procedure. Select only company code
TA## and your transaction. The reset takes place on the first day of the following months.
Company Code TA##

Test Run Yes, afterwards: no
Accrual/Deferral Key Date last day of this month
Key Date Is Month End Yes
FI Posting Date <blank>

FI Document Date <blank>
Reset Key Date <blank>

Reset FI Document Date <blank>
a) Choose the Execute Accruals / Deferrals tile (Treasury - Accounting).
b) Choose Product Groups → OTC Transaction:, and select to activate, then enter the
selection fields provided in the table, and press Execute.
c) Check the posting log.

LESSON SUMMARY

Unit 4
Lesson 9
Configuring Account Determination
LESSON OBJECTIVES
Account Assignment References
Figure 343: Account Assignment References
Business Example
For each financial product type, the posting logic needs to be defined and configured in SAP.
The following are part of the SAP Transaction Manager implementation:
● Posting relevance of update types
● Account assignment reference
● Account assignment reference determination
● Account determination
See how to define and configure the posting in SAP S/4HANA Treasury and Risk
Management on the next pages.


the lesson Configuring Account Determination, online in the SAP Learning Hub.
Before getting started, let's review the process flow for Transaction Manager. The slide above
shows the process flow for Transaction Manager financial transactions. In this section, the
Posting and Valuations / Accruals box is covered.
Figure 346: Before Getting Started
Before accounting related customizing should start, the implementation team should have
the end-to-end process of the different types of trades and the accounting entries that should
be generated for each trade type. It is important that the accounting entries be from inception
of the trade to maturity, and should include any period-end accounting entries. In addition, if
multiple accounting principles are required, the desired accounting entries for each
accounting principle are needed.

Lesson: Configuring Account Determination
The slide above shows an example of an Excel spreadsheet that shows the accounting entries
to be generated at each step of an FX forward hedge.
Figure 347: Configuration Steps
Animation: Configuration Steps

For more information on Configuration Steps, please view the animation in the
lesson Configuring Account Determination, online in the SAP Learning Hub.
The steps above outline the key steps needed to enter the account determination on SAP. The
term "account determination" refers to the customizing to determine accounting entries to be
generated based on the application side processing / inputs. The customizing steps do not
strictly need to be entered in the order shown. This is more a logical ordering.
Figure 349: Update Types Relevant to Posting
For each update type, it must be marked as relevant for posting, if it is to post to the SAP
General Ledger. Without this setting, the update type will not post. Also, if multiple valuation
areas are used, and an update type will not post for all valuation areas, the valuation area
must be specified in this customizing.

We have now used update types in many areas. Not all update types have to be designated as
posting-relevant. In this Customizing item, you specify for each update type whether it is
considered relevant to posting or not. If you mark an update type as relevant to posting, a
posting document is generated when this update type is used. If the relevant to posting check
is not selected, the update type is not forwarded to financial accounting.
Settings → Accounting → Link to Other Accounting Components → Indicate Update Types as
Relevant to Posting.
Figure 350: Account Assignment Reference
Animation: Account Assignment Reference

For more information on Account Assignment Reference, please view the
animation in the lesson Configuring Account Determination, online in the SAP
Learning Hub.
The account assignment reference links the Transaction Manager to the SAP General Ledger.
It is the main influencing factor in determining accounts and, therefore, represents the
granularity with which the positions for financial instruments appear in the general ledger.
Account assignment references are used to drive accounting entries for Treasury trades. At
this point in the configuration, though, only the account assignment reference symbol is
defined. At a later point, the SAP General Ledger account is assigned.
The account assignment reference is a freely defined string with a maximum size of 13 digits
that is used to include additional information to the account determination process. The
definition takes place in connection with the posting logic.
The diagram above shows SAP standard's naming convention of the account assignment
reference fields. SAP's account assignment reference naming convention can be used or a
new naming convention can be used. The system is flexible.
Account assignment references are required for each subledger position and for each class
position in a securities account. You can use the account assignment references to determine
the G/L account in FI in which the relevant position is to be managed. You assign the G/L
accounts to the account references in the IMG activity Define Account Determination. You

can use the account assignment references to control the posting of the subledger positions
in the general ledger.
You can use the account assignment reference of the class positions in the securities account
to control the posting of dividend payments, interest payments, and repayments for each
class position of the securities account. You do this by making the assignment of G/L
accounts in FI dependent on the account assignment reference for each account symbol
(position and interest/dividend revenue). You create the account assignment references
independently of the valuation areas. You can assign the account assignment references to
positions that are valuation-dependent on the area or you can control the account
determination per valuation area and account assignment reference.
Note: In contrast to the account assignment references in the operative valuation areas, the
account assignment references can be independent of position management in the G/L
accounts. This means that in the parallel valuation areas, you can control the posting of
positions to the G/L accounts using the account assignment references. However, you are
not obliged to do this.
Settings → Accounting → Link to Other Accounting Components → Define Account
Assignment References.
Account Assignment Reference Derivation Rules
Figure 352: Account Assignment Reference Derivation
Animation: Account Assignment Reference Derivation

For more information on Account Assignment Reference Derivation, please view
the animation in the lesson Configuring Account Determination, online in the SAP
Learning Hub.
In the determination of account assignment reference, you set up rules for how the system
should determine the account assignment reference as a trade is entered. The account
assignment reference is a required field in trades, and it is a key field in the Account
Assignment Reference Determination Rule configuration when you are determining to which

SAP General Ledger account to post the trade. It is a better process to have the account
assignment reference automatically derived, than to set it manually, therefore, the
determination rules are important.
The account assignment references are needed for both the operative and parallel valuation
areas, when there are parallel valuation areas.
The rules are defined per product group, where the product groups Securities and Listed
options / futures are grouped together. The definition of the determination rule is done per
valuation area. At the tab "Condition" the required valuation area per determination rule is
defined. The account assignment reference determination can be controlled by a derivation
rule or by an assignment. Double-clicking an assignment displays the details.
An assignment consists of two parts: the definition and the condition.
The definition specifies which fields or which account assignment reference is used for the
product type controlled in the condition.
In the conditions area, you specify which product type the assignment applies to.
Assignment Reference Determination.
Next, click the create step icon. In the pop-up screen that appears, select the Derivation rule
toggle and then click the continue icon. In this configuration, you enter the source fields at the
top of the screen and the target field at the bottom. For our example, use the product type
field as the source field. You want to determine the account assignment reference, so make
the account assignment reference the target field.
Figure 354: Account Assignment Reference Derivation - Steps
In the determination of account assignment reference, you set up rules for how the system
should determine the account assignment reference as a trade is entered. The account
assignment reference is a required field in trades, and it is a key field in the Account
Determination configuration when you are determining to which SAP General Ledger account
to post the trade. It is a better process to have the account assignment reference
automatically derived, than to set it manually, therefore, the determination rules are
important.
The account assignment references are needed for both the operative and parallel valuation
areas, when there are parallel valuation areas.
The rules are defined per product group, where the product groups Securities and Listed
options / futures are grouped together. The definition of the determination rule is done per
valuation area. At the tab "Condition" the required valuation area per determination rule is

defined. The account assignment reference determination can be controlled by a derivation

rule or by an assignment. Double-clicking an assignment displays the details.
An assignment consists of two parts: the definition and the condition.
● The definition specifies which fields or which account assignment reference is used for the
product type controlled in the condition.
● In the conditions area, you specify which product type the assignment applies to.
Assignment Reference Determination.
Next, click the create step icon. In the pop-up screen that appears, select the Derivation rule
toggle and then click the continue icon. In this configuration, you enter the source fields at the
top of the screen and the target field at the bottom. For our example, use the product type
field as the source field. You want to determine the account assignment reference, so make
the account assignment reference the target field.
Figure 355: Account Assignment Reference - Rule Definition
Depending on the derivation rule, it may be necessary to maintain rule values for the
derivation rules. The screenshot above shows the rule values. The screen shows the mapping
of source fields to target field, which depends on the actual rule.
The next step is to define what the source and target field should be set to for this rule. To do
this, click the Maintain Rule Values button and enter the values.
Note: To capture your determination of account assignment reference configuration to a
transport, you must select the derivation rule created and click the transport icon . The
derivation rule is then saved to a workbench transport.

Additional Account Assignments
Figure 356: Allocate Additional Account Assignments
In this step, if necessary, a cost center is assigned to an account assignment reference. This is
used when posting Treasury trades to a profit and loss (P&L) account where a cost center is
required for interest expense and income postings. In this step, a cost center is specified for
company code and account assignment reference combinations. This cost center is used in
the accounting entries for the combination specified if a cost center is required.
To enter the configuration, follow customizing menu path Financial Supply Chain
→ Accounting → Link to Other Accounting Components → Allocate Additional Account
Assignments to Account Assignment References.
Account determination
Figure 357: Account Determination Configuration Steps

Animation: Account Determination Configuration Steps

For more information on Account Determination Configuration Steps, please
view the animation in the lesson Configuring Account Determination, online in
The steps above outline the key steps needed to enter the account determination on SAP.
1. The first step is to define account symbols, which is done after double-clicking the
Definition of Account Symbols folder. Symbols such as INTEREST EXP or INTEREST INC
should be created to represent the types of G/L accounts to which to post. This makes the
account determination more user friendly.
2. The posting specifications define the types of posting specifications made by treasury
trades. Each posting rule contains the document type used and the debit and credit
symbols in that type of posting.
3. Assign the posting specifications to update types.
4. If different posting specifications should be used in different valuation areas (accounting

principles) for an update type, the different rules are specified here.
5. For each account symbol and account assignment reference, you assign an SAP General
Ledger account.
In the next slides, the steps will be considered in more detail.
Figure 359: Account Determination - Definition of Account Symbols
To control the defined account assignment references to various accounts, account

assignment has to be adjusted. The posting schemes and G/L accounts are assigned
depending on the chart of accounts. It is important to note that all specification of the
accounting entries to be made in Transaction Manager are done from this account
determination node. In other words, the accounting entries to be generated for interest
accruals, valuations, derived flows, etc., are specified using this customizing node.
Enter the chart of accounts for the corresponding company code, which is YCOA, in the
training system.
The account symbols are first defined in abstract form; these account symbols are valid for all
valuation areas.
Since the account assignment references in the parallel valuation areas no longer contain the
(original) information as to which account is to be posted to, you must also define an account
symbol for the position.
Double-click Definition of Account Symbols. A description and a posting type appear on the
right for each account symbol. Specify that there is to be position posting and a profit posting.

● The position posting is entered directly into the balance; the profit posting is entered into
the profit-and-loss statement.
● You can also see that account symbol 3 is specified with the description "bank clearing."
This is the same as the posting record "11100 Position to bank clearing" that you just saw.
● The correct bank clearing account is taken from the house bank stored in the business
transaction.
Before you can assign the accounts, you have to define the account symbols. Depending on
the posting area, different account symbols are defined. The following subdivision has already
been used:
1. Position posting
2. Bank clearing
3. Interest revenue/expense
4. Receivables
5. Amortization
To enter account determination, use the customizing path: Financial Supply Chain
→ Accounting → Link to Other Accounting Components → Define Account Determination.
Figure 360: Account Determination - Posting Specifications
General posting specifications are defined in the Definition of Posting Specifications folder. A
posting specification is characterized by a debit (40) and credit (50) posting. The accounts
are not yet assigned at this point; the account symbols are merely assigned now.
When a posting is carried out, FI posting documents are always generated. In the upper part
of the input template, you specify which document type is used. It is good practice to create a
document type for Transaction Manager postings so they can be easily reported on.

Figure 361: Account Determination - Assignment of Update Types
For the assignment of posting specification to an update type is done for all valuation areas in
the Assignment of Update Types to Posting Specs folder.
Figure 362: Account Determination - Valuation Areas
In the second to last step, if different posting specifications should be assigned to an update
type based on the valuation area, the assignment of different posting specifications to the
update types can be done by valuation area.
Figure 363: Account Determination - Assignment of G/L Accounts
The final step of account determination is to assign an G/L account to each account symbol.
If different posting logic is needed for IFRS and local GAAP, include the account assignment
reference or use the additional field for valuation area. Normally, for IFRS and local GAAP,
different positions and P&L accounts are used.
The G/L account assigned must be in the specified chart of accounts.
Notice in this step, there is a connection of the account symbol, valuation area, and account
assignment reference.

Figure 364: Account Determination - Post Flows
You see the posting log. In the menu bar for each posting record, you can see information
about the company code and the valuation area. Make sure that all valuation areas that were
stored for the company code are posted. In the posting header, you can find information
about the update type (MM1100- in this case) and the valuation class. The stored accounts
were retrieved in the main part, the posting record. At posting document level, you can see
the posting keys and the assigned accounts.
The posting process of a fixed-interest bond is different to the posting process of money
market products. Security management is split into transaction and position management.
For both areas, different transactions are used in the application. Before you can post the
transaction, the contract must be released, settled, counter confirmation assigned, and the
cash flows released for posting. Only then the transaction cash flows can be posted. For fixed-
interest bonds, the investment and accrued interest amount are posted.
→ Accounting → Link to Other Accounting Components → Define Account Determination.
How to Configure Account Assignment Determination Rules
Simulation: How to Configure Account Assignment Determination Rules

For more information on How to Configure Account Assignment Determination
Rules, please view the simulation in the lesson Configuring Account
Determination online in the SAP Learning Hub.
Link to Accounting
Simulation: Link to Accounting

For more information on Link to Accounting, please view the simulation in the
lesson Configuring Account Determination online in the SAP Learning Hub.

Unit 4
Exercise 24
Link to Accounting
Business Example
For the new money-market product type 5##, the accrual/deferral procedure and posting
rules for the integration into SAP Financial Accounting are required. Make all the required
settings, and then test them by entering a new financial transaction.
Dependencies
This exercise uses the following dependencies executed in previous exercises:
● The product type 5## and transaction type 100 were created.
● A general valuation class was assigned to product type 5## and transaction type 100.
Note:
1. Validate the account determination customizing. The existing account-assignment

references can be used because they do not include any product -type-specific
information. The next step is to adopt the existing account determination rules. Define a
new derivation rule for product type 5## and valuation area IFRS. Use your group number
as the name of the determination. Assign product type 5## to account assignment
reference 203200000000. Use the derivation rule for product type 51A as a reference, if
you like.
Table 60: Determination Rule

Field Name Value
Step Description: User defined text + group number
Definition (on the Definition tab)
Constant 203200000000
Target field AA_REF
Condition (on the Condition tab)
Name PRODUCT_TYPE
Operator =

Field Name Value

Value 5##
Name Fixed-Term Deposit 5##
and:
Name VALUATION_AREA
Operator =
Value 001
Name IFRS
2. Enter a financial transaction using the Create Financial Transaction tile with business
partner BP## and with your product type 5##. You want to invest 10 M USD for two
months. The current market rate for this transaction type is 1.1%. Use this as the interest
rate for your financial transaction.

Field Name Value
Amount 10M
Currency USD
Interest rate 1.1%
Start date Today
End date ++2
(Interest) frequency At end of term
3. Check the position indicator and ensure the defined account assignment reference and
the position-management procedure are selected. When all settings are correct, release
the transaction from your neighbor, if required. Please select only company code TA##
and your transaction number.
4. Post the investment amount of this transaction. If you like, execute as a test run first.
Post the transactions you created in the previous lesson. After the transactions have been
created and released in the workflow, the individual cash flows are posted on the due date.
To do this, return to the application and double-click the Post Flows tile.
Enter the following data to ensure that only your transactions are posted.
Company Code TA##

Up To and Including Due Date Today’s date
Test run No

Post all valuation Areas Yes
5. At period-end closing, the valuation run is carried out for this transaction. Calculate the
Net Present Value (NPV) of the financial transaction and then start the valuation run to
post the month-end valuation to the SAP general ledger. Select only your transactions.
(Do not post your neighbor’s transactions.)
Table 62: NPV Calculation Details

Field Name Value
Product Group: OTC Transaction: MM, Forex, OTC Deriva-

tives
Company Code: TA##
Transaction: Your transaction number
Evaluation Type: Y001
Key Date: Last day of this month
Test Run: Yes, then no
Price/NPV Type: 001
Table 63: Valuation Run

Field Name Value
Product Group: OTC Transaction

Company Code: TA##
Key Date for Valuation: Last day of this month
Key Date for Reset: First day of the next month
Valuation Category: Mid-year valuation with Reset

Unit 4
Solution 24
Link to Accounting
Business Example
For the new money-market product type 5##, the accrual/deferral procedure and posting
rules for the integration into SAP Financial Accounting are required. Make all the required
settings, and then test them by entering a new financial transaction.
Dependencies
This exercise uses the following dependencies executed in previous exercises:
● A general valuation class was assigned to product type 5## and transaction type 100.
Note:
1. Validate the account determination customizing. The existing account-assignment

references can be used because they do not include any product -type-specific
information. The next step is to adopt the existing account determination rules. Define a
new derivation rule for product type 5## and valuation area IFRS. Use your group number
as the name of the determination. Assign product type 5## to account assignment
reference 203200000000. Use the derivation rule for product type 51A as a reference, if
you like.
Table 60: Determination Rule

Field Name Value
Step Description: User defined text + group number
Definition (on the Definition tab)
Constant 203200000000
Target field AA_REF
Condition (on the Condition tab)
Name PRODUCT_TYPE
Operator =

Field Name Value

Value 5##
Name Fixed-Term Deposit 5##
and:
Name VALUATION_AREA
Operator =
Value 001
Name IFRS

Settings → Accounting → Link to other Accounting Components → Define Account
Assignment Reference Determination (OTC Transactions).
b) Press the Display / Change toggle to get into change mode.
c) Choose Create Step.
Note:
In Customizing, three determination rules for money market are defined,
but for company code TA## only the determination rules for IFRS and
HGB are required. For our case, we want to create a new determination
rule.
d) Select the item Move and confirm your entries.
e) Enter a description text and enter the data provided in the table, Determination Rule.
f) Choose Save.
2. Enter a financial transaction using the Create Financial Transaction tile with business
partner BP## and with your product type 5##. You want to invest 10 M USD for two
months. The current market rate for this transaction type is 1.1%. Use this as the interest
rate for your financial transaction.

Field Name Value
Amount 10M
Currency USD
Interest rate 1.1%
Start date Today
End date ++2

Field Name Value

b) Choose the Create Financial Transaction (FTR_CREATE) tile (Treasury - Trade

Processing).
c) Enter the data provided in the table, Transaction Data.
d) Choose Save.
Note the transaction number for later settlement activities and postings.
3. Check the position indicator and ensure the defined account assignment reference and
the position-management procedure are selected. When all settings are correct, release
the transaction from your neighbor, if required. Please select only company code TA##
and your transaction number.
a) In order to check the position indicator, go to the group Treasury - Trade Processing
and pick the Tile Process Treasury Transaction (FTR_EDIT) (Treasury - Trade
Processing).
b) Give the company code TA## and the transaction number created.
c) Pick Display from the list at screen Process Financial Transaction.
d) Now go to Environment and pick the value Position Indicator.
e) Return to the Fiori Launchpad using the Home button.
4. Post the investment amount of this transaction. If you like, execute as a test run first.
Post the transactions you created in the previous lesson. After the transactions have been
created and released in the workflow, the individual cash flows are posted on the due date.
To do this, return to the application and double-click the Post Flows tile.
Enter the following data to ensure that only your transactions are posted.
Company Code TA##

Up To and Including Due Date Today’s date
Test run No
Post all valuation Areas Yes
a) To ensure that only your transactions are posted, enter the data provided in the table.
b) Choose Execute, and check the individual posting transactions.
c) Return to the application, and choose the Post Flows tile (Treasury - Accounting).

5. At period-end closing, the valuation run is carried out for this transaction. Calculate the
Net Present Value (NPV) of the financial transaction and then start the valuation run to
post the month-end valuation to the SAP general ledger. Select only your transactions.
(Do not post your neighbor’s transactions.)
Table 62: NPV Calculation Details

Field Name Value
Product Group: OTC Transaction: MM, Forex, OTC Deriva-

tives
Company Code: TA##
Evaluation Type: Y001
Key Date: Last day of this month
Price/NPV Type: 001
Table 63: Valuation Run

Field Name Value
Product Group: OTC Transaction

Company Code: TA##
Key Date for Valuation: Last day of this month
Key Date for Reset: First day of the next month
Valuation Category: Mid-year valuation with Reset
a) Proceed to the group Treasury - Accounting and choose the Calculate Net Present
Values (TPM60) tile.
b) Calculate the NPV for this transaction. Start the transaction and enter the settings
provided in the table, NPV Calculation Details.
c) Choose the Execute Valuation tile.
d) Start the valuation run for your transaction. Check the posting log and the selected
update types, use the data in the table, Valuation Run.
e) Start a test run. If no errors occur, deselect the test run indicator and post the
valuation to the SAP general ledger.

LESSON SUMMARY

Unit 4
Lesson 10
Replacing LIBOR
LESSON OBJECTIVES
Learning about Benchmark Reform
Figure 367: Benchmark Reform Details
LIBOR, which is short for the London Interbank Offered Rate, is the benchmark interest rate
used in bonds, loans, derivatives, intercompany loans, etc., worth over $350 trillion around
the world. It is being phased out starting at the end of 2021 due to its history of being
manipulated by banks. This is what we refer to as the "benchmark reform".
LIBOR will be replaced by a variety of Alternative Reference Rates (ARRs) or Risk-Free Rates
(RFRs) around the globe - generally by country. This slide shows an example of some of the
requirements included with the benchmark reform. These new rates behave differently from
LIBOR in some significant ways. For example, The Secured Overnight Financing Rate (SOFR)
is expected to be the preferred alternative reference rate for US dollar financial products after
2021. SOFR is based on transactions in the Treasury repurchase market, where banks and
investors borrow or loan Treasuries overnight. Similarly the ESTR reference rate will be used
for EUR financial products after 2021.
SAP customers must actively prepare for a one-time transition on SAP from LIBOR to one of
the alternative rates. In addition to modifying or renegotiating outstanding contracts with the
counterparties of the trades, this task involves preparing and updating the SAP software and
outstanding trades. Currently, conversion of existing instruments is not supported.

Note: The functionality covered in this section impacts only floating rate instruments
currently using LIBOR.
For the area of the LIBOR replacement SAP has created the following composite SAP notes:
The functionality is delivered via following notes, there are four composite notes:
● 2939657: Composite SAP Note: EU Benchmark Regulation, Risk-Free Rates (RFRs) -
shared basis for CML and TRM
2932789: Composite SAP Note: EU Benchmark Regulation, Risk-Free Rates (RFRs), TRM
2880124; Composite SAP Note for Loans Management: EU Benchmark Regulation, Risk-Free
Rates (RFRs), CML
2971185: Composite SAP Note for Interest Rate Swaps, TRM
At the time this course was written, Money Market transactions (Product Categories 550 and
580), bonds (Product Category 040), and swaps (Product Category 620) are supported with
the new functionality outlined here.
Note: Installment bonds in Product Category 040 are excluded as well as Product Category
042 and handling of capitalized interest.
For those wanting more background information, please see the below articles.
● FSB - Financial Stability Board - "Overnight Risk-Free Rates: A User's Guide (June 4,
2019)"
● Alternative Reference Rates Committee (ARRC) - "A User's Guide to SOFR (April 22,
2019)"
● European Central Bank - "Overview of the euro short-term rate (€STR)"
Figure 368: Benchmark Reform Impact
The first step is to assess the impact of the change and determine a plan of action for this
one-time conversion from LIBOR to the new Risk-Free Rates (RFRs).
SAP customers should define a strategy to move to the new reference interest rates, which
may look something like the list below.
1. Review and install needed OSS notes. Please see the composite notes listed on the last
slide. As applying OSS notes is a Basis task, it is important to get this started.
2. Determine scope of impact, e.g. the list outstanding trades impacted
3. Negotiate with counterparties, if necessary.
4. Determine any processes that will need to change when LIBOR is replaced, e.g. the import
of market data.

Lesson: Replacing LIBOR
5. After the OSS notes have been applied, execute the configuration changes for the new
functionality.
6. Create new reference interest rates and yield curves.
7. Test the new functionality in a development and quality system.
8. Do a practice run-through of modifying existing contracts (adding a new interest

condition) or closing out existing contracts and creating new ones in a quality system.
9. Modify existing contracts or close out outstanding trades and create new trades in the
production system.
Figure 369: Parallel Interest Conditions
The SAP functionality to cover the new requirements related to the replacement of LIBOR are
covered. This is meant to be an overview of the functionality.
The first requirement that must be met is Parallel Interest Conditions in trades, which is
shown here in a Money Market trade.
The requirement Parallel Interest Conditions in trades is met by allowing multiple Condition
Groups to be assigned to one trade. It is the multiple Condition Groups assigned to the trade
that enables the functionality of the parallel interest calculation.
By viewing the Overview of Conditions screen, the user is able to see the multiple interest
conditions assigned to the trade.
Note: The user interface stays the same, for the most part, but it is the underlying calculations
have changed with the new requirement.
Figure 370: New Interest Calculation Methods

Animation: New Interest Calculation Methods

For more information on New Interest Calculation Methods, please view the
animation in the lesson Replacing LIBOR, online in the SAP Learning Hub.
If the Parallel Interest Conditions are used, two additional new Interest Calculation Methods
are supported, which contain additional features. These new Interest Calculation Methods are
visible in the interest condition, as shown here.
With the rollout of this functionality, two new Interest Rate Calculation Methods are delivered
for both Money Market, Interest Rate Swap, and Securities trades.
● 5 - Compound Interest Calculation
● 6 - Average Compound Interest Calculation
All */act Interest Calculation Methods are supported for the new functionality, e.g. act/360,
act/365, etc. Other Interest Calculation Methods are not supported with the new functionality
at this point in time.
Figure 372: Parallel Interest Condition - Interest Rate Adjustment
The interest rate adjustment condition reflects a new field, shown here, the Lockout Period.
With the lookback (in arrears), the observation period for the interest rate calculation starts
and ends X days prior to the interest period. Therefore, the interest payments can be
calculated prior to the end of the interest period.
Note: The lookback is not new functionality added with the parallel interest conditions but is
now given a name. the lookback is the market data rate shift applied for the interest rate
adjustment.
With the lockout period (in arrears), which is new functionality, the RFR is no longer updated,
i.e. it is set, for X days prior to the end of an interest rate period (lockout period). During this
period, the RFR on the day prior to the start of the lockout period is applied for the remaining
days of the interest period.

Figure 373: Parallel Interest Condition: Lookback Example
With the lookback (in arrears, meaning a negative lookback number of days), the observation
period for the interest rate calculation starts and ends X days prior to the interest period.
Therefore, the interest payments can be calculated prior to the end of the interest period.
In this case, the lookback is set to 2- in the interest rate adjustment settings of the trades,
which indicates to shift back two days when determining the rate to use for the interest rate
adjustment.
In addition to the interest rate adjustment settings of the trade, the slide shows the trade's
cash flows, and the reference interest rates are shown.
The observation period for the interest rate calculation starts and ends X days prior to the
interest period. Therefore, the interest payments can be calculated prior to the end of the
interest period.
Figure 374: Compound Interest Calculation Formula
Animation: Compound Interest Calculation Formula

For more information on Compound Interest Calculation Formula, please view
the animation in the lesson Replacing LIBOR, online in the SAP Learning Hub.
The slide shows the compound interest calculation formula used by SAP.
The number of days in the interest period is taken into account.

Figure 376: Compound Interest Calculation Example
Here we see the details of the example trade for the compound interest calculation.
This is a floating rate trade with a ESTR floating rate with no spread. It pays interest every
three months.
On the right, the Overview of Conditions screen is displayed showing interest condition
assigned to the trade.
Here we see the interest condition details. The Interest Calculation Type is set to Compound
Interest Calculation.
Daily interest rate adjustments with a calendar rule set to take the previous working day.
In this example, there is no lookback or lockout period. There is also no shifting on the due
date of the interest payment with the first interest payment to be made on January 14th,
2020.

Here we see the resulting cash flows. Notice the change in the base amount, which is the
amount used in the calculation of the interest. The base amount is decreasing because the
interest rate is always negative.
Also notice that the Days field shows the number of days used in the calculation of the
interest. Where there is a '3' in the Days column, this is Friday and the two weekend days. The
interest amount shown reflects the amount for three calendar days.
Figure 379: Average Compound Interest Calculation Formula
Animation: Average Compound Interest Calculation Formula

For more information on Average Compound Interest Calculation Formula,
please view the animation in the lesson Replacing LIBOR, online in the SAP
Learning Hub.
The slide shows the average compound interest calculation formula used in SAP.
The number is rounded. The formula shows the flow factor and base factor.

Figure 381: Average Compound Interest Calculation Example
Here we see the details of the example trade for average compound interest calculation. At
the trade structure level, the trade is the same as in the compound interest calculation
example.
This is a floating rate trade with a ESTR floating rate with no spread. It pays interest every
three months.
On the right, the Overview of Conditions screen is displayed showing interest condition
assigned to the trade.
Looking at the interest condition details, we see the Interest Calculation Type is set to
Average Compound Interest Calculation. We also see that two different types of rounding that
can be done.
When the Average Compound Interest Calculation Interest Calculation Type is selected, two
additional boxes of information are displayed for rounding purposes.
Notice there are two places for rounding:
● The Average Interest Rate can be rounded. In this case, the Average Interest Rate is being
rounded to 5 decimal places.
● The factor can be rounded. In this case, the factor is being rounded to 20 decimal places.

The above rounding fields would be set based on the trade agreements.
On the right, the interest rate adjustment condition is displayed. There is no lookback or
lockout period set.
On the Cash Flow tab of the trade, there are a number of new fields.
In this slide, the user is shown the effect of rounding rules on the trade's cash flows. Notice
the Average Interest Rate is rounded at five decimal places. (Check the Average interest rate
rounding setting on the last slide, if in doubt.)
Each Average Interest Rate is calculated as the average rate for the interest rates for the
current period. The Average Interest Rate is calculated is always calculated as the average
from the first day of the period to the current date.
This slide show how the interest cash flow is calculated (in green).
The interest cash flow is calculated as the Average Interest Rate for the date (which is the
average interest rate for the period up until that date) times the pro rata of the days (sum of
the days up until that date) of the period up until that date. The rounding is in the Average
Interest Rate.

Figure 385: Interest Rate Spread Handling
Animation: Interest Rate Spread Handling

For more information on Interest Rate Spread Handling, please view the
animation in the lesson Replacing LIBOR, online in the SAP Learning Hub.
There are different ways to control the spread on the floating interest rate with the new
functionality. The formulas used on SAP are displayed here.
With Compounded Interest Calculation (5), the spread is compounded with the daily
reference interest rate.
With Average Compound Interest Calculation (6), the spread is compounded with the daily
Figure 387: Interest Rate Spread Handling - Spread Logic 1
Spread Logic 1 - Spread is compounded with daily RFR.

This uses the formula Average Compound Interest Calculation (6) shown on the last slide and
is the classic example of entering a spread into the trade.
This slide shows an example for Average Compound Interest calculation. The entry in the
Percentage Rate field in the Data for Percentage Calculation box will be included the spread
compounding

This slide shows the Cash Flows tab in the trade. The spread is added to the reference interest
rate and the average interest rate is calculated for the period, as explained previously.
Spread Logic 2 - Spread as Parallel Interest Condition

Notice there is no spread entered on the Interest Structure area of the trade, instead multiple
interest conditions are entered, as shown on the right with the Overview of Conditions screen
of the trade.
This method of handling the spread uses the parallel interest conditions.

The interest amount is calculated and is displayed as one additional flow in the trade.
The calculation of the spread is completely independent from the calculation of the flows
within the compounding period.
Spread Logic 3 - Spread within Interest Condition

This option is only available for the Average Compound Interest calculation.
Notice there is no spread entered on the Interest Structure area of the trade, instead the
spread is entered in the interest condition (next slide).
As the slide shows there is just one interest condition in the trade.
The spread:
● is not compounded
● is added to the annualized rounded average interest rate
● Cap/Floor is applied on this result
The result is shown in field Average Interest Rate.

This slide shows the interest condition where the spread is entered (.750).
In this example, an entry in the Spread field in the Average Interest Rate box will add the
spread after compounding.
This spread is not compounded.
Notice the Upper and Lower limit amounts. If the lower limit is set to zero, there are no
negative spreads.
Here we see the resulting cash flows.

Figure 394: Money Market Configuration: Parallel Interest Condition Activation
The left side shows for the SAP S/4HANA on-premise releases and on the right the SAP S/
4HANA Cloud Editions.
This slide shows in the Money Market module where in configuration parallel interest
conditions are activated for the following Product Categories:
● 550 - Interest Rate Instrument
● 580 - Current Account Style Instrument
Note that the setting for Parallel Interest Conditions is at the definition of the product type.
In SAP S/4HANA Cloud Edition, the product types are delivered with this setting.
Figure 395: Securities Configuration: Parallel Interest Condition Activation
For Securities instruments, the setting is at the class master data level for the Product
Category below.
● 040 - Bonds
Again, the left side shows for the SAP S/4HANA on-premise releases and on the right the SAP
S/4HANA Cloud Editions.
In SAP S/4HANA Cloud Edition, all instruments can be created with the Parallel Interest
Condition. For this reason, the Cash Flow Calculation field is hidden in the Security Class
Master Data.

Figure 396: Securities Configuration: Parallel Interest Condition
For Securities Condition Type field selection configuration, there are new fields are added
relevant to this functionality, as shown here. These fields should all be set as "optional", as
shown in the slide.
Note: There are additional fields available that are not reflected on the slide.
LESSON SUMMARY


Unit 4
Learning Assessment
1. Both traders and portfolios are optional trade level field.

X True
X False
2. Both trader and portfolio customizing is done by company code.

X True
X False
3. Which of the following are specified in the flow type definition?

X A Payment request relevant.
X B Posting relevant.
X C Relevant to posting.
X D Relevant to cash management.
4. Is there a specific flow category to reflect cash flows on the "other flows" tab in trades?
X True
X False
5. Is it necessary to assign flow types created from conditions to the transaction type?
X True
X False

6. Condition types are?

X A Calculation rules for trade flows.
X B Assigned to transaction types.
X C Assigned to product types.
7. Which are Money Market trade types?

X A Facilities.
X B Cash Flow Transactions.
X C Interest Rate Instruments.
X D Interest Rate Swap.
8. Number ranges are assigned at the product type level.

X True
X False
9. What types of transactions should be setup under the product category 'Trade Finance'?
X A Interest Rate Instrument.
X B Letters of Credit.
X C Bank Guarantee.
X D Subscription Rights.
10. At what level are the derived flows specified in standing instructions?
X A By business partner.
X B By business partner and company code.
X C By company code.
X D By valuation area.

11. Derived flows show in which tab in a financial transaction?

X A Structure tab
X B Other flows tab
X C Cash flows tab
X D Status tab
12. The deal workflow release must be implemented.

X True
X False
13. The Account Assignment Reference is included in the position indicator.

X True
X False
14. Which of the following statements is true regarding the Position Management Procedure.
X A The position management procedure is a required field in trades.
X B The position management procedure is assigned to a company code and valuation

area to drive different accounting principles.
X C The position management procedure is used for internal position management.
X D The valuation steps required in a key date valuation are specified in the definition of
the position management procedure.
15. Select all that are true regarding the key date valuation.
X A Foreign exchange valuation can be included in the key date valuation.
X B Amortization can be included in the key date valuation.
X C Security prices may be required for key date valuations.

16. Which of the options listed below can be used to manage Derived Business Transactions?
X A The derived business transaction are created before the Original Business
Transaction.
X B The derived business transaction is created and posted immediately at the time of
the Original Business Transaction.
X C The derived business transaction is created at the time of the Original Business
Transaction but not posted at the time of the Original Business Transaction.
X D No automatic Creation of Derived Business Transactions. Therefore, they have to

be created and posted as a separate step.
17. SAP supports which types of interest accruals?

X A Forward calculation
X B Incremental
X C Backwardation
X D Book and reverse
18. The accrual functionality on SAP should only be used for interest flows.
X True
X False
19. What is meant by Account Assignment Reference Determination?

X A Automatic determination of the posting rules for a trade
X B Automatic determination of a derivation rule to be used in driving the postings for a

trade
X C Automatic determination of the Account Assignment Reference for a trade
X D Automatic determination of various fields in a trade such as the portfolio field and
business partner

20. The Account Assignment Reference is one of the most important components driving a
trade's postings.
X True
X False
21. The Account Determination Posting Specification contains which of the following fields?
X A Account Symbol
X B Account Assignment Reference
X C Document Type
X D Posting Key


UNIT 5 Additional Configuration
Lesson 1
Maintaining Company Code Additional Information 403
Lesson 2
Entering Trade Field Selection 407
Exercise 25: Change Trade Field Status 411
Lesson 3
Establishing the Cash Management Integration 417
Lesson 4
Mirroring of Trades 423
UNIT OBJECTIVES
● Understand additional settings made by currency and company code

● Define trade field selection
● Define SAP Cash Management settings
● Understand the usage of mirroring
● Define mirroring configuration

Unit 5: Additional Configuration

Unit 5
Lesson 1
Maintaining Company Code Additional
Information
LESSON OBJECTIVES
Company Code Additional Information
Figure 397: Company Code Additional Information (1)
For all company codes to be used for Transaction Manager processing, the Company Code
Additional Information settings should be understood and configured. These are
miscellaneous settings used across various Transaction Manager modules.

Figure 398: Company Code Additional Information (1/2)
Based on the FI company codes, transaction manager specific company code specific
settings need to be defined. This step should be done for all company codes you will use the
transaction manager module. In this step, a number of different settings can be made. Based
on the individual implementation scope, not all the fields may be relevant.
The various configuration nodes in this unit can be found under Financial Supply Chain
→ Organization → Define Company Code Additional Data.
Under the "General settings", the SWIFT / BIC code relates to the setting of the SWIFT code
used to identify the company as a member of the SWIFT network.
Under the "Exchange rate settings", the exchange rate calculation procedures are needed to
use a standardized rate basis for foreign currency postings for the securities and loans areas.
This rate type is used as a default if a rate type is not specified.
Under the "Securities settings", the indicator "Short sales possible" indicator should be
selected if short sales are allowed in the company code. Also, define a price type that should
be used for evaluations.
Under the "Loans settings", specify the factory calendar that should be used for loans
management, if a calendar has not been assigned to the currency in use under Financial
General Settings → Transaction Management → Currencies → Assign Calendar.

Lesson: Maintaining Company Code Additional Information
Figure 399: Company Code Additional Information (2/2)
Under the "Regulatory reporting settings", if regulatory reporting is active, specify the fields in
this section.
Under "Settings for variable interest rates", specify how planned records (future cash flows)
should be calculated and displayed, e.g. in cash management and on the cash flows tab in
trades. There are several options to choose from.
The following options are available:
● Zero update:
Interest rate flows that have not yet been adjusted receive an interest rate of 0% and
therefore the amount 0.
● Update with interest rates maintained automatically:
The interest rate is the last interest rate adjusted automatically in the system for the
● Update types with interest rates maintained manually:
The interest rate is the last interest rate adjusted manually in the system for the reference
interest rate.
● Update with current interest rates:
The interest rate used is the last interest rate adjusted in the system for the reference interest
rate, regardless of whether it was created manually or automatically.
● Update with interest rates maintained automatically/manually:
The interest rate is the last interest rate adjusted automatically in the system for the
reference interest rate. If there is no automatically adjusted interest rate, the last manually
adjusted interest rate is used.

Under "Settings for variable commodity prices", specify how planned records (future cash
flows) should be calculated and displayed, e.g. in cash management and on the cash flows tab
in trades. There are several options to choose from. Use the F1 help to view the options
available.
Under "Settings for variable securities prices", specify how planned records (future cash
flows) should be calculated and displayed, e.g. in cash management and on the cash flows tab
in trades. There are several options to choose from. Use the F1 help to view the options
available.
Currency Settings
Figure 400: Currency Settings
Within a Transaction Manager implementation, there is typically a number of currencies

relevant to the implementation. For each of those currencies, a calendar should be created
that holds the banking working days of the country the currency is relevant to. For example, if
USD is used in an implementation, a U.S. banking calendar should be created that holds the
banking work days and holidays for the U.S.
Calendars are defined and maintained using the customizing path SAP Netweaver → General
Settings → Maintain Calendar. Typically calendars are created and maintained at a central
level within an implementation, e.g. someone on the Basis team is responsible for maintaining
all calendars.
For each currency to be used in the Transaction Manager implementation, a banking calendar
should be maintained in configuration. After this step has been done, Transaction Manager
functionality will ensure working day checks are done using the calendar specified for the
currency. This ensures, for example, that Transaction Manager payments will not fall on non-
working days without warning the user.
The customizing path to assign a banking calendar to a currency is Financial Supply Chain
→ Transaction Management → Currencies → Assign Calendar.
LESSON SUMMARY

Unit 5
Lesson 2
Entering Trade Field Selection
LESSON OBJECTIVES
Field Selection
Figure 401: Field Selection
As with other transactional data on SAP, it is possible to set field status control at the financial
transaction level. Using the field selection control function, it is possible to control which fields
are shown and hidden, and to permit or request entries.
Setting up the financial transaction field selection is a two-step process. The first step is to
define the field selection strings. Once strings (templates) have been defined, they can be
assigned at the following levels:
1. Product type and company code
2. Transaction type
3. Activity category
4. Function
You can individually configure which fields are used for data entry on the corresponding tab
pages. You can then use the field modification settings in customizing to define whether a
field is hidden, displayed, ready for input, or mandatory.

It is possible to define how the user screens will be displayed. All the fields that are visible in
the entry screens are grouped according to business criteria. For each field group, whether it
should be shown or hidden and whether the entries should be required or optional is defined.
These field selection strings can then be assigned directly to a product category, and further
selected and defined through product type, company code, transaction type, activity category
or functions. It is also possible to configure overall settings for the different tab pages on the
transaction entry screen, such as administration or correspondence. These tab pages can be
set to hidden, optional entry or display only. However, tab pages cannot be defined as
mandatory.
Note that the structure tab page cannot be hidden.

Lesson: Entering Trade Field Selection
Animation: Field Selection

For more information on Field Selection, please view the animation in the lesson
Entering Trade Field Selection, online in the SAP Learning Hub.
The field selection strings (templates) can be assigned at the following levels:
1. Product type and company code
2. Transaction type
3. Activity category
4. Function
When you create / display / change a financial transaction, the relevant field selection string
is taken from this table. The system first searches for a field selection string for the function. If
the search is unsuccessful, it searches for the field selection string for the activity category. If
this search is also unsuccessful, it searches through the next level up. The last search level is
the assignment to the product type and company code.
You are not completely free to configure the field selection controls as you wish. You are not
allowed to make settings that contradict the predefined system settings. For example, if you
attempt to hide a field group regarded as mandatory by the system (essential to the business
process or necessary for technical reasons), the system ignores the setting.
Change Trade Field Status
Simulation: Change Trade Field Status

For more information on Change Trade Field Status, please view the simulation in
the lesson Entering Trade Field Selection online in the SAP Learning Hub.


Unit 5
Exercise 25
Business Example
You are not using certain fields and tabs in financial transactions and would like to hide
specific fields and tabs.
Dependencies
This exercise uses the product type 5## created in an earlier exercise.
Note:
1. Hide the Memos and Partner Assignment tabs and the Authorization Group, Guarantor,
and Finance Project fields.
Table 64: Field Selection

Field Selection 5## field selection

Product Category 510
Table 65: Tabs

Memo / Notes tab (86) Select Hide

Partner Assignment tab (95) Select Hide
Authorization Group (109) Select Hide
Guarantor (116) Select Hide
Finance Project (117) Select Hide

Product type 5##

Company code TA##

2. Verify customization by entering a trade using the product type 5## and transaction type
100 (purchase). Verify that the fields and tabs are hidden.
Field Name Value
Company code TA##

Product type 5##
Transaction type 100
Partner BP##
Amount 5M EUR
Interest rate 2.6%
Term 1 months starting from today

Unit 5
Solution 25
Business Example
You are not using certain fields and tabs in financial transactions and would like to hide
specific fields and tabs.
Dependencies
This exercise uses the product type 5## created in an earlier exercise.
Note:
1. Hide the Memos and Partner Assignment tabs and the Authorization Group, Guarantor,
and Finance Project fields.
Table 64: Field Selection


Table 65: Tabs

Memo / Notes tab (86) Select Hide

Partner Assignment tab (95) Select Hide
Authorization Group (109) Select Hide
Guarantor (116) Select Hide
Finance Project (117) Select Hide

Product type 5##

Company code TA##


Settings → Transaction Management → Define Field Selection.
b) To create a field selection definition, by choose the Field selection definition folder, and
choose New Entries.
c) Enter the data provided in the table, Field Selection.
d) Select the tab to the left of the data entered in step c, and to define the field selection,
choose Field Selection.
e) Verify that all of the tabs in the table, Tabs, are listed.
f) Choose Back.
g) Select the tab to the left of the field status definition, double-click the Assignment to
product types folder, and choose New Entries.
h) Enter the data provided in the table, Product Type.
i) Choose Save.
2. Verify customization by entering a trade using the product type 5## and transaction type
100 (purchase). Verify that the fields and tabs are hidden.
Field Name Value
Company code TA##

Product type 5##
Partner BP##
Amount 5M EUR
Interest rate 2.6%
Term 1 months starting from today
a) In your company code (TA##), choose the Create Financial Transaction tile. Use the
business partner you created.
b) Enter the data provided in the table.

It is not necessary to save the trade.

Lesson: Entering Trade Field Selection
LESSON SUMMARY


Unit 5
Lesson 3
Establishing the Cash Management Integration
LESSON OBJECTIVES
Assign Planning Levels
Figure 406: Assign Planning Levels
Business Example
Your company is using both SAP’s Cash Management functionality as well as Transaction
Manager. You are required to make the settings on SAP to reflect all Transaction Manager
transactions in the cash position app.
Tasks to perform in that area are:
● Assigning planning levels
● Configuring update types for Cash Management
● Cash management and forecast in the application

Figure 407: Integration with Cash Management
Animation: Integration with Cash Management

For more information on Integration with Cash Management, please view the
animation in the lesson Establishing the Cash Management Integration, online in
Because SAP is an integrated system, real-time updates to the cash position report of
Treasury transactions is easy.
The steps to integration of Transaction Manager and Cash Management are the following:
● Create planning levels in customizing
● Assign planning levels to product types in customizing
● Create trades in the application side processing
● Real-time update of the cash position report in Cash Management
Figure 409: Assign Planning Levels
The planning levels and reporting structure of the daily cash position are defined in Cash
Management. The assignment of a planning level byproduct type is done within Transaction
Manager customizing.

Lesson: Establishing the Cash Management Integration
Before planning levels can be assigned, they must be defined using the customizing path:
Financial Supply Chain Management → Cash and Liquidity Management → Cash
Management → Planning Levels and Planning Groups → Define Planning Levels.
The planned cash flows of the Transaction Manager are displayed in the cash position as the
system knows relatively early in the process which house bank and account these cash flows
are processed through. If a house bank account is not specified in the financial transaction,
the cash flows will continue to be shown in the cash position, but they are usually assigned to
a different planning level (Level (bank unknown) column), as shown above. In other words, in
this customizing step, different planning levels can be assigned based on if the bank account
details are specified within the financial transaction and if the bank account details are not
specified within the financial transaction.
To assign planning levels, use the customizing path: Financial Supply Chain Management →
Treasury and Risk Management → Transaction Manager → General Settings→ Link to Cash
Management → Assign Planning Levels.
Notice that this customizing is done by company code.
Once you have defined the planning level, you must define in Customizing which flows you
want to update into SAP Cash and Liquidity Management. For example, flows related to
valuations are not supposed to appear in SAP Cash and Liquidity Management. In this
context, you must distinguish whether the flow originates from transaction management or
position management. For flows that originate from transaction management, you must
define during the definition of the flow type whether they are relevant to cash management.
This is described in the Define Flow Types section of this course.
Figure 410: Define CM Period
For securities, there are additional customizing settings required before a cash management
integration is available. The forecast period or CM period specifies for how many half-yearly
terms the cash flow is to be generated in the future. Making this setting improves the
performance, because for securities with maturity dates out 20+ years, cash flows are then
generated only for the specified period. Processes requiring the entire cash flow, such as
valuation or net present value calculation, are not affected by this setting.

To make these settings, follow the customizing path Financial Supply Chain Management →
Treasury and Risk Management → Transaction Manager → Securities → Master Data →
Product Types → Define Company Code-Dependent Settings for the Product Type.
Notice that this customizing is done by company code.
Specify Update Types for Cash Management
Figure 411: Specify Update Types for Cash Management
Animation: Specify Update Types for Cash Management

For more information on Specify Update Types for Cash Management, please
view the animation in the lesson Establishing the Cash Management Integration,
For flows that originate from position management, you can use the Specify update types for
Cash Management activity in Customizing, which enables you to mark update types as
relevant to cash management by settings the CM relevant indicator. You can find this activity
next to the definition of the planning levels.
To assign planning levels, use the customizing path: Financial Supply Chain Management →
Treasury and Risk Management → Transaction Manager → General Settings → Link to Cash
Management → Specify Update Types for CM.
After having finished the relevant customizing settings, all newly created financial
transactions are automatically updated in the daily cash position.
From the cash position app, the trade related cash flows are reflected. If there are questions
relating to the trade cash flows while viewing the cash position app, drilldown to the trades is
possible.
The cash position app reflects cash flows by value date.
The following cash flow information can be included in the daily cash position:
● Planned cash flows from financial transactions
● Posted cash flows on bank interim account
● Posted cash flows on payment request account

Lesson: Establishing the Cash Management Integration
● Bank account balances from bank account statement
LESSON SUMMARY


Unit 5
Lesson 4
Mirroring of Trades
LESSON OBJECTIVES
Mirroring of Trades
Figure 413: Trade Mirroring Overview
When companies reach a more complex size, they often implement intercompany financing
processes to facilitate borrowing from surplus cash entities and lending to the deficit cash
entities. The nature of these transaction is that one side is a buy and the other side is a sale,
and the two trades exactly offset each other in consolidations.
You can use mirror transactions to create financial transactions in one company code and
automatically mirror it in another company code. This is useful if several companies within a
corporation or subsidiaries of a company have their own company codes and conduct
financial transactions with each other. Mirror transactions require that both companies be
represented in the same client with separate company codes, and that both companies be
entered as business partners in the company code of the other company.
You can mirror financial transactions only in a defined direction-that is, always starting from
the same company code. When creating a financial transaction in this company code, another
financial transaction is automatically created with opposite payment flows in the company
code of the counterparty. This is what is meant by mirroring.
The advantage of using the mirroring configuration is that the system will create the opposite
side of the trade automatically. The eliminates the risk of human error of entering in the
offsetting trade manually. The mirroring configuration saves time and reduces risk.
The prerequisites to using the mirroring customizing is that both company codes reside in the
same SAP client, and that both companies are represented in SAP as a company code, and a
business partner can be created for each company.

Mirroring Configuration Steps
Figure 414: Mirroring Trade Customizing
Learn on the next pages about the customizing steps for Mirroring Trades.
Figure 415: Mirroring Trade Customizing
Animation: Mirroring Trade Customizing

For more information on Mirroring Trade Customizing, please view the animation
in the lesson Mirroring of Trades, online in the SAP Learning Hub.
The slide above outlines the steps to configure mirroring and what is happening at each step.
This configuration drives the creation of the mirrored intercompany loan trade.
Before getting started, on the mirroring configuration, the configuration for the buying side
and selling side of the intercompany loan should be completed. This includes the
configuration of the product types, transaction types, flow types, condition types, etc.
described in the previous unit.
With the mirroring configuration, when creating a financial transaction in this company code,
another financial transaction is automatically created with opposite payment flows in the
company code of the counterparty. For example, if you enter the investing side of an
intercompany loan, the SAP system automatically creates the mirror image of the investment
side by creating the borrowing side of the intercompany loan. In addition, when the mirroring
functionality is used, the SAP system automatically links the intercompany loans using the
SAP standard MIR reference category. In addition, when displaying or changing a mirrored
financial transaction, you receive a message informing you that a mirror transaction exists for
the transaction.

Lesson: Mirroring of Trades
The mirroring reduces the amount of manual work when entering the intercompany trades.
Keep in mind that to keep the two sides of the intercompany loan the same, any processing of
the trades after creation must be done to both the lending and borrowing sides of the
intercompany loan.
The mirroring functionality is available for the following financial instruments: fixed-term
deposit, deposit at notice, cash flow transaction, interest rate instrument, foreign exchange,
and foreign exchange swap.
Figure 417: Maintain Relevant Product Types and Transaction Types
The mirrored financial transactions are always customized only in a defined direction-for
example, always starting from the investing entity or always starting from the same company
code.
In the Maintain Relevant Product Types and Transaction Types configuration, shown above,
you specify the characteristics of the leading or initiating company code. This configuration
for mirroring transactions drives starts the mirroring process. If the combination of inputs in
this table matches a trade, the mirroring process moves to the next configuration step. In
other words, the data in this customizing step defines the company codes, product types,
transaction types, business partner and relevant activities should be considered for mirror
initiation.
The fields in this configuration table are company code, product type, transaction type, and
business partner of the trade. Activity 01 is for create. Activity Category 10 is for Contract,
which represents the status of the trade just created.
The Maintain Relevant Product Types and Transaction Types configuration node is found in
the customizing menu path Financial Supply Chain Management → Treasury and Risk
Distribution of Mirror Transactions → Map Product Types and Transaction Types.
Figure 418: Map Product Types and Transaction Types

In the next configuration step, the system maps from the initiating side of the trade to the
mirrored side of the trade (for example, from the lending side of the trade to the borrowing
side of the trade), by matching the entries using the MetaText field. The entries in this
customizing steps are used to create the mirrored transaction.
When moving from the last configuration table to this configuration table, the system is
determining the product type and transaction type of the mirrored trade by matching on the
MetaText field.
For our example, when you create an initiating trade in company code TA01 with product type
55G and transaction type 100, the system finds an entry in this table with Direction Incoming
and captures the MetaText INT. RATE INSTRUMENT INVEST. The mirroring program then
finds a matching entry in this table based on the MetaText found and a Direction of Outgoing.
The system finds the entry in the table of company code 1710, product type 55G, and
transaction type 200, which are then the characteristics of the mirrored trade that it will
create.
The Map Product Types and Transaction Types configuration node is found in the
customizing menu path Financial Supply Chain Management → Treasury and Risk
Distribution of Mirror Transactions → Map Product Types and Transaction Types.
Figure 419: Process Incoming Data
This system determines further characteristics of the mirrored trade being created. The SAP
programs query the configuration to determine further parameters of the mirrored trade
being created. Here you maintain the configuration for processing incoming data from the
perspective of the company code of the mirrored trade.
The Process Incoming Data configuration node can be found under the customizing menu
Manager → Money Market → Transaction Management → Distribution of Mirror Transactions
→ Process Incoming Data.
Figure 420: Assign Company Code to Partner
As shown above, the SAP programs query the Assign Company Code to the Partner
configuration table to determine the business partner of the mirrored trade to create. This
configuration step links a company code to a business partner. This must be a one-to-one

Lesson: Mirroring of Trades
relationship between company code and business partner. At this point, the system has all
the information needed to create the mirrored trade.
Under the Assign Company Code to Partner configuration node found using the customizing
menu path Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → Money Market → Transaction Management → Distribution of Mirror
Transactions → Assign Company Code to Partner.
Figure 421: Define Number Ranges for Linking Transactions
Animation: Define Number Ranges for Linking Transactions

For more information on Define Number Ranges for Linking Transactions, please
view the animation in the lesson Mirroring of Trades, online in the SAP Learning
Hub.
When the mirroring functionality is used, the SAP system automatically links the
intercompany loans using the SAP standard MIR reference category. There is a number range
associated with each reference category.
This can be found in the customizing menu path Financial Supply Chain Management →
Treasury and Risk Management → Transaction Manager → General Settings → Transaction
Management → Define Number Ranges for Linking Transactions. In this transaction, in the
Reference Cat. field, enter MIR and click the change Intervals button.
Resolving Mirroring Errors
Figure 423: Trouble Shooting Mirroring Errors

After entering the mirroring configuration, test to make sure the mirroring configuration is
correct. Often the cause of not getting a mirrored trade is that the standing instructions are
not complete for the mirrored trade. An quick way to validate that all the configuration and the
standing instructions for the mirrored trade are complete is to enter the offsetting trade
manually. After the offsetting trade can be entered manually successfully, test the mirroring
by entering an initiating trade from the defined direction. When displaying or changing a
mirrored financial transaction, you receive a message informing you that a mirror transaction
exists for the transaction.
How to Create an Intercompany Loan (Mirrored Trades)
Simulation: How to Create an Intercompany Loan (Mirrored Trades)

For more information on How to Create an Intercompany Loan (Mirrored
Trades), please view the simulation in the lesson Mirroring of Trades online in the
SAP Learning Hub.
How to Reference (Link) a Trade
Simulation: How to Reference (Link) a Trade

For more information on How to Reference (Link) a Trade, please view the
simulation in the lesson Mirroring of Trades online in the SAP Learning Hub.
LESSON SUMMARY

Unit 5
Learning Assessment
1. Which of the following are options for how variable rate interest rates can reflect in trades
and cash management?
X A Reflect with a zero amount.
X B Reflect using the last rate used either manually or automatically.
X C Reflect using the highest rate entered in SAP for the specific reference interest
rate.
2. There are settings indicators for variable interest rate, commodity prices, and currency
prices in the company code additional information settings.
X True
X False
3. At which levels can the field status of a trade be driven?

X A Product type
X B Transaction Type
X C Activity category, for example, contract, contract settlement
X D Function, for example, Settlement, Reversal
4. The planning level assignment is the link between Transaction Manager and the cash
position report.
X True
X False

5. The planning level customizing can be found in the IMG under Transaction Manager and
under Cash Management.
X True
X False
6. Which of the following are advantages of mirroring of trade?

X A Mirroring of trade helps when subsidiaries of a company conduct financial

transactions with subsidiaries of another company.
X B Mirroring of trade helps when the client wants to understand and configure the
company code additional settings.
X C Mirroring of trade helps as the system creates the opposite side of the trade
automatically.
X D Mirroring helps in defining and assigning field selection to appropriate level.

UNIT 6 Back Office Functions
Customizing
Lesson 1
Configuring the Correspondence Monitor 432
Exercise 26: Correspondence Activities 453
Exercise 27: Execute Correspondence 463
Lesson 2
Using the Payment Program 473
Exercise 28: Execute the Treasury Payment Run 493
Lesson 3
Using the Trade Repository 507
UNIT OBJECTIVES
● Provide an overview of the correspondence monitor

● Configure the correspondence monitor
● Maintain correspondence master data settings
● Use the correspondence monitor
● Understand the payment programs
● Configure the treasury payment program
● Execute the treasury payment program
● Connect to banks
● Know the process of implementing SAP Multi-Bank Connectivity
● Articulate the benefits of implementing SAP Multi-Bank Connectivity
● Understand the trade repository
● Understand terms such as ESMA, Dodd-Frank legislation, and trade repository
● Describe the process of getting the required data to a trade repository
● Check the use of configuration for the trade repository

Unit 6
Lesson 1
Configuring the Correspondence Monitor
LESSON OBJECTIVES
Correspondence Monitor Overview
Figure 426: Internal and External Correspondence
The central tool for correspondence is the Correspondence Monitor, from which you can start
virtually any correspondence-relevant function and monitor correspondence. The
Correspondence Monitor is the one location to go for anything correspondence related.
The Correspondence Monitor is an open, flexible framework to support automated processes
with straight-through processing. PDF forms, SAPscript forms, or files in any format are
created and can then be sent as an email, fax, or printout. Straight-through processing is also
available for incoming messages.
Below are examples of what can be provided by the Correspondence Monitor:
● An overview of the current processing correspondence status with symbols.

Lesson: Configuring the Correspondence Monitor
● A function for setting the counter-confirmation status to matched directly from the
monitor.
● A function that allows you to execute planned correspondence directly from the monitor.
● The option of repeating correspondence that has already been generated. This function
allows you to restart a correspondence run that failed, for example, for a particular
selection of correspondence (the toner ran out in the printer).
● You can use the Correspondence function to generate specific letters for the financial
transactions managed in the system.
● You can send this correspondence directly from the system by Fax or e-mail or by SWIFT
files or IDocs (in the Money Market, Foreign Exchange, and Trade Finance area) or print it
out.
● This correspondence can be used as a form of internal documentation for financial
transactions (dealing slips) as well as for comparing the financial transactions concluded
with business partners using external correspondence that can also be counter-confirmed.
The settings for correspondence are applicable across the different SAP treasury modules.
The purpose of correspondence is the generation of a confirmation of a transaction with
either an external counterparty (possibly requiring matching or counter-confirmation) or an
internal counterparty (for notification and record-keeping). Of particular relevance in
Treasury management are:
● SWIFT Confirmation
● Textual Formatted Confirmations
SAP supplies standard forms that can be used for correspondence. The correspondence
function provided by SAP is freely definable, and can also be assigned with any other custom
made forms. In some cases, these standard forms will need to be adjusted to meet the
specific business requirements. In such cases, the SAP delivered form should be copied, and
changes should be made to the copy as per the specific requirements. The new form should
then be assigned in the correspondence configuration for the transaction activity. New forms
can be created using forms editor, by copying the standard form and then assigning it in the
configuration activities Define Communication Profile and Define Correspondence Activities.
The trades can be internal or external trades. For example, trade tickets with the payment
dates and bank account information can be generated on SAP for intercompany loans just as
the trade tickets can be sent for investments made with external brokers.
Correspondence serves to document and match concluded financial transactions.
You can define correspondence in different formats (such as SWIFT formats, dealing slips,
and confirmations) using correspondence classes. By performing a correspondence run, you
can confirm all the financial transactions you have concluded with a business partner in a
given period. You can print the generated data or have it sent directly from the system by fax.
You can also use e-mail and IDocs. To send e-mails, you need to set up the communication
interface SAPconnect. For money market and foreign exchange transactions, you can
generate SWIFT files MT320 (fixed-term deposits) and MT300 (forex).
You can control the various correspondence classes independently of the business partner.
The system also keeps a record of the confirmation status in the transaction. This includes
information about when the confirmation was sent/received, the relevant activity, the user,
the form used, and the output type of incoming or outgoing confirmations.

Unit 6: Back Office Functions Customizing
You can control when correspondence is generated in Customizing for product and
transaction types and activities. You can also specify whether correspondence should be
generated automatically when a transaction is created, changed, or reversed (that is, as soon
as the transaction is saved). Correspondence that has been generated is stored in the
financial transaction data.
Correspondence is sent to the business partner's standard address by default. If you want to
use a different address for the partner, specify this in the Alternative Address field.
Figure 427: Overview of Correspondence Monitor
Animation: Overview of Correspondence Monitor

For more information on Overview of Correspondence Monitor, please view the
animation in the lesson Configuring the Correspondence Monitor, online in the
SAP Learning Hub.
The correspondence process can be split into two sub-processes, as shown above:
● Internal correspondence process (Dealing Slip):
1. Internal communication between front, middle, and back office
2. Documentation
3. Internal check of key information, for example, payment details and product type
● External correspondence process (confirmation):
1. Get a counter confirmation from, for example, bank or business partner
2. External check of key information, for example, conditions and amount
3. To fulfill external and internal requirements on processes and documentation.
The trade correspondence can be configured to have the following formats:

● Fax (Fax settings could be defined in customizing)

● Printer (Printer settings could be defined in the customizing)
● IDoc (internal communication type between two SAP systems)
● Swift (for example, MT300 and MT320)
● E-mail
Figure 429: Treasury Process Flow
Animation: Treasury Process Flow

For more information on Treasury Process Flow, please view the animation in the
lesson Configuring the Correspondence Monitor, online in the SAP Learning Hub.
Treasury trades are executed. Correspondence for the trades can be sent from SAP for the
specified trades.
Based on the customizing settings, a correspondence object can be created at the following
times:
● When you create or change a financial transaction
● When you create a securities account transfer
● Manually from the Correspondence Monitor
When the correspondence is generated, the administrative and business-relevant data is

included in/on the correspondence object.

Figure 431: Correspondence Monitor Steps
Animation: Correspondence Monitor Steps

For more information on Correspondence Monitor Steps, please view the
SAP Learning Hub.
The correspondence monitor supports straight-through processing from deal capture to

error handling and automatic matching.
For better usability, three views are made available in the Correspondence monitor:
● Standard view: In this view, all the correspondence objects selected based on the selection
parameters are displayed in one single list.
● Assignment view: In this view, the selected correspondence objects are displayed divided
in two lists. The top half shows all the COs already assigned to a deal and the lower half
shows all the COs yet to be assigned to a deal. It is possible to choose an unassigned CO in
lower half and assign it to the deal to which any CO in the upper half is assigned to.
● Matching view: In this view, only the COs selected based on selection parameters which
are relevant for matching are displayed. The COs relevant for matching are divided based
on their direction (i.e. Incoming or outgoing). The outgoing COs relevant for matching (i.e.
status 'Delivered' and 'Matched') are shown in the upper half and the incoming COs
relevant for matching (i.e. status 'Received' and 'Matched') are shown in the lower half. It is
possible to choose COs in both the halves and match them.

Figure 433: Correspondence Monitor
The application for generating the correspondence is the Correspondence Monitor. The
Correspondence Monitor is the dashboard to all the processing and tracking related to
Transaction Manager correspondence, e.g. confirmations, dealing slips, SWIFT messages,
etc. Correspondence objects can be displayed in the Correspondence Monitor (transaction
code FTR_COMONI, or Process Correspondence tile). A correspondence object is the internal
representation of the correspondence data. The Correspondence Monitor offers many
functions for working with correspondence objects, such as a message preview, message
sending, attaching files to the correspondence object, and memo creation.
The outgoing message is always stored in the document management system when it is sent
and can then be displayed at any time.
When you receive a message that can be processed electronically (e.g., a Receipt file in
SWIFT format), the message can be imported from the application server folder defined in
customizing. Incoming messages are also stored in the document management system.
Mapping is then used to transfer the external structure of the message to the internal
structure of the correspondence object, and a correspondence object is created. For
messages received by fax, a correspondence object can be created manually, and the fax can
be attached to the correspondence object as an attachment.
Matching serves to identify correspondence objects that belong together, as well as indicating
if the terms of trade match the details received.
Both outgoing and incoming correspondence objects for a transaction can set the
correspondence status of the financial transaction. In the case of incoming correspondence,
it is also possible to copy additional data into the transaction.
PDF forms, SAPscript forms, or files in any format are created and can then be sent as an
email, fax, or printout. Straight-through processing is also available for incoming messages.
Messages that are sent and received are stored and can be displayed unchanged at any time.
An outgoing message may use a PDF or SAPscript form to display the content. SAP standard
provides the two standard forms in the sample customizing that can be copied to meet
customer specific requirements. Depending on the contract type and product type, text
modules are combined within the form logic and filled with data from the financial transaction.

Correspondence General Settings

Correspondence Specific Terms
Figure 434: Correspondence General Settings
Animation: Correspondence General Settings

For more information on Correspondence General Settings, please view the
SAP Learning Hub.
First, let's define some correspondence specific terms.

A correspondence object is the internal representation of the administrative and business-
relevant correspondence data. Functions are executed with the correspondence object, and it
has its own status.
A communication channel describes how something is sent, e.g. email, fax.
The correspondence class indicates why a message is sent, e.g. money market confirmation.
The correspondence recipient type answers the question of to whom or from whom the
message is sent.
A correspondence activity answers the question of when the outgoing correspondence is
created.
The format metatype answers the question of which type of message is sent, e.g. form or
SWIFT message.

The definitions specified above are technical attributes, which are combined together in a
technical profile known as the communication profile. This communication profile controls
the creation, sending, and receipt of messages.
Business Partner Group
Figure 436: Define Business Partner Group
Business partners with similar correspondence requirements are grouped into business
partner groups. The advantage of doing so is that this allows business partners with the same
properties to be grouped together.
In this customizing step, you can make the required settings for Business Partner Group,
which defines the correspondence related business settings for the group. This differentiates
the business attribute definitions- like counter confirmation requirement, matching
requirement, and others- from that of technical attributes. The business partner group is later
assigned to the business partner (application setting). In our case we used define just one
default business partner group - BPG_DEFAULT.
Set the indicator to activate the business partner group.
Large Banks like Bank of America or Deutsche Bank Group have a lot of subsidiaries
worldwide. In terms of an efficient limit management it is useful to be able to analyze and limit
risks for a whole group of affiliated business partners.
To define business partner groups, use the customizing path: Financial Supply Chain
Settings→ Correspondence → General Settings → Define Business Partner Group.
Correspondence Recipient Types
Figure 437: Define Correspondence Recipient Types
The correspondence recipient type indicates to whom or from whom the message is sent.
This is the recipient in the case of outgoing messages, and the sender in the case of incoming
messages.
The correspondence recipient type is mainly used to differentiate between internal and
external recipients/senders. It is also a controlling parameter while creating outgoing/
incoming messages. You must assign a business-partner role to the correspondence
recipient type. The definition takes place in connection to the different Business Partner roles:
● COUNTERPARTY: Counterparty

● DEPOSITORYBANK: Depository Bank

● GLOBALCUSTODIAN: Global Custodian
● GUARANTOR: Guarantor
● INTERNAL: Internal
● ISSUER: Issuer
In a specific financial transaction or securities account, a business partner must then exist in
this role.
Set the Internal indicator if correspondence is to be created for an internal party involved.
It might be necessary to define more than one recipient/sender type for one recipient/sender
if you want to use different communication channels (such as e-mail, fax, and file).
To define correspondence recipient types, use the customizing path: Financial Supply Chain
Settings→ Correspondence → Messaging Interface → Define Correspondence Recipient
Types.
Correspondence Classes
Figure 438: Define Correspondence Classes
The correspondence class indicates why a message is sent.

The correspondence class is related to the business transactions of the available message
formats, such as SWIFT messages. Correspondence classes are delivered by SAP, but can be
enhanced by you. New correspondence classes should be added if any new transaction type
(with new format, partner settings, status relevance, and so on) was defined.
To define correspondence classes, use the customizing path: Financial Supply Chain
Settings→ Correspondence → Messaging Interface → Define Correspondence Classes.

Assign Attributes for Business Partner Groups
Figure 439: Assign Attributes for Business Partner Groups
The figure shows the configuration step of assigning attributes to business partner groups.
The attributes like auto correspondence, release required, status relevance, counter
confirmation requirement, reconciliation, auto completion, update of external reference, etc.,
are assigned by business partner group, correspondence class, and recipient/sender type.
If the StsRelev. Indicator is set, the correspondence object is relevant to deal (trade) status
management.
If the AutoCorr indicator is set, the correspondence is executed automatically whenever the
trade is saved.
The following are the business attributes specified in this step:
● Automatic correspondence required or not.
● Counter confirmation from the counter party required or not.
● Whether the correspondence object is deal-status relevant.
● Release required or not before send. The release flag will determine whether the release
tool has to be called or not before sending the correspondence object.
● Reconciliation required or not.
● Whether a correspondence is relevant to be automatically marked as completed.
● Whether the information about external reference and contact person in the deal has to be
updated with the information received in a status relevant incoming correspondence.
Auto correspondence (only applicable for outgoing side): The correspondence is executed
automatically once a transaction is created.
Release required (only applicable for outgoing side): The release tool is called before send.

Status relevance (outgoing and incoming side): The correspondence object would be relevant
in deal status management.
Counter-confirmation requirement (only applicable for outgoing side): Is a confirmation from
the counterparty required for the outgoing correspondence objects.
Reconciliation (only applicable for incoming side): Should an incoming correspondence
trigger the automatic reconciliation.
Auto completion (outgoing and incoming side):
If the flag is set, the effect will be as follows:
● For incoming correspondences: It will be automatically marked as completed as soon as it
is matched to an outgoing correspondence.
● For outgoing correspondences not requiring counter confirmation: it will be automatically
marked as completed as soon as it is delivered.
● For outgoing correspondence requiring counter confirmation: it will be automatically
marked as completed as soon as it is matched and counter confirmed, that is matched to a
status-relevant incoming correspondence.
Update of external reference (only applicable for incoming side): Shall the information about
the external reference and the contact person in the deal be updated with the information
received in a status-relevant incoming correspondence.
Physical Delivery Flag (only applicable for incoming side): Indicates whether an incoming
correspondence is relevant for confirming the physical delivery of a security transaction
→ Correspondence → General Settings → Assign Attributes for Business Partner Groups.
Define Number Ranges for CO ID
Figure 440: Define Number Ranges for CO ID
Each correspondence gets a key number for the identification in the correspondence monitor.
In this customizing step, you define this number range.
Settings→ Correspondence → General Settings → Define Number Ranges for CO ID.
Sequential numbering is also required both for correspondence objects and for matching. You
define the relevant number ranges in customizing under Financial Supply Chain Management
→ Treasury and Risk Management → Transaction Manager → General Settings →

Correspondence → General Settings → Define Number Ranges for CO ID or under

Correspondence → General Settings → Define Number Ranges for Match ID.
Internal Recipients
Figure 441: Define Internal Recipients
Internal recipients are recipients within your company and may be, for example, individual
users, groups of users (a department), or even a printer within a department. These are the
recipients, in addition to transaction counterparties, that should receive a correspondence for
transactions. The internal recipients would also be used for internal financial transactions.
Settings→ Correspondence → General Settings → Define Internal Recipients.
Correspondence Messaging Interface
Figure 442: Correspondence Messaging Interface
See on the next slides how you would define the needed communication channels for such
correspondence.
Figure 443: Define Communication Channels
A communication channel describes how something is sent. This defines the medium of the
transmission of a correspondence message. It controls the used storage and called
middleware to send the message to the current recipient. Using the correspondence class
and correspondence recipient type, the channel controls the format of a message.

Cross-client settings for communication channels are predefined and can be used for creation
of confirmations and dealing slips. For Transaction Manager, in standard, the correspondence
can be created as a Fax, e-mail, print, or as a SWIFT file. For the use of the IDoc format the
SAP standard needs to be adapted, based on the company specific requirements.
The response Flag indicates if ACK and NACK messages will be received from the network.
Depending on the network, e.g for those files that are to receive ACK and NAK messages, you
can receive technical responses from the processing network. If the network provides such a
service, the status of the correspondence objects is set to Awaiting acknowledgement after
the correspondence has been sent.
To define communication channels, use the customizing path: Financial Supply Chain
Settings→ Correspondence → Messaging Interface → Define Communication Channels.
Figure 444: Define Formats
Formats are predefined in SAP. In connection to the communication channel, different

formats are used. In our example, we will use the standard SAP Script file for creation of a
confirmation.
The format answers the question of what is sent. It represents the syntactical and semantic
structure of a message.
The formats included with the standard delivery use the mapping that is delivered as
standard. Corrections or changes to the delivered formats can be made to this mapping in
terms of both the mapping rules and the mapping methods. When doing this, you should
always define your own formats (copy the standard format) rather than modifying the default
formats. For example, to create a custom MT300 format, copy the standard format to
ZMT300, and then make changes to ZMT300.
Formats are later assigned to the profiles based on correspondence class, recipient type and
communication channel.
To define formats or view the SAP standard formats, use the customizing path: Financial
General Settings→ Correspondence → Messaging Interface → Define Formats.

Figure 445: Assign Correspondence Class for Inbound Process
The correspondence class indicates why a message is sent.

In this customizing step, make the required settings for assigning a correspondence class for
an inbound process. The file format that came as a counter conformation from the external
business partner can differ from the send file format.
Note, that basically for bank and insurance the swift format is used for counter confirmation.
SWIFT is the abbreviation of "Society for Worldwide Interbank Financial Telecommunication".
This company provides a network that enables financial institutions worldwide to send and
receive information about financial transactions in a secure, standardized and reliable
environment. In connection to the product different swift formats are used. The mapping of
the inbound correspondence can be done automatically or manually. If an automatic process
is required, additional customizing settings are necessary.
To assign the correspondence class for inbound process, use the customizing path: Financial
General Settings→ Correspondence → Correspondence Messaging Interface → Assign
Correspondence Class for Inbound Process.
Figure 446: Assign Formats

In this customizing step, you assign formats to the profiles based on correspondence class,
recipient type, and communication channel. In this step, you assign a message format, e.g.
SWIFT message type, SAP script form, to a profile, correspondence class, recipient type, and
communication channel.
To assign formats, use the customizing path: Financial Supply Chain Management →
Treasury and Risk Management → Transaction Manager → General Settings →
Correspondence → Messaging Interface → Assign Formats.
Communication Profiles
Figure 447: Define Communication Profiles - Channel Assignment
The screen above shows the connection between the different correspondence customizing
settings.
After the technical attributes are defined, they are merged together in a technical profile
known as the communication profile. This communication profile controls the creation,
sending and receipt of messages. The communication profile is assigned to a group of
business partners.
The following steps are required in order to create a communication profile:
1. Name the communication profile - You must assign a name to the communication profile.
2. Communication channel assignment - Next, assign a communication channel (how

something is to be sent) to the correspondence class (why it is to be sent) and the
correspondence recipient type (to whom it is to be sent). To do this, select the required
communication profile and click the Channel Assignment entry.
3. Format metatype assignment - The next step is to define which format metatype (which
type is to be sent) is to be used for a communication channel (how it is to be sent).
4. Channel-dependent attributes - You also need to specify the channel-dependent

attributes for a communication channel (how something is to be sent). To do this, select a
channel assignment and choose the Channel-dependent Attributes entry.
5. Format-dependent attributes - Lastly, you also need to define format-dependent

attributes. These include, in particular, the external format for messages exchanged in file
format.

Figure 448: Define Communication Profiles - Assigned Format Metatypes
The business partner group and communication channel, which are combined together in a
technical profile known as the communication profile. This communication profile controls
the creation, sending, and receipt of messages.
You can use this function to assign attributes to the business partner, the correspondence
class, and the sender/recipient type. You can assign the following attributes:
● Whether automatic correspondence is necessary or not.
● Whether counter confirmation of the counterparty is necessary or not.
● Whether the correspondence object is relevant to the business status or not.
● Whether correspondence has to be released before sending. The release indicator
specifies whether or not the release tool has to be called before the correspondence object
is sent.
● Whether reconciliation is necessary or not.
● Whether correspondence can be automatically marked as completed or not.
● Whether or not information about the external reference and the contact person for the
transaction has to be updated using information from incoming correspondence that is
status relevant.
In the slide above, the Communication Profile PR_DEFAULT is defined, which will be assigned
with the business partner group to business partners on the application side.
In the Communication Profile PR_DEFAULT, the correspondence class of DEAL_MM, recipient
type COUNTERPARTY (external counterparty), and communication channel file defined. We
can see in the communication profile, the format is an MT320 formatted SWIFT file. In this
case, when the correspondence is generated, an MT320 file will be generated that contains
the details of the trade. This file would then be sent to the external counterparty of the trade.

To define communication profiles, use the customizing path: Financial Supply Chain
Settings→ Correspondence → Messaging Interface → Define Communication Profiles.
Figure 449: Define Communication Profiles - Format dependent attributes
In the slide above, the Communication Profile PR_DEFAULT is defined, which will be assigned
with the business partner group to business partners on the application side.
In the Communication Profile PR_DEFAULT, the correspondence class of DEAL_MM, recipient
type INTERNAL (internal recipient), and communication channel email defined. We can see in
the communication profile, the format is the TR_F_AFM_CORR_MM form. In this case, when
the correspondence is generated, an email will be sent that contains the details of the trade,
as defined by the layout of the TR_F_AFM_CORR_MM form.

Figure 450: Define Communication Profiles
Animation: Define Communication Profiles

For more information on Define Communication Profiles, please view the
SAP Learning Hub.
In the slide above, shows the connection between the different correspondence related
elements.
Figure 452: Automatic Settlement Status
There is an Automatic Settlement for Counter-confirmation indicator at the define transaction

type step. If this indicator is selected, the financial transactions are automatically settled
when the counter-confirmation is received and matched for the correspondence sent.

If this flag on the transaction type definition is set, the deal status will automatically be set to
settlement by the system whenever the correspondence object for a deal was matched. This
could be used for straight through process if wanted by the customer.
The define transaction types configuration step can be found in the customizing menu by
following the path Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → Money Market / Foreign Exchange / Securities / Listed Derivatives /
OTC Derivatives / Trade Finance → Transaction Management → Transaction Types → Define
Transaction Types.
Correspondence Activities
Figure 453: Define Correspondence Activities
The correspondence activity configuration determines when (at which business transaction)
the outgoing correspondence is created.
You assign each correspondence function code to a product type for an activity and also for a
recipient type. This configuration is entered by company code.
This is a required step for correspondence object creation for a money market contract type.
The correspondence object is created for a financial transaction, based on the
correspondence class and recipient type assigned for that product type, and for the
transaction type for an activity.
You can also specify if the recipients for the correspondences need to be derived based on the
partner assignments made in the deal or based on the BAdI implementation (method
FILL_RECIPIENT_AUTO_CREATION of BAdI BADI_TCOR_FILL) by selecting the
"RefPartnerAssgn" indicator.
Via the activity category, the relevant process information can be included in the
correspondence process.
The following activity categories are supported for money market contracts:
● 05 Offer
● 07 Simulation

● 10 Contract
● 11 Rollover
● 20 Contract Settlement
● 21 Rollover Settlement
For example, if correspondence is to be generated for both Contract Settlement and Rollover
Settlement, two entries should be entered for the same product type, transaction type,
recipient, correspondence type combination.
To define correspondence activities, use the customizing path: Financial Supply Chain
Settings→ Correspondence → Correspondence Activities → Money Market. There are
corresponding customizing nodes for Foreign Exchange, Derivatives, Securities, and Trade
Finance.
Figure 454: Correspondence Planned Records
Animation: Correspondence Planned Records

For more information on Correspondence Planned Records, please view the
SAP Learning Hub.
The diagram above shows the logic of determining correspondence planned records in
Simulation: Correspondence Activities

For more information on Correspondence Activities, please view the simulation
in the lesson Configuring the Correspondence Monitor online in the SAP Learning
Hub.


Unit 6
Exercise 26
Business Example
After finishing the definition of the main process for product type 5##, you can define the
back-office processing. Define correspondence activities for product type 5##.
Dependencies
● This exercise uses the Business Partner BP## that was created in Exercise 1.
● This exercise uses product type 5## and transaction type 100.
● Ensure that the flow types were assigned to product type 5## and transaction type 100.
● Ensure that the condition types were assigned to product type 5## and transaction type
100.
● Ensure that the general valuation class was assigned to product type 5## and transaction
type 100.
Note:
1. Activate the correspondence process for product type 5##. Create a confirmation after
saving the contract.
Table 67: Correspondence Activities 100

Field Name Value
Product category 510
Product type 5##
Activity category 10 ’Contract’
Recipient/Sender type COUNTERPARTY
Correspondence class DEAL_MM
Internal Recipient DEPT_PRINT
2. Activate the correspondence process for product type 5## with transaction type 200.


Field Name Value
Product type 5##

Unit 6
Solution 26
Business Example
After finishing the definition of the main process for product type 5##, you can define the
back-office processing. Define correspondence activities for product type 5##.
Dependencies
● This exercise uses the Business Partner BP## that was created in Exercise 1.
● This exercise uses product type 5## and transaction type 100.
100.
type 100.
Note:
1. Activate the correspondence process for product type 5##. Create a confirmation after
saving the contract.

Field Name Value
Product type 5##

a) In the Customizing Implementation Guide, choose Financial Supply Chain

Settings → Correspondence → Correspondence Activities → Define Correspondence
Activities - Money Market.
b) Start the customizing transaction and select company code TA## on the Determine
Work Area: Entry popup window.
d) Enter the data provided in the table, Correspondence Activities 100.
e) Choose Save, and stay in the customizing screen for the next step.
2. Activate the correspondence process for product type 5## with transaction type 200.

Field Name Value
Product type 5##
a) Choose New Entries.
b) Enter the data provided in the table, Correspondence Activities 200.
c) Choose Save.
d) To return to the Customizing Implementation Guide, choose Back.

SAP Forms
Figure 457: An Introduction to Forms - Forms Builder
Adobe PDF forms are delivered with SAP standard, and can be used for outgoing messages.
The forms are delivered as confirmations to be used for external correspondence and dealing
slips to be used for internal correspondence.
In a form, you specify a standard text with a user-defined layout. SAP passes the financial
transaction data in the structures shown above. When the correspondence is created, the text
is displayed with the current transaction data. You can define different standard texts for
different product types, transaction types, activities, etc.
The forms delivered with SAP standard are the following:
● TR_F_AFM_CONF_MM: confirmation for money market transactions
● TR_F_AFM_CONF_FX: confirmation for foreign exchange transactions
● TR_F_AFM_CONF_DE: confirmation for derivatives
● TR_F_AFM_CONF_SE: confirmation for securities
● TR_F_AFM_CORR_MM: dealing slip for money market transactions
● TR_F_AFM_CORR_FX: dealing slip for foreign exchange transactions
● TR_F_AFM_CORR_DE: dealing slip for derivatives
● TR_F_AFM_CORR_SE: dealing slip for securities
SAP also delivers SAP script forms but the Adobe PDF forms are recommended over the SAP
script forms.

Figure 458: An Introduction to Forms - Layout
On the Layout tab, the user can see where the fields are placed on the form once it is
generated. A company logo, and company specific wording, etc., can be added to the forms.
To send correspondence by e-mail, the communication interface SAPconnect must be set up.
(See also: Note no.: 152474)
Figure 459: An Introduction to Forms - Fields
PDF forms are created and edited using the Interactive Forms function. This transaction also
contains the form documentation. When implementing the forms, you should copy the SAP
standard form and adjust the copied version to meet your needs.
The fields are hidden within the form logic depending on the contract type and product type.
The TR_I_AFM_CORR interface is used to transfer the data to the PDF forms. The forms are
maintained in the Interactive Form system transaction (Transaction SFP), which you find in
the menu, under Tools Form Printout.
Note: When you create a new PDF form, the form name cannot be longer than 16 characters
due to technical reasons. Otherwise, the form cannot be assigned in Customizing.

BAdI SMOD_RFTBCOEX can be used to fill additional fields in the correspondence forms. In
the interface methods, the correspondence output structures (TBCO structures) are
presented for changes. This is where you can make changes or fill your own fields, which are
preferably added to the output structure using append structures.
Figure 460: Available BAdIs
To enable an open and flexible framework, many BAdIs have been defined, and some have
also been implemented. Information on the BAdIs can be found by following the customizing
Manager → General Settings → Correspondence → Correspondence Messaging Interface →
BAdIs.
Below is additional information on the correspondence related BAdI's that are available:
● BAdI: Influence Correspondence Monitor Selection Criteria This Business Add-In (BAdI) is
used in the Transaction Manager (FIN-FSCM-TRM-TM) component. You can use this
Business Add-In (BAdI) to influence the results of selections based on criteria specified on
the selection screen of the correspondence monitor (Transaction FTR_COMONI).
● BAdI: Fill Fields in Correspondence Objects (Customer-Includes) This Business Add-In
(BAdI) is used in the Transaction Manager (FIN-FSCM-TRM-TM) component. You can use
this Business Add-In (BAdI) to fill user defined fields in the payload structure or
correspondence object structure. This BAdI is also used to fill the address fields in the
include structure TCORS_RECIPIENT_ADDR and also some other fields like recipient
(RECIPIENT), message status (MSG_STATUS), reason for message status
(MSG_REASON), recipient's country (CORR_COUNTRY), recipient's language
(CORR_LANGUAGE).
● BAdI: Influence Events After Saving Correspondence Objects The BAdI
BADI_TCOR_EVENT is used to provide flexibility after actions done in the correspondence
monitor. It implements the logic to influence events after storing correspondence.
● BAdI: Influence Events After Storing Correspondence Objects.

Business Partner Group and Profile
Figure 461: Maintain Correspondence Master Data Settings
In the business partner master data, you can also specify the business partner's BIC code or
SWIFT code. If the code is not maintained there or if you want to use additional or alternative
BIC codes, you can make the relevant assignments in the Assign BIC and External Securities
Account ID to Business Partner tile.
To assign a BIC to a business partner, use the application side menu Financial Supply Chain
→ Correspondence → Master Data → Assign BIC and External Security Account ID to
Business Partner (BIC Codes for BP (FTR_BP_BIC) - Treasury - Master Data).
Figure 462: Maintain Profile and BP Group Assignments
A required step to generate correspondence is to assign a communication profile and

business partner group to business partners on the application side.
In the outbound process, the communication profile that is to be used and a business partner
group must be assigned to the business partner, both in the company code and in the
business partner's correspondence recipient type. You make this assignment in the
Assignment of Profiles and BP Groups to External Recipients transaction (Assign Profile and
BP Groups to Ext Recipient (FTR_EXT_ASSIGN) tile under Treasury - Master Data)
This assignment may be made at various levels. For example, it may apply to all securities in
general or to one specific product type only. The screenshot above shows a blank business
partner field, which then assigns the rule to all business partners.
As with external recipients, an assignment must be made to the internal recipient if outgoing
correspondence is to be sent to this internal recipient. You make this assignment using the
Assignment of Profiles and BP Groups to Internal Recipients tile.

To maintain profile and business partner group assignments to external recipients, use the
application side menu Financial Supply Chain Management → Treasury and Risk
Management → Transaction Manager → General Settings→ Correspondence → Master Data
→ Maintain Profile and BP Group Assignments to Internal Recipients. (transaction code
FTR_INT_ASSIGN - Note: the tile is not added to the S4F51 Fiori Launchpad).
Figure 463: Assign Correspondence Class
customizing path: Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → General Settings → Correspondence → Correspondence Messaging
Interface → Assign Correspondence Class for Inbound Process Dependent on Recipient
(Inbound Correspondence Assignment (FTR_INB_FUNC) - Treasury Master Data).
Figure 464: Business Partner Group Assignment for Inbound Correspondence
customizing path: Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → General Settings → Correspondence → Assign Business Partner
Group for Inbound Process (Inbound Correspondence Assignment (FTR_INB_FUNC) -
Treasury Master Data).
Figure 465: Correspondence Monitor
After finishing all customizing and application settings, you can create a new contract. With
the creation of a financial transaction, the system checks the correspondence setting of the
Business Partner and creates a confirmation. As soon as the transaction is saved, the
correspondence can be viewed in the correspondence monitor.
The correspondence monitor provides an overview of all available correspondence objects.
You can edit existing objects and create new correspondence objects. You can use the
correspondence monitor to process the entire trading process without re-entering data and

without any manual intervention. The entire life cycle of the trading transaction can be
processed using the straight-through processing method.
The correspondence monitor provides you with the following processing and monitoring tools
based on the Correspondence Overview:
● An overview of the current processing status with symbols.
● A function for setting the counter-confirmation status to matched directly from the
monitor.
● A function that allows you to execute planned correspondence directly from the monitor.
● The option of repeating correspondence that has already been generated. This function
allows you to restart a correspondence run that failed, for example, for a particular
selection of correspondence (e.g. the toner ran out in the printer).
● You cannot use the correspondence monitor to display correspondence as SWIFT files.
● A function for navigating to the IDoc processing functions, to the transaction (history) or to
the display for the optical archive.
● A function for deleting correspondence planned records.
● A function for resetting a counter confirmation that was set manually.
● The system logs the change documents.
Execute Correspondence
Simulation: Execute Correspondence

For more information on Execute Correspondence, please view the simulation in
the lesson Configuring the Correspondence Monitor online in the SAP Learning
Hub.

Unit 6
Exercise 27
Business Example
You want to use the new correspondence functionality for creation of confirmations and
dealing slips.
To create securities class data, select the Correspondence Monitor tile (Treasury – Back
Office Functions).
Dependencies
● The business partner BP##.
● The product type 5## and the transaction type 100.
● Ensure that the flow types were assigned to product type 5## and the transaction type
100.
Note:
1. Activate the correspondence functionality for business partner BP## and product type
5##.
Field name or data type Value
Business Partner BP##

Valid from 01.01. of the current year
Recipient /Sender Type COUNTERPARTY
Correspondence DEAL_MM
Swift Code PTSDDEN0MM
2. Assign the business partner group BPG_DEFAULT for inbound process.


Company Code TA##

Product Type 5##

Business Partner Group BPG_ DEFAULT
3. Maintain profile PR_DEFAULT and the BP group BPG_DEFAULT assignments to external

recipients.
Table 69: External Recipient


Company Code TA##
Table 70: BP Profile and Group

Profile PR_DEFAULT
4. Assign correspondence class for inbound process dependent on recipient. The

correspondence is created with format PDF_CNF_MM.
Format PDF_CNF_MM
5. Create a fixed-term deposit (product type 5##, transaction type 100) with business
partner BP## in your company code TA##.
Table 71: Transaction Details 1

Company Code TA##

Product Type 5##


Payment Amounts 100t

Start 0
End +++1 (out one year)
Percentage Rate 3
Interest Calculation Method Act/360
6. View the generated correspondence for the financial transaction in the Correspondence
Monitor tile (Treasury - Back Office functions).
Company Code TA##

Transaction Your transaction number from this lesson.
7. Manually enter the incoming correspondence received by fax from your counterparty
using the Correspondence Monitor tile (Treasury - Back Office functions). Keep in mind
that for incoming correspondence to match, the incoming confirmation details must
match the trade exactly or the system will not find a trade to match - and that is correct.
Table 73: Incoming Details

Correspondence Category Transaction activities

Company code TA##
Product Type 5##
Incoming/Outgoing Incoming
Creation Options Fast Entry
Table 74: Correspondence Details

Recipient/Sender Type Counterparty

Sender BP
BP Group BPG_DEFAULT
Profile PR_DEFAULT
Correspondence Class DEAL_MM

Table 75: Counterparty Details

Currency EUR
Amount 100T
Direction - (outgoing)
Start of term Today
End of term Out one year or end date of trade entered
Interest rate 3
Note:
The above details must match exactly to the trade entered. If in doubt, open
another browser and verify the details of the trade entered.

Unit 6
Solution 27
Business Example
You want to use the new correspondence functionality for creation of confirmations and
dealing slips.
To create securities class data, select the Correspondence Monitor tile (Treasury – Back
Office Functions).
Dependencies
● The business partner BP##.
● The product type 5## and the transaction type 100.
● Ensure that the flow types were assigned to product type 5## and the transaction type
100.
Note:
1. Activate the correspondence functionality for business partner BP## and product type
5##.

Valid from 01.01. of the current year
Swift Code PTSDDEN0MM
a) Proceed to the group Treasury - Master Data and choose the BIC Codes for BP
(FTR_BP_BIC) tile.
b) Press the New Entries button and enter the data provided in the table.
c) To confirm your entries, press Enter.
d) Choose Save.
2. Assign the business partner group BPG_DEFAULT for inbound process.


Company Code TA##
Product Type 5##
a) Proceed to the group Treasury - Master Data and choose the Assign BP Group for
Inbound Correspondence (FTR_INB_ASSIGN) tile.
c) To confirm your entries, press Enter.
d) Choose Save.
3. Maintain profile PR_DEFAULT and the BP group BPG_DEFAULT assignments to external

recipients.
Table 69: External Recipient


Company Code TA##
Table 70: BP Profile and Group

Profile PR_DEFAULT
a) Choose the Assign Profile and BP Groups - Ext. (FTR_EXT_ASSIGN) tile (Treasury -
Master Data), and click the + (insert row) icon in the left panel.
b) Enter the data provided in the table, External Recipient, and press Enter.
c) Open the Money Market folder in the right top window until you get to the product type
level.
d) Double-click product type 5## (Fixed-Term Deposit).
e) In the lower right window, click the + (insert row) icon.
f) Enter the data provided in the table, BP Profile and Group, and press Enter.

g) Choose Save.
4. Assign correspondence class for inbound process dependent on recipient. The

correspondence is created with format PDF_CNF_MM.
Format PDF_CNF_MM
a) Choose the Inbound Correspondence (FTR_INB_FUNC) tile (Treasury - Master Data),

and from the menu bar, choose New Entries.
c) Choose Save.
5. Create a fixed-term deposit (product type 5##, transaction type 100) with business
partner BP## in your company code TA##.

Company Code TA##

Product Type 5##

Payment Amounts 100t

Start 0
End +++1 (out one year)
Percentage Rate 3
Interest Calculation Method Act/360
a) Choose the Create Financial Transaction tile.
b) Enter the data provided in the table, Transaction Details 1, and press Enter.
c) Enter the data provided in the table, Transaction Details 2, and press Enter.
d) Choose the Status tab.
e) On the toolbar, choose the Correspondence icon.

f) Press the back arrow once.
g) Press Save.
6. View the generated correspondence for the financial transaction in the Correspondence
Monitor tile (Treasury - Back Office functions).
Company Code TA##

Transaction Your transaction number from this lesson.
a) Choose the Correspondence Monitor (FTR_COMONI) tile (from Group Treasury - Back
Office Functions) to display the correspondence.
c) Choose Execute.
d) Choose Correspondence.
e) Select the row.
f) Right click on the mouse and at the popup menu, select Acknowledgment Receipt to
manually record the acknowledgement received by the receiving party. Press Continue
(Enter) through the message popup. The Status on the message should now be
Delivered.
g) Select the View Message icon.

You may receive a message that the data carrier is not set up. This is a basis task.
7. Manually enter the incoming correspondence received by fax from your counterparty
using the Correspondence Monitor tile (Treasury - Back Office functions). Keep in mind
that for incoming correspondence to match, the incoming confirmation details must
match the trade exactly or the system will not find a trade to match - and that is correct.
Table 73: Incoming Details

Correspondence Category Transaction activities

Company code TA##
Product Type 5##
Incoming/Outgoing Incoming
Creation Options Fast Entry
Table 74: Correspondence Details

Recipient/Sender Type Counterparty

Sender BP
BP Group BPG_DEFAULT

Profile PR_DEFAULT
Correspondence Class DEAL_MM
Table 75: Counterparty Details

Currency EUR
Amount 100T
Direction - (outgoing)
Start of term Today
End of term Out one year or end date of trade entered
Interest rate 3
Note:
The above details must match exactly to the trade entered. If in doubt, open
another browser and verify the details of the trade entered.
a) Choose the Create button from the output screen of the Correspondence Monitor.
A dialog appears.
b) On the dialog, enter the data provided in the table, Incoming Details, and press Enter.
c) Enter the data provided in the table, Correspondence Details.
d) On the dialog, enter the data provided in the table, Counterparty Details, and press
Enter.
e) Press the Change deal assignment button.

The system validates your entries.
f) If the system finds your trade, choose Save. If not, revalidate your entries.
g) Choose Save.

LESSON SUMMARY

Unit 6
Lesson 2
Using the Payment Program
LESSON OBJECTIVES
Payment Program Overview (F110/F111)
Figure 467: Payment Program Overview
Business Example
Treasury departments execute various types of payments, such as bank account transfers,
trade-related payments, and one-off payments. These types of payments can be made by a
Treasury department using SAP’s Treasury payment program.
● Treasury program overview
● Payment program overview
● Payment controls
People familiar with SAP applications are often familiar with the Accounts Payable (AP)
payment program, but not everyone is familiar with the Treasury payment program, although
there are features of the Treasury payment program that most companies could use to
improve their processes in an SAP system. The Treasury payment program offers a very
controlled, best practice process for treasury departments to follow.


the lesson Using the Payment Program, online in the SAP Learning Hub.
payments related to Treasury processing accumulate and will need to be transferred to the
banks.
Figure 470: Payment Program Overview
Whereas the AP payment program pays AP and accounts receivable (AR) invoices, the
Treasury payment program pays payment requests. Payment requests are open items made
to the Payment Request Clearing Account, which is a suspense account configured to track

Lesson: Using the Payment Program
Treasury payments. The same Payment Request Clearing Account number should be used
across all company codes.
Animation: Payment Program Overview

For more information on Payment Program Overview, please view the animation
in the lesson Using the Payment Program, online in the SAP Learning Hub.
Below are the two payment programs available on SAP:
1. Automatic Payment Transactions (F110) - This is commonly referred to as the AP

payment program. It is typically used to pay vendors and customers, e.g. rebates.
2. Automatic Payment Transactions for Payment Requests (F111) - This is commonly

referred to as the Treasury payment program, and pays payments queued up by
Transaction Manager, the In-House Cash module, freeform payments, and bank-to-bank
transfers.
● Automatic Payment Transactions (F110) - The AP payment program processes domestic
and foreign payments for vendors and customers. It creates payment documents
(postings) and supplies data to the payment medium programs. These payment medium
programs create an output for the payments. For example, the output may be checks or
payment files, e.g. XML or MT101 files, that would then be transferred to the banks.
● Automatic Payment Transactions for Payment Requests (F111) - You use this function to
start the Payment Program for Payment Requests. This is an additional option for
automatic payment in the SAP system. Unlike the standard payment program, the
payments are not based on open items (customer items) but on payment requests.
- If you want to generate payment requests for transactions with a business partner, you
can define these in the standing instructions for the business partner payment details.
To do this, set the Payment Request indicator in the Standing Instructions of the
payment details and enter at least one payment method in the List of Payment Methods
field. These settings are the default values for the payment details for each transaction
with the business partner.
- You make the final decision as to whether to generate a payment request, however,
when you actually enter the transaction. If you do not want to generate a payment
request, you can overwrite the default values from the standing instructions in the
payment details for the transaction.
- In a transaction, one payment request is generated for each flow. If you use the
functions from the Public Sector area, one payment request is generated for each
account assignment. In the relevant posting record, the bank clearing account is
exchanged for the clearing account for payment requests. The payment program for
payment requests makes the clearing posting from the clearing account for payment
requests to the original bank clearing account.
There are seven types of payments that could be run through the Treasury payment program
(F111). They are:
1. Bank-to-bank transfers
2. Free form payments
3. Business partner repetitive code payments

4. Trade-related payments
5. In-house cash (IHC) payments
6. Loans Management (FS CML) payments
7. Payments to customers and vendors
Note: When you are making payments to customers and vendors using the Treasury payment
program, the customer and vendor bank details are used, but the open invoice is not cleared.
Figure 472: Dual Controls on Treasury Payments
Treasury payments are typically wires for large dollar amounts, so payment controls are key.
Payment controls are in place to accomplish the following:
1. Avoid making mistakes in transmitting wires ─ such as dollar amount, bank account detail,
and reference field
2. Avoid having individuals make payments to third parties that should not have been made
(whether by processing an invalid payment request or intentionally making an invalid
payment)
Throughout the payment process in the SAP system, there are a number of places where dual
controls can be activated. The definition of dual control related to payments is that a person
other than the initiator of the payment must approve the payment before it moves forward in
the process. For example, if a business partner is created and bank details are entered in the
business partner master record, a dual control workflow process can be activated that blocks
the business partner from being used in a payment before the business partner changes have
been approved by a person other than the person who created or changed the business
partner.
The following are dual controls that can be put along the payment process flow:
● Business partner creation/update approval
● Free form payment approval

● Repetitive code template creation approval

● Payment approval (batch level approval) using the Bank Communication Management
(BCM) module. (Additional licensing may be required.) This approval is role based. It is not
technically a dual control in that the person who initiated the wire is able to approve the
wire. The controls must be put into the authorizations and role assignments.
Other types of payments made through the Treasury payment program.

Repetitive Payments
Repetitive payments are bank-to-bank transfers or payments to a business partner that take
place regularly using the same set of payment instructions. There are two types of repetitive
payments in the SAP system: bank-to-bank transfers and business partner repetitives. The
SAP system uses repetitive codes to process repetitive payments. A repetitive code in the
SAP system is a 20-character key that designates a set of payment standing instructions that
do not and cannot be changed ad hoc. This includes the sender bank, sender account,
recipient bank, recipient account, payment method, and currency. The only details that can
be changed when the payment is made are the payment amount, value date, and reference
text. There are multiple advantages gained by using repetitive codes in the SAP system. Some
of the advantages include increased security, faster entry, and risk mitigation against user
error.
Bank-to-Bank Transfers
The most common type of repetitive payment is the bank-to-bank transfer. Bank-to-bank
transfers are used to make repetitive payments from one house bank account to another.
Both accounts must be defined in the SAP system as house bank accounts. Keep in mind that
when the two accounts are in different company codes, this type of repetitive payment
creates an intercompany posting document (the payment posting posts to the intercompany
due to /due from accounts) posting. (Bank-to-bank transfers can be done between any two
accounts as long as the FI configuration has enabled cross-company code postings between
the two entities.)
Business Partner Repetitives
Business partner repetitives are repetitive payments made from a house bank account to a
business partner bank account.
Freeform Payments
Freeform payments are one-off payments to a party not defined on SAP as a business
partner. To execute a free form payment, run the Online Payment program found under
Accounting → Financial Supply Chain Management → Cash and Liquidity Management →
Planning → Generate Payment Request → Using USA Control Program → Online Payment, or
execute transaction code RVND.

Figure 473: Steps to Running Treasury Payment Program
Animation: Steps to Running Treasury Payment Program

For more information on Steps to Running Treasury Payment Program, please
view the animation in the lesson Using the Payment Program, online in the SAP
Learning Hub.
The following are the steps when running the Treasury payment program:
1. Enter parameters - This is where you tell SAP what you want to pay by specifying the
payment methods, company codes, etc., which are referred to as the payment
parameters.
2. Run the proposal - This is where SAP tells you what will be paid based on the parameters
you entered.
3. Payment run - In this step, the postings are made to the general ledger. (This step can be
run as one or two separate steps.)
4. Create payment medium. In this step, the payment file or output is created. This last step
can be combined with the payment run step above.
Note:
It is worth noting that the payment proposal is an optional step and steps 3 and 4
can be combined into one step during execution of the payment run.

Payment Methods
Figure 475: Configure the Treasury Payment Program
Business Example
Your company needs to use the Treasury payment run F111 for their payments executed by
the Treasury department. For the implementation of the payment program, the following
settings are required:
● Paying Company Codes
● Payment Methods in the Country
● Payment Method in the Company Code
● Payment request number ranges
● Determine the payment request clearing account
Figure 476: Payment Methods
The F110 (AP) and F111 (Treasury) payment programs share some of the basic configuration.
This configuration can be found under the first four buttons shown above.

Use transaction FBZP to get to the Customizing settings of the payment run. You will see a
menu, split into three sections, which is explained in more detail on the following pages.
Follow the customizing menu path Financial Accounting → Accounts Receivable and
Accounts Payable → Business Transactions → Outgoing Payments → Automatic Outgoing
Payments → Payment Method/Bank Selection for Payment Program, or use transaction code
FBZP.
Company Code Settings
In this step, all company codes from which payments are to be generated must be entered
here.
If payments for a company code will be paid from a different company code, this information
is specified in the Control data section.
For the Treasury payment program purposes, the settings are usually the same across all
company codes.

Under Paying Company Codes, you specify which company codes are to be used for
payments and from which fields the sender information is supposed to be retrieved.
In the Control Data section, the minimum payment amounts are specified for both incoming
and outgoing payments.
Click the Forms and Sender Information buttons. Choose a company code where you want to
take a closer look at the payment control.
The Credit Identification Number specifies a unique, cross-country identification of the
creditor of a SEPA direct debit. The creditor ID number comprises the following elements:
● Characters 1-2: country key (for example, DE)
● Characters 3-4: check digit (is calculated the same way as the IBAN check digit)
● Characters 5-7: creditor business code (for example, for indicating individual business
codes or branches of the creditor). The creditor business code is by default filled with the
letters ZZZ. It is a non-identifying part of the SEPA mandate. This means that by changing
the business code in the creditor ID no new mandate is created. Even after you have made
such a change, a mandate search made by the system using the old creditor ID number
still finds the corresponding mandates.
● Characters 8-35: national identification characteristic for the creditor, progressively
numbered in ascending order.

Define Payment Methods
Next, the payment methods to be used in the Treasury payment program (F111) are defined.
First, the payment methods are created in a country, then in a company code. Payment
methods must be defined first in a specific country to be able to take into account local
payment format requirements.
It is helpful if the payment methods used for the Treasury payment program are different
from the AP payment program payment methods because then the system can clearly
distinguish the payment methods that are to be used with the AP payment program versus
the payment methods for the Treasury payment program. One way to easily distinguish the
Treasury payment program payment methods from the AP payment program payment
methods is to use the numbers 0-9 for treasury payment methods and A-Z for the AP
payment methods.

When defining the details of the payment method, you can set the following:
● Specify if the payment method is for outbound or inbound payments
● Type of payment method, e.g. bank transfer or check
● Required information in the master data, e.g. bank details, IBAN, SWIFT
● Payment medium, e.g. type of output file
● Specify the document type for payment and clearing
The Payment Medium Workbench (PMW) is a tool used to configure and create payment
media sent by organizations to their house banks.
● Superior control and verification of payment procedure
● Improved performance with mass payments (> 50,000)
● Better sort functions with payment advice notes
● Clearer to work with than the myriad previous payment medium programs
● Easier to maintain and to extend
It is possible to control the use of the payment method, for example, by currency or origin. For
example, a payment method created for SEPA payments should only allow the EUR currency
to be used for these payments.
Allowed currencies:
● Not all payment methods have to be suitable for all currency types. In order to limit the
number of currencies per payment method in advance, you can enter the values here.

● To do so, select a payment method in a country and, in the left menu hierarchy, go to level
2.
Allowed origins:
The origin represents how the payment request was triggered. The origin indicates the
application area from which the payments originate, i.e. Transaction Manager, In-House Cash
payments, etc.
Once the payment methods have been specified in the countries, you have to also specify
them at country-code level. In the application, you can only use payment methods for which
there is an entry in this table. You will see that only the assigned payment methods are
displayed when the business partner master data is modified.
Double-click an entry to view the details.
You can specify the maximum or minimum amounts that have to be taken into account for
paying an item. If the open item does not meet these conditions, an error message will be
displayed when the payment program is run.
In the Foreign Payments/Foreign Currency Payments section, select the indicator is foreign
business partners are allowed, foreign currency payments are allowed, and if the business
partner address outside of the payment country is allowed.
Information in the Drawer on the form section is passed to the payment file generated during
the payment run.

Figure 482: Account Determination
Next, the account determination for the Treasury payment program is entered. This
configuration can be done by currency, house bank account, and/or payment method. In this
step, you define when the Treasury payment program is run in this currency, the house bank
account, the payment method, and the cash clearing account to which the posting from the
payment request clearing account should go. In other words, the payment program uses this
customizing table to determine the accounting entries to make when the program is run.
Follow the customizing menu path Financial Accounting → Bank Accounting → Business
Transactions → Payment Transactions → Payment Handling → Bank clearing account
determination → Define account determination and enter the configuration.
In addition, a calendar must be defined to determine working days for each currency you will
be paying out of the Treasury payment program. This is done using customizing menu path
Financial Accounting → Bank Accounting → Business Transactions → Payment Transactions
→ Payment Handling → Value Date → Define Factory Calendar per Currency.

Payment Request Clearing Account
Figure 483: Payment Request Clearing Account
Animation: Payment Request Clearing Account

For more information on Payment Request Clearing Account, please view the
animation in the lesson Using the Payment Program, online in the SAP Learning
Hub.
The next step is to assign the general ledger (G/L) account that will be the payment request
clearing account used to track the payment requests. The payment requests are the
payments that will be sent to the external banks. All payments sent through the Treasury
payment program queue up to the payment request clearing account. This G/L account
should be the same G/L account across all company codes.
To assign the G/L account follow customizing menu path Financial Supply Chain
Settings → Payment Management → Payment Requests → Define Clearing Account for
Payment Requests.
Enter the company code and payment request clearing G/L account, then click the save icon.

Payment Request Number Ranges
Figure 485: Payment Request Number Ranges
Next, define a number range for the payment request. Payment request numbers, also known
as key numbers, go across company codes, meaning each payment request is given a unique
number regardless of the company code from which the payment was made.
To define the payment request number range, follow customizing menu path Financial
Accounting → Bank Accounting→ Business Transactions → Payment Transactions →
Payment Request → Define Number Ranges for Payment Requests.
How to Maintain the Account Determination for Payment Requests
Simulation: How to Maintain the Account Determination for Payment Requests

For more information on How to Maintain the Account Determination for
Payment Requests, please view the simulation in the lesson Using the Payment
Program online in the SAP Learning Hub.
Business Partner Payment Details
Figure 487: Business Partner Payment Details
The Payment Transactions tab in the business partner master record is used to hold the
business partner's bank details (bank account information) which relate to payments.
Note: The business partner "payment details" and business partner "bank details" are the
same thing. They refer to a business partner's bank account information stored on SAP.

The bank details captured here are used in case the funds need to be transferred from
another house bank account using the TRM payment program.
With SAP, there can be straight-through processing of payments. The business partner's
bank details are entered just once in the business partner master record, and flow through the
payment process, and into the payment file that is sent from SAP to the bank.
Business Partner Standing Instructions
Figure 488: Business Partner Standing Instructions
The function of the Standing Instructions is both to allow the Business Partner authorization
and to facilitate the Back Office work on the level of the company code.
The Standing Instructions can be created or managed using the button Company Code.
Prerequisite for the availability of the button: the Business Partner is displayed in the role
Counterparty!
Figure 489: Business Partner: Standing Instructions - SI Payment Details
The Business Partner Standing Instructions Payment Details are defaults, which are inherited
from the business partner to the deal automatically. They can be altered within the deal. The
business partner standing instructions reduce manual processing when entering a financial
transaction. They also reduce risk in that the correct bank details default into the trade
automatically.
● They are created by currency.
● The definition of the Payment Detail ID allows to assign different ways of payments by
product.
● Also, it is proposed which payment method and program is to be used.

Figure 490: Standing Instructions - Payment Details Explanations
Payer/payee: Incoming and outgoing payments are settled using this business partner.
Use:
● If the business partner is the house bank, it is not required to enter data in this field, as
payments are made exclusively using the house bank account. The business partner
settles all the payments, and is therefore automatically the payer/ee.
● If the business partner does not act as the house bank, you have to enter a payer/ee in the
payment details. The result is that payments are not made to the business partner, but to
the payer/ee.
● When payments are due, they are drawn to the payment details specified in the master
data for the payer/ee (business partner or alternative payer/ee), which means that these
must be maintained accordingly.
Bank details ID: Key identifying a business partner's bank details. Retrieves the Bank details
stored for Payer/Payee within the tab Payment Transactions.
Create Payment request: A payment request is the prerequisite for the use of the specific
TRM payment program.
Indicator Individual payment: This indicator is used to determine whether payment on an
individual basis is necessary or whether flows are allowed to be paid together with other flows
(e.g. compensation, netting). This indicator is only significant for flows that can generate
payment requests.
● If the indicator is NOT set, payment may be made on an individual or joint basis.
● If it is set, payment is to be made in on individual basis.
Indicator Same direction necessary for joint payment: This indicator is used to determine
whether flows are allowed to be paid as part of a joint payment regardless of the direction of
the payment (incoming or outgoing) or whether the direction has to be the same for all flows.
● If the indicator is NOT set: flows can be grouped regardless of payment direction.
● If the indicator is set: flows can only be grouped if they have the same payment direction.

Payment method: Method of payment, e.g. money transfer, check.

The system supports multi-level payment methods. By entering a bank chain, you can
process payments using several banks. Up to three intermediate banks are supported.
More information on payments is provided in the following unit on Payments.
Figure 491: Business Partner Payment Details
Assigning the payment details standing instructions can be tricky the first time through.
Figure 492: Payment Details/Payment Detail ID

Animation: Payment Details/Payment Detail ID

For more information on Payment Details/Payment Detail ID, please view the
animation in the lesson Using the Payment Program, online in the SAP Learning
Hub.
Assignment is a mandatory step in entering the business partner payment details standing
instructions. Without assignment the information is not inherited completely to the deal! In
that case the deal can not be saved without completing the payment information.
Execute the Treasury Payment Run
Simulation: Execute the Treasury Payment Run

For more information on Execute the Treasury Payment Run, please view the
simulation in the lesson Using the Payment Program online in the SAP Learning
Hub.


Unit 6
Exercise 28
Business Example
You now want to create a fixed-term deposit in Transaction Manager, post it, and pay it using
payment run F111.
To check payment requests and to execute the Treasury payment program, use the tiles
under Treasury – Payment Processing.
Note:
1. Create a money market transaction (product type 55A/transaction type 100) in your
company code (TA##) and with your business partner (BP##). Use the Create Financial
Transaction tile. Make sure the payment details have been set to create a payment
request on the outgoing side.
Note the transaction number.
Field Name Value
Amount 50M EUR

Interest 2.6%
Start date 0 (Today)
End date ++3 (three months out)
2. Settle your transaction using the Edit Financial Transactions tile.
3. Once the transaction has been released, post it using the Post Flows tile (or transaction
code TBB1). When the trade flows are posted, a payment request is created. Check the
posting transactions and make a note of the payment request number.

Note the document number.
Note the payment request number.
4. View the payment request using the Display Payment Requests tile (or transaction code
F8BT).
5. Use the Automatic transaction for payments tile to run the Treasury payment program (or
transaction code F111) (Treasury - Payment Processing). Only pay the payment request
just created. Use the transaction created in step 1.
Table 76: Parameters

Field Name Value
Company code TA##

Posting date today
Next payment run on tomorrow
Payment methods T
Customer <blank>
G/L account <blank>
Additional logs
Do not log payment method selection No
Payment method selection if not successful No
Payment method selection in all cases Yes
Check due date Yes
Items of the payment documents Yes
Table 77: Dynamics Selections

Field Name Value
Key Number Enter your payment request ID numbers

from step 3.

Note:
In production, take a shortcut and copy payment parameters from a previous
run. Additionally, it is possible to schedule the treasury payment program.
6. Create a payment proposal by pressing the Proposal button. At the Schedule Proposal
window, press the Enter key to continue. Press the Enter key to have the status of the
proposal run updated in the Status window. When the proposal run is complete, there will
be a message indicating that is the case. Check whether your transaction has been
selected. If all settings are correct, start the real payment run and create the payment
medium.
Table 78: Proposal Details

Field Name Value
Start immediately Yes

Create payment medium No
7. Create a payment proposal by pressing the Pmnt run (Schedule Payment) button. At the
Schedule Pmnt Run window, press the Enter key to continue. Press the Enter key to have
the status of the proposal run updated in the Status window.
Table 79: Payment Details

Field Name Value

Create payment medium Yes
8. To see the payment log, press the Display payment log button. In the log, the accounting
entries that were generated are displayed. The accounting document number is also
displayed in the log.

Unit 6
Solution 28
Business Example
You now want to create a fixed-term deposit in Transaction Manager, post it, and pay it using
payment run F111.
To check payment requests and to execute the Treasury payment program, use the tiles
under Treasury – Payment Processing.
Note:
1. Create a money market transaction (product type 55A/transaction type 100) in your
company code (TA##) and with your business partner (BP##). Use the Create Financial
Transaction tile. Make sure the payment details have been set to create a payment
request on the outgoing side.
Note the transaction number.
Field Name Value
Amount 50M EUR

Interest 2.6%
Start date 0 (Today)
End date ++3 (three months out)
c) Choose the Payment Details tab.

The payment details have defaulted from the business partner standing instructions,
and a payment request is selected.

d) Save the transaction and note the transaction number for later settlement activities
and postings.
2. Settle your transaction using the Edit Financial Transactions tile.

a) Choose the Collective Processing tile, or choose the Edit Financial transaction tile
(Treasury - Trade Processing).
3. Once the transaction has been released, post it using the Post Flows tile (or transaction
code TBB1). When the trade flows are posted, a payment request is created. Check the
posting transactions and make a note of the payment request number.
Note the document number.
Note the payment request number.
a) Set a restriction to company code TA##, and choose the Post Flows tile (Treasury -
Accounting).
Note the posting document number.
A payment request is created. Check the posting transactions and make a note of the
payment request number.
b) Check the posting log.

If no errors have occurred, start the posting run. Note the payment request number.
4. View the payment request using the Display Payment Requests tile (or transaction code
F8BT).
a) To restrict the display to a few transactions, set the company code to your company
code (TA##), and choose the Display Payment Requests tile.
b) View the Open payment requests, which are payments yet to be moved through the
treasury payment program, or Cleared payment requests, which are payments already
paid.
c) You see a list of all transactions that meet your selection criteria. You can double-click
the payment request line to view all of the details related to the payment. .
Note the payment method of the payment request. The payment method can be
viewed by changing the layout to show the field or by drilling down on the payment
request. The payment method is one of the last fields to be displayed when looking at
the drilldown view.
5. Use the Automatic transaction for payments tile to run the Treasury payment program (or
transaction code F111) (Treasury - Payment Processing). Only pay the payment request
just created. Use the transaction created in step 1.

Table 76: Parameters

Field Name Value
Company code TA##

Posting date today
Next payment run on tomorrow
Payment methods T
Customer <blank>
G/L account <blank>
Additional logs
Do not log payment method selection No
Payment method selection if not successful No
Payment method selection in all cases Yes
Check due date Yes
Items of the payment documents Yes
Table 77: Dynamics Selections

Field Name Value
Key Number Enter your payment request ID numbers

from step 3.
Note:
In production, take a shortcut and copy payment parameters from a previous
run. Additionally, it is possible to schedule the treasury payment program.
a) Choose the Automatic transaction for payments tile (Treasury - Payment Processing).
b) Enter the execution data (today) as well as a payment run ID (TA##), and press Enter.
c) To enter the payment parameters (tell the system what is to be paid), choose
Parameters.
d) Enter the data provided in the table, Parameters.
e) For both dialogs, choose Continue.
f) Choose Dynamics Selections.
g) On the dialog, enter the data required in the table, Dynamic Selections.
h) Press Save to save the Dynamic Selections entry.
i) Press the back arrow to get back to the initial screen. At the popup window, press Yes
to save your entries.

Note:
The Dynamic Selections step is only required if you want to pay only
specific payment requests for your company code.
6. Create a payment proposal by pressing the Proposal button. At the Schedule Proposal
window, press the Enter key to continue. Press the Enter key to have the status of the
proposal run updated in the Status window. When the proposal run is complete, there will
be a message indicating that is the case. Check whether your transaction has been
selected. If all settings are correct, start the real payment run and create the payment
medium.
Table 78: Proposal Details

Field Name Value

Create payment medium No
a) To generate a proposal, choose Proposal.

A dialog displays.
b) At the dialog, enter the data provided in the table, Proposal Details.
c) Choose the Status button until the message Payment Proposal has been created
displays in the Status window.
d) To see the accounting entries that are generated or for any error messages, choose
Display Proposal Log.
The true document number does not display because a posting has not yet been
generated.
Note:
To see the accounting entries that are generated, the Additional Log
settings mentioned have to be selected with the payment parameters.
7. Create a payment proposal by pressing the Pmnt run (Schedule Payment) button. At the
Schedule Pmnt Run window, press the Enter key to continue. Press the Enter key to have
the status of the proposal run updated in the Status window.
Table 79: Payment Details

Field Name Value

Create payment medium Yes
a) At the dialog, enter the data provided in the table, Proposal Details.
b) Choose the Status button until the message Payment Run has been created displays in
the Status window.

8. To see the payment log, press the Display payment log button. In the log, the accounting
entries that were generated are displayed. The accounting document number is also
displayed in the log.

Multi-Bank Connectivity
Figure 495: Multi-Bank Connectivity (1)
Bank connectivity is key to Treasury. A Treasury department typically has various files that
are transferred to and from the banks daily. Examples of these files are the following:
● Outgoing payment files
● Outgoing trade confirmation files
● Incoming payment acknowledgement files (payment status)
● Incoming bank statements (account statements)
Most corporates have bank accounts and do business with multiple banks and therefore need
to connect to the banks on a daily basis. Host-to-host connections with the banks can be
setup for straight-through processing of payments or business users may need to login to the
bank portal to manually execute payments. The trade-off is the cost of setting up host-to-host
connections and maintaining that software on an on-going basis versus having risky, time-
intensive manual processing. With Multi-Bank Connectivity, SAP customers have another
option.
SAP Multi-Bank Connectivity connects corporates directly with financial services institutions
without leaving the SAP ecosystem. An advantage of using Multi-Bank Connectivity is SAP
customers do not need to introduce another third party vendor, such as a bank

communication software vendor, into their end-to-end system processes. The use of SAP
Multi-Bank Connectivity results in improved control, efficiency, and transparency of the
financial accounting process. As the solution automatically updates payment status and cash
positions in the ERP system once updates are available from the banks it further improves
and streamlines the company’s treasury operations.
The file types currently supported are the following:
● Outgoing payment files
● Outgoing trade confirmation files
● Incoming payment acknowledgement files (payment status)
● Incoming bank statements (account statements)
The Multi-Bank Connectivity solution provides corporates with a multi-bank, digital channel
between their ERP systems and their banks. In addition, the solution also offers embedded
SWIFT connectivity.
This corporate cloud banking network provides measurable improvement to the accounts
payable and accounts receivable functions through automation of all the manual and error-
prone steps associated with the execution and reconciliation of payments, order-to-cash
applications, and order entry documents.
The on-boarding to the solution is very straight-forward and delivered through a private cloud
owned and managed by SAP that is secure and partitioned by each customer and their
network of banks.
Animation: Multi-Bank Connectivity (3)

For more information on Multi-Bank Connectivity (3), please view the animation
in the lesson Using the Payment Program, online in the SAP Learning Hub.
As with rolling out new functionality, the on-boarding process for SAP Multi-Bank
Connectivity involves a testing phase before going live.
SAP has identified a simple three-step process to using SAP Multi-Bank Connectivity where
the first step involves the on-boarding to the network enabling connectivity, security and
message type mapping where needed.

The second step involves the testing of the exchange of messages. The individual members
confirm with SAP that they wish to connect and SAP Multi-Bank Connectivity Operations
activates the service between the members and inform the pair they are now ready for an
end-to-end test. Once end-to-end testing is complete, the product level connection is
activated for productive usage.
Once information is flowing between members, SAP runs and manages the inter-connectivity
to ensure seamless and smooth running of the network, delivering real-time messages
between the different parties.
● Step 1: On-boarding
- Connect to MBC
- Agree on payment message format
- Perform connectivity tests
● Step 2: Bank activation and testing
- Perform end-to-end connectivity testing
- Finalize service activation
● Step 3: Run and Manage
- Monitor, manage, and deliver financial messages
- Add new banks and services as needed
Each network participant has a unique “tenant” for processing and a unique partition (with
unique encryption) for data storage. There is separation of data and processing by each bank
and each corporate participant, as well as digital signing and encryption of data, ensuring that
integrity, security, and authentication are complete.
Figure 499: Multi-Bank Connectivity
The key advantages of using Multi-Bank Connectivity are:

● The process to implement bank communication to multiple banks is fast. It is much less
effort than to implement host-to-host connections to the banks.
● There are cost reductions compared to maintaining disparate e-banking systems.
● The SAP customer does not need to worry about system maintenance or upgrades as
Multi-Bank Connectivity is a cloud application maintained by SAP.
● The SAP customer has just one channel to connect to all financial institutions.
● Let SAP support the bank communication process.

● SAP customers can more easily change their banking relationships, if necessary.
● Multi-Bank Connectivity offers secured connectivity.
● Straight-through processing is achieved with one software vendor (SAP).
For questions or to get started with Multi-Bank Connectivity, SAP customers should contact
their SAP Account Executive.

LESSON SUMMARY


Unit 6
Lesson 3
Using the Trade Repository
LESSON OBJECTIVES
Trade Repository
Business Example
Your company is using SAP Treasury and Risk Management and you are obligated to report to
a trade repository to fulfill EMIR requirements according to ESMA. You are considering using
the dedicated service provider Virtusa to meet your company’s regulatory reporting
requirements.
Figure 500: Changes in Financial Reporting Requirements
After the financial crisis in 2007 and 2008, a number of financial regulatory changes have
taken place worldwide. For example, in 2010, the countries in the G20 nations made a strong
commitment to regulatory reform of the market for derivatives. In the U.S., there was the
Dodd-Frank Wall Street Reform and Consumer Protection Act. In Europe, there has been a
number of changes made to regulatory reporting changes for derivatives.
Due to the regulatory reporting requirements and the changes to the requirements, one
option for SAP customers is to use Virtusa, which is a cloud-based third-party solution called
SAP Trade Repository Reporting by Virtusa (aka: SAP TRR by Virtusa). This offering is also
known more generically as Trade Repository Reporting. This solution allows SAP customers
to meet the reporting requirements more easily in that they do not need to devote as many
internal resources to meet the requirements. This solution is scalable and will support future
changes to the reporting requirements.

The big benefit of using this solution is SAP and Virtusa take full responsibility for keeping up
with regulatory changes. SAP customers can concentrate on their core business.
The asset classes supported by the Virtusa are the following:
● FX
● Interest rates
● Equities
● Commodities
● Credit
● Collateral
● And others
Figure 501: Definition of Terms
Before moving forward, a definition of key terms is provided.

ESMA - European Securities and Markets Authority under the European Market Infrastructure
Regulation (EMIR) works in the field of securities legislation and regulation to improve the
functioning of financial markets in Europe. The idea behind ESMA is to establish an "EU-wide
financial markets watchdog".
Dodd-Frank Wall Street Reform and Consumer Protection Act was signed into law in response
to the financial crisis of 2007 and 2008. It made changes in the American financial regulatory
environment affecting all federal financial regulatory agencies and almost every part of the
U.S.'s financial services industry.
Trade Repository - an entity that centrally collects and maintains the records of over-the-
counter (OTC) derivatives. The electronic platforms, acting as authoritative registries of key
information regarding open OTC derivative trades provide an effective tool for mitigating
inherent opacity (lack of clarity) of OTC derivative markets.
Over-the-counter (OTC) or off-exchange trading is done directly between two parties, without
the supervision of an exchange. OTC trading is contrasted with exchange trading, which
occurs via exchanges. An exchange has the benefit of facilitating liquidity, providing
transparency, and maintaining the current market price.
Virtusa/Polaris has a cloud-based solution that works with SAP to meet the EMIR reporting
requirements.

Lesson: Using the Trade Repository
Figure 502: Business Process Overview
1. Virtusa/Polaris helps identify the data to be reported and can extract from any number of
sources. Extract data and store data on files(s). Csv-files or xml-files. Files are transferred
using a so called SFTS-server (Secure File Transfer Service).
2. Virtusa/Polaris transform the data into our engine, so it is regulatory compliant.

Transformation engine will detect relevant changes to report.
Files are imported to TRR's first data layer (staging) where checks are made. Notifications
sent via mail if errors! Data is mapped in TRR (Instrument-, Party- and other data is
mapped). Clients can during the day monitor data (New, Modifications, Terminations,
Valuation & Collateral) that is going to be sent to Trade Repository.
3. Virtusa/Polaris then sends a report to the trade repository of choice. It then gathers the
reconciliation status from trade repositories. Data is sent to Trade Repository either
manually or by a schedule.
Figure 503: Implementation Steps
The steps to onboard the SAP Trade Repository Reporting by Virtusa are now outlined.
Identification Workshop
● Virtusa helps its customers identify the data to be reported, which may include any of the
following:
● Transaction data
● Positions / market values
● Counterparty data
● Instrument data

● Collateral
Platform Provisioning
● Tenant creation and technical connection are established
● Transfer data to Cloud-based platform via secure File Transfer Service (FTS)
● Security setup and exchange of keys for the encryption process
Transform Data into Regulatory Compliant Information

● Advanced transformation engine loads data into generic EMIR data model
● Engine detects regulatory relevant changes on trades (logged and stored for audit
purposes)
● Reconciliation status from Trade Repository keeps companies on top of their reported
data, no matter what repository will be used
Communicate with Trade Repository

● Platform will send necessary reports to the Trade Repository of your choice
● Platform will also gather the reconciled data from the Trade Repository to consolidate the
information into the portal
You can run the solution on ECC or on S/4HANA. A prerequisite is the SAP Treasury and Risk
Management (TRM) module has been implemented and the Business Function FIN_TRM_TRR
has been activated.
Please see the following SAP notes if interested in learning more about using the Virtusa
solution: 2305429, 662340, 2384289, 2337693, and 2334950.
How to Access the SAP Trade Repository Reporting by Virtusa/Polaris
Simulation: How to Access the SAP Trade Repository Reporting by Virtusa/

Polaris
For more information on How to Access the SAP Trade Repository Reporting by
Virtusa/Polaris, please view the simulation in the lesson Using the Trade
Repository online in the SAP Learning Hub.
LESSON SUMMARY

Unit 6
Learning Assessment
1. Select all that apply regarding the correspondence monitor.

X A Correspondence can be created, received and matched automatically.
X B Settlement can be performed automatically upon Confirmation.
X C The Correspondence settings are subject to configuration on granular Level.
X D Deal Data is retained by time of Correspondence created.
X E A Correspondence Monitor is available.
2. What types of payments should be processed using the F111 payment program?
X A Repetitive Treasury Payments.
X B T&E Payments.
X C One Time Treasury Payments.
X D All payments within SAP can be processed through F111.
3. Which of the following file types are supported by Multi-Bank Connectivity?

X A Payment files
X B Bank statement files
X C Correspondence files
X D Payment acknowledgement files

4. Which of the following applies to the Trade Repository on SAP?

X A Complies with evolving EMIR reporting requirements for derivative trades.
X B Transforms derivative trade data into EMIR-compliant information.
X C Satisfies regulatory reporting requirements in the U.S.
X D Offers data collection, transformation, mapping, and routing of data to trade

repositories.

UNIT 7 Hedge Management and
Accounting
Lesson 1
Defining Exposure Management 515
Exercise 29: Create Exposure Activity Type and Reference Based Exposure 525
Lesson 2
Understanding the SAP Hedge Management Solution 537
Lesson 3
Creating Reference Based Hedging Areas 576
Exercise 30: Create Hedging Classification 583
Exercise 31: Create a Reference-Based Hedging Area 585
Lesson 4
Customizing Hedge Management Elements 596
Exercise 32: Customize Hedge Management 607
Exercise 33: Update a Reference Based Hedging Area and Create FX Trade 613
Lesson 5
Understanding FX Options Process and Customizing 621
Lesson 6
Understanding Hedge Accounting 629
UNIT OBJECTIVES
● Define Exposure Management

● Define exposure activity types
● Define exposure positions
● Define product types for exposures
● Establish exposure lifecycles
● Understand the SAP Hedge Management solution

Unit 7: Hedge Management and Accounting
● Explain the reason for doing hedge accounting

● Outline the hedge categories that exist for FX hedge accounting according to IAS, IFRS,
and US GAAP
● Understand the Hedge Management cockpit, the hedging area, and snapshots
● Use the trading platform integration SCP app to integrate a front-office trading system
with SAP Treasury and Risk Management
● Outline the full end-to-end hedge management process covered in the Treasury and Risk
Management Business Processes course
● Explain hedge management terms and concepts
● Understand the difference between period-based hedging areas and reference-based
hedging areas
● Describe differences in the definition of the hedging area when using reference-based
hedging areas
● Know the configuration settings required when using reference-based hedging areas
● Outline the different customizing steps relevant to hedging classifications
● Customize hedge management key elements
● Customize additional hedge management elements
● Outline the process steps for exercising an FX option contract
● Outline the hedge management specific configuration related to FX options
● Understand hedge accounting customizing settings

Unit 7
Lesson 1
Defining Exposure Management
LESSON OBJECTIVES
Exposure Management
Figure 505: Integration View of Components
Looking at the view hedge management components above, in this objective, we are
discussing the Exposure Management component.
Many corporations are exposed to foreign currency risks. Typically organizations purchase
from vendors from different countries, sell to customers in different countries or have
subsidiaries abroad all being based on different currencies.
Foreign exchange exposures are caused by the regular operating business. They are arising in
form of planning data, firm commitments and balance sheet positions. Not managing them
continuously endangers the profit the corporation could make.
The process many companies follow is the middle office collects exposure data based on
forecasted cash flows in risk currencies from various sources. They consolidate the exposure
data to enter it into the SAP system as Raw Exposures. The exposure data should be
aggregated in granularity which differentiates:

● Company code
● Risk currency
● The period when the exposure is due
Once the exposures are known and loaded into SAP, the hedging of the exposures starts,
based on a company's hedge policy.
Definition of Terms
Before moving forward, a definition of key terms is provided.

● Exposure: In SAP Treasury and Risk Management, hedging activities are performed to
hedge many different financial risks associated with your operating business. Different
companies will have different financial risks based on their businesses however in an effort
to use one standardized term for all risks, we use the term exposure to describe such a
financial risk.
● Raw exposure: In Exposure Management, only the basic data relating to your operative
business transactions is stored in a raw format known in the system as a raw exposure. A
raw exposure is a basic mapping of an operative business transaction.
● Sub raw exposure: All information relating to financial risks is stored in sub raw exposures.
Sub raw exposures form part of a raw exposure. A raw exposure can contain several sub
raw exposures.
● Exposure position: The raw exposures taken together represent the financial risk
associated with a company's operation. The total risk position is known as an exposure
position, which comprises several sub raw exposures.
● Differentiation and exposure transactions: Differentiation enables you to define how risks
are divided. The sub raw exposures are initially converted into a temporary intermediate
format. They then become exposure transactions and are used to create exposure
positions.
● Exposure position flow: Exposure transactions are used to create exposure position flows,
which, in turn, create the exposure position. An exposure position generally contains
several exposure position flows.
● Exposure position value: The exposure position value is the total value of the exposure
position flows for one exposure position on a particular key date.

Lesson: Defining Exposure Management
Figure 507: Exposure Management Configuration Steps
Animation: Exposure Management Configuration Steps

For more information on Exposure Management Configuration Steps, please
view the animation in the lesson Defining Exposure Management, online in the
SAP Learning Hub.
The steps above outline the key steps to configure Exposure Management on SAP. They do
not strictly need to be entered in the order shown. This is more a logical ordering.
Exposure Position Types

Define Global Settings
Figure 509: Define Global Settings
If you have an exposure that is a forecasted transaction, which becomes a firm commitment.
You enter the exposure into SAP. SAP will match the two and reduce the forecasted item by
the amount of the first commitment. The system automatically matches the firm
commitment positions to previously entered forecast position. This is referred to as
automatic position matching.
You use this activity to choose between the options Automatic Position Matching and
Transaction Category Change Allowed.
● When you choose Automatic Position Matching, the process for the raw exposures is as
follows.
You first create raw exposures with the transaction type Planned Transaction. The system
creates an exposure position on the basis of the values for the above differentiation criteria. If
there is already an exposure position corresponding to these criteria, it is increased by the
amount. Over time, the transaction type of the underlying transaction changes to Fixed

Commitment Transaction. You cannot change this field in the raw exposure. Instead, you
have to create a new raw exposure with the new transaction type. When the raw exposure is
released, the 'old' exposure position with the transaction type Planned Transaction is reduced
by the amount of the raw exposure (= automatic matching), and a new exposure position with
the transaction type Fixed Commitment Transaction is created (or increased if a suitable
exposure position already exists).
Customizing path: Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → General Settings → Exposure Management 2.0→ Define Global
Settings.
Define Periods
Figure 510: Define Periods
When you enter a raw exposure in the Exposure Management 2.0, you can assign the planning
period and the planning year to the line items instead of the due date or in addition to the due
date. The planning period together with the planning year defines the period in which the raw
exposure expire. If you do not enter a due date for your raw exposure in raw exposure
maintenance, the last working day of the relevant period acts as the expiry date / due date for
the exposure.
The planning period and the planning year are differentiation criteria for your exposure
positions.
● If you have not entered the planning period and planning year in the raw exposure, the
system - when creating the exposure position - derives the planning period and the
planning year from the due date and the planning year variant of the relevant exposure
position type and adds them to the exposure position (but not in the raw exposure).
● If you do not want to have the planning period and the planning year as differentiation
criteria, you can set the No Planning Period and Planning Year indicator in the activity
Define Exposure Position Types.
Planning Period: The planning period together with the planning year defines the period in
which the raw exposure expires.
Planning year Variant: The planning year variant split the year into periods.
Posting Period: Self-contained part of the a fiscal year.
In the maintenance view, choose New Entries and enter the following:
● 3-digit identifier for the planning period

● Short text for the planning period

● Choose the planning year variant (= fiscal year variant).
● Choose the posting period of the planning year variant relevant for this planning period
Transaction Manager → General Settings → Exposure Management 2.0 → Define Periods.
Define Exposure Activity Type
Figure 511: Define Exposure Activity Type
You configure your exposure activity types. The exposure activity type is a required entry
when you create a raw exposure.
The sub raw exposures are created for a raw exposure in accordance with what you enter
here.
Exposure Activity Type: The exposure activity type gives semantic meaning to an exposure. It
is also the anchor for the dynamic field selection feature. A raw exposure is always created
with an exposure activity type.
Raw Exposure Flow Category for FX: Signifies the direction of the FX flows in an exposure.
Raw Exposure Release Type: For each exposure activity type, you can decide whether raw
exposures are released manually or automatically.
Transaction Manager → General Settings → Exposure Management 2.0 → Define Exposure
Activity types.
Define Exposure Lifecycle
Figure 512: Define Exposure Lifecycle
You define the exposure categories that are required in order to differentiate exposure
positions. Each exposure category is assigned to a default transaction category in Hedge
Accounting for Exposures.

In the change view, you assign a transaction category from Hedge Accounting for Exposures
for each exposure category. This transaction category is then used as the default when the
system transfers the exposure positions of this exposure category to Hedge Accounting for
Exposures.
Transaction Manager → General Settings → Exposure Management 2.0 → Exposure
Lifecycle.
Define Product Types for Exposures
Figure 513: Define Product Types for Exposures
Product types for exposures are defined in this step. Product types for exposures allow you to
define the exposure product types to be used for your implementation.
These product types must be attached to exposure position types. The product type of the
exposure positions is needed for the integration of the exposure positions (as operating
exposures) in the Risk Analyzer.
In this step, the matching exposure position type is defined. The transaction category is a
differentiation criterion of the exposure positions, which means that, in this case, a new
exposure position is created and the 'old' exposure position is reduced (updating the
exposure positions).
In the maintenance view, choose New Entries and specify the following:
● Product type
Examples include stocks, bonds, or investment certificates.

● Short text of up to 10 characters
● Long text of up to 30 characters
● Product category
The only category available is Exposure.

Transaction Manager → General Settings → Exposure Management 2.0 → Define Product
Types for Exposures.

Define Exposure Position Types
Figure 514: Define Exposure Position Types
The exposure position type defines the differentiation criteria that are relevant for your
exposure positions. For the automatic matching process, you determine the matching
exposure position type.
You define your exposure position types. By making the settings here, you decide on the
differentiation criteria that are relevant for your exposure positions. For the automatic
matching process, you determine the matching exposure position type.
Position Types.
As an additional step, it may be necessary to create Derivation Strategies to derive fields such
as the Exposure Position Type, which would be done using the Define Exposure Fields
Derivation Strategy configuration.
fields Derivation Strategies.
Exposure Process Flow
Figure 515: Exposure Process Flow

In Exposure Management, you collect future incoming and outgoing payments of your
company that are associated with a currency risk. These payment flows are either actual
payments that already have a fixed amount and time settings or they are only planned
payments. Exposure Management helps you identify the risks in payment flows and offers you
integration with hedge management.
The process steps in Exposure Management are the following:
1. The raw exposures are created in SAP.
2. The raw exposures that will be hedged are released.
3. After the raw exposures are released, they are in Exposure Position Management. Once in
Hedge Management the exposures can be linked to a hedging instrument to form a
hedging relationship.
FX exposure hold the following information:

● Period of the exposure
● Amount of the exposure
● Currency of the exposure
● Target currency of the exposure (typically the company currency)
Creating Raw Exposures
Figure 516: Creating Raw Exposures
Raw exposures are created manually using the Raw Exposure Maintenance tile shown above.
In addition, the following BAPIs can be used to create an automated interface into Exposure
Management.
● BAPI_TEX_EXPOSURE_CREATE
● BAPI_TEX_EXPOSURE_CHANGE

Create Exposure Activity Type and Reference Based Exposure
Simulation: Create Exposure Activity Type and Reference Based Exposure

For more information on Create Exposure Activity Type and Reference Based
Exposure, please view the simulation in the lesson Defining Exposure
Management online in the SAP Learning Hub.


Unit 7
Exercise 29
Create Exposure Activity Type and Reference
Based Exposure
Business Example
Your company is ready to start using hedge management on SAP to hedge incoming FX
exposures.
The exposure activity type is a required entry when creating a raw exposure. When creating
the exposure activity type, the fields that are suppressed, required, optional, or display only
must be specified. Create an exposure activity type to track your incoming foreign exchange
exposures.
Lastly, you will create an incoming USD exposure for an expected sale that will result in an
incoming USD exposure, then validate the exposure using the Process Exposure Positions
app (Treasury – Hedge Management).
Creating exposure activity types is a customizing step. Use transaction code SPRO, and
follow the path to Treasury and Risk Management. The application side tiles used in this
exercise are in the Treasury - Hedge Management group.
Note:
This exercise has no dependencies.
1. Create a new incoming exposure activity type CF## for your foreign exchange exposures.
Set the field selection to mark fields as suppressed, required, optional, or display only.
Use the data provided in the following tables:
Table 80: Exp Activity Type Details

Field Name Value
Exp Activity Type CF##
FX Exposure Category Incoming
Description FX Exp Inc - Ref Based ##
Release Type Automatic
Change GS Default Global Settings

Table 81: General Attributes

General Attrib- Suppress Req. Entry Opt. entry Display
utes
Company Code X
Country X
External Docu- X
ment Number
Exposure Origin X
Logical System X
Physical Inven- X
tory Indicator
Table 82: Free Attributes

Free Attributes Suppress Req. Entry Opt. entry Display
Short Header X
Attribute 1
Short Header X
Attribute 2
Long Header At- X
tribute 1
Data Header At- X
tribute 1
Table 83: Line Item Attributes

Line Item Attrib- Suppress Req. Entry Opt. entry Display
utes
External Item X
Number
Profit Center X
Long Item At- X
tribute 1
Long Item At- X
tribute 2
Long Item At- X
tribute 3
Long Item At- X
tribute 4
Medium Item X
Attribute 1

Medium Item X
Attribute 2
Short Item At- X
tribute 1
Date Item At- X
tribute 1
Planning Period X
Planning Year X
Due Date X
Exposure X
Amount
Exposure Cur- X
rency
Target Currency X
Payment Date X
Delivery Date X
Without Usage X
Without Usage X
Portfolio X
Cost Center X
Business Area X
WBS Element X
Segment X
On behalf of X
company
Raw Exposure X
Description
2. Create a raw exposure for a large USD sale using the Raw Exposures tile (Treasury –
Hedge Management) and the data provided in the table Raw Exposure Details.
To link underlying exposures to the hedge, the underlying (raw) exposures must be
recorded. These raw exposures are then available for additional processing in the Hedge
Management.
Table 84: Raw Exposure Details

Field Name Value
Exposure Activity Type CF##

Raw Exposure ID <blank>
Version <blank>

Field Name Value
Line Items /S4F50_51

Sub Raw Exposure /S4F50_51
3. Enter the header data using the following data:
Table 85: Header Data

Field Name Value
Ext. Doc No. Free form unique Text

Sales USD Group ##
Default Exposure Category 01 (Forecasted Transaction)

Company Code TA##
Country DE
Crit ExpPos Type FXR (Reference based)
Direction of CF In
Long Header Attr 1. <Free form text>
Date Header Attr.2: Current date
Valid From System Date
4. Create a new line item using the following data:
Table 86: Line Item Data

Field Name Value
Period M<current month+2>

If current date is Feb 24, enter M04
Planning Year Current Year

Exp Due Date Current date plus two months If current
date is Feb 24, enter April 24, <current
year>.
Exposure Amount 10.000.000
ExpAmtCrcy USD
TargetCrcy EUR
When you save your raw exposure, it is automatically released to a position. Make note of
the position number for the next step.

Note the position number.
5. View the exposure position using the Overview Raw Exposures tile (Treasury – Hedge
Management) and filtering by your company code TA##.
Field Name Value
Company Code TA##

Exposure Amount Currency USD
After the exposures have been entered and reviewed, they automatically update the
Hedge Management Cockpit. From the Hedge Management Cockpit, these underlying
transactions (exposures) can then be linked to a hedging instrument and a hedging
relationship can be designated, which will be done in the next exercise.

Unit 7
Solution 29
Create Exposure Activity Type and Reference
Based Exposure
Business Example
Your company is ready to start using hedge management on SAP to hedge incoming FX
exposures.
The exposure activity type is a required entry when creating a raw exposure. When creating
the exposure activity type, the fields that are suppressed, required, optional, or display only
must be specified. Create an exposure activity type to track your incoming foreign exchange
exposures.
Lastly, you will create an incoming USD exposure for an expected sale that will result in an
incoming USD exposure, then validate the exposure using the Process Exposure Positions
app (Treasury – Hedge Management).
Creating exposure activity types is a customizing step. Use transaction code SPRO, and
follow the path to Treasury and Risk Management. The application side tiles used in this
exercise are in the Treasury - Hedge Management group.
Note:
This exercise has no dependencies.
1. Create a new incoming exposure activity type CF## for your foreign exchange exposures.
Set the field selection to mark fields as suppressed, required, optional, or display only.
Use the data provided in the following tables:
Table 80: Exp Activity Type Details

Field Name Value
Exp Activity Type CF##
FX Exposure Category Incoming
Description FX Exp Inc - Ref Based ##
Release Type Automatic
Change GS Default Global Settings

Table 81: General Attributes

General Attrib- Suppress Req. Entry Opt. entry Display
utes
Company Code X
Country X
External Docu- X
ment Number
Exposure Origin X
Logical System X
Physical Inven- X
tory Indicator
Table 82: Free Attributes

Free Attributes Suppress Req. Entry Opt. entry Display
Short Header X
Attribute 1
Short Header X
Attribute 2
Long Header At- X
tribute 1
Data Header At- X
tribute 1
Table 83: Line Item Attributes

Line Item Attrib- Suppress Req. Entry Opt. entry Display
utes
External Item X
Number
Profit Center X
Long Item At- X
tribute 1
Long Item At- X
tribute 2
Long Item At- X
tribute 3
Long Item At- X
tribute 4
Medium Item X
Attribute 1

Medium Item X
Attribute 2
Short Item At- X
tribute 1
Date Item At- X
tribute 1
Planning Period X
Planning Year X
Due Date X
Exposure X
Amount
Exposure Cur- X
rency
Target Currency X
Payment Date X
Delivery Date X
Without Usage X
Without Usage X
Portfolio X
Cost Center X
Business Area X
WBS Element X
Segment X
On behalf of X
company
Raw Exposure X
Description
a) In the SAP Customizing Implementation Guide, choose the following path: Financial
Supply Chain Management → Treasury and Risk Management → Transaction
Manager → General Settings → Exposure Management 2.0 → Define Exposure
Activity Types.
b) Choose New Entries and enter the data provided in the table Exp Activity Type Details.
c) Choose Save and choose the back arrow once.
d) To enter the field selections, select the tab to the left of your entry and choose Field
Selection.
e) Double-click General Attributes and select the settings provided in table General
Attributes.

f) Choose the Next Group icon to move to the free attributes fields, and select the
settings provided in table Free Attributes.
g) Choose the Next Group icon to move to the line item attributes fields, and select the
settings provided in table Line Item Attributes.
Note:
You will need to press the Next Page or page down key to see all the fields.
h) Choose Save.
2. Create a raw exposure for a large USD sale using the Raw Exposures tile (Treasury –
Hedge Management) and the data provided in the table Raw Exposure Details.
To link underlying exposures to the hedge, the underlying (raw) exposures must be
recorded. These raw exposures are then available for additional processing in the Hedge
Management.
Table 84: Raw Exposure Details

Field Name Value
Exposure Activity Type CF##

Raw Exposure ID <blank>
Version <blank>
Line Items /S4F50_51
Sub Raw Exposure /S4F50_51
a) Click on the Raw Exposures tile (Treasury – Hedge Management).
c) Choose Create.
3. Enter the header data using the following data:
Table 85: Header Data

Field Name Value
Ext. Doc No. Free form unique Text

Sales USD Group ##
Default Exposure Category 01 (Forecasted Transaction)

Company Code TA##
Country DE
Crit ExpPos Type FXR (Reference based)
Direction of CF In
Long Header Attr 1. <Free form text>
Date Header Attr.2: Current date

Field Name Value
Valid From System Date
a) After pressing Create, the app opens to the Header Data tab.
b) Enter the data from the table Header Data.
4. Create a new line item using the following data:
Table 86: Line Item Data

Field Name Value
Period M<current month+2>

If current date is Feb 24, enter M04
Planning Year Current Year

Exp Due Date Current date plus two months If current
date is Feb 24, enter April 24, <current
year>.
Exposure Amount 10.000.000
ExpAmtCrcy USD
TargetCrcy EUR
a) Go to the Line Item Data tab.
b) Choose the Create New Line Item (+) icon.
c) Enter the data from the table Line Item Data.
d) Press the Save button.
When you save your raw exposure, it is automatically released to a position. Make note of
the position number for the next step.
Note the position number.
5. View the exposure position using the Overview Raw Exposures tile (Treasury – Hedge
Management) and filtering by your company code TA##.
Field Name Value
Company Code TA##

Exposure Amount Currency USD
a) Choose the Overview Raw Exposures tile (Treasury – Hedge Management), and
execute.

b) Enter the key date and position ID.
c) Choose Execute.
After the exposures have been entered and reviewed, they automatically update the
Hedge Management Cockpit. From the Hedge Management Cockpit, these underlying
transactions (exposures) can then be linked to a hedging instrument and a hedging
relationship can be designated, which will be done in the next exercise.

LESSON SUMMARY

Unit 7
Lesson 2
Understanding the SAP Hedge Management
Solution
LESSON OBJECTIVES
and US GAAP
Hedge Management Reporting Requirements

What is Hedge Accounting?
Figure 518: What is Hedge Accounting?
Entities are exposed to financial risks arising from many aspects of their business. Different
companies are concerned about different risks (for example, some entities might be
concerned about exchange rates or interest rates, while others might be concerned about
commodity prices). Entities implement different risk management strategies to eliminate or
reduce their risk exposures. The objective of hedge accounting is to represent, in the financial
statements, the effect of risk management activities that use financial instruments to manage
exposures arising from particular risks that could affect profit or loss (P&L) or other
comprehensive income (OCI).
Simply put, hedge accounting is a technique that modifies the normal basis for recognizing
gains and losses (or income and expenses) on associated hedging instruments and hedged

items, so that both are recognized in P&L (or OCI) in the same accounting period. This is a
matching concept that eliminates or reduces the volatility in the statement of comprehensive
income that otherwise would arise if the hedged item and the hedging instrument were
accounted for separately under IFRS.
Review Hedge Accounting
Figure 519: Review Hedge Accounting
In this section, we will briefly review some of the terms and characteristics related to hedge
accounting. We will leave it to the reader to know by which accounting rules their company
needs to follow.
The following Hedge Categories exist according to IAS / IFRS and US GAAP, and are
supported by SAP's Hedge Management solution.
● Fair Value Hedge:
Protection against price or market value change of a recognized Assets or Liability (e.g.
Financial Instruments variable interest) or unrecognized firm commitment.
Fair value hedges are accounted for as follows:

● The gain or loss on the hedging instrument is recognized in profit or loss
● The hedging gain or loss on the hedged item shall adjust the carrying amount of the
hedged item (if applicable) and be recognized in profit or loss
● Exception: If the hedging instrument hedges an equity instrument for which an entity has
elected to present changes in fair value in other comprehensive income: both are posted to
other comprehensive income (OCI)
● When a hedged item is an recognized firm commitment (or a component thereof), the
cumulative change in the fair value of the hedged item subsequent to its designation is
recognized as an asset or a liability with a corresponding gain or loss recognized in profit or
loss.
● Cash flow Hedge:
Protection against the change of an expected future cash flow as a result of certain risk,
e.g. Foreign Exchange rate risk.
Cash flow hedges are accounted for as follows:

Lesson: Understanding the SAP Hedge Management Solution
● The separate component of equity associated with the hedged item (cash flow hedge
reserve) is adjusted to the lower of the following (in absolute amounts):
- The cumulative gain or loss on the hedging instrument from inception of the hedge; and
- The cumulative change in fair value (present value) of the hedged item (i.e. the present
value of the cumulative change in the hedged expected future cash flows) from
inception of the hedge.
● The portion of the gain or loss on the hedging instrument that is determined to be an
effective hedge (i.e. the portion that is offset by the change in the cash flow hedge reserve
calculated in accordance with (a)) shall be recognized in other comprehensive income
(OCI).
● Any remaining gain or loss on the hedging instrument (or any gain or loss required to
balance the change in the cash flow hedge reserve … is hedge ineffectiveness that shall be
recognized in profit or loss.
● Net Investment Hedge:
Protection of an investment in a foreign business / company.
Net investment hedges are accounted for as follows:

A Net Investment Hedge is a specific type of foreign currency cash flow hedge that is used to
eliminate or reduce the foreign currency exposure that arises from an entity's Net Investment
in a Foreign Operation (NIFO). Update consolidation each period of the NIFO into the parent
financial statements a foreign currency gain or loss is recognized in shareholders' equity.
When a derivative hedging instrument is used, the effective portion of the change in the fair
value of the instrument is recognized in equity. The ineffective portion is recognized
immediately in the P&L.
A Hedging Relationship relates to exactly one Hedge Category.
A hedging relationship qualifies for hedge accounting only if all of the following criteria are
met:
● It consists only of eligible hedging instruments and eligible hedged items.
● Formal designation and documentation of the hedging relationship exists.
● The entity's risk management objective and strategy are known.
● It meets the hedge effectiveness requirements.

SAP Hedge Accounting Solutions
Figure 520: SAP Hedge Accounting Solutions
Animation: SAP Hedge Accounting Solutions

For more information on SAP Hedge Accounting Solutions, please view the
animation in the lesson Understanding the SAP Hedge Management Solution,
SAP has two Hedge Accounting solutions:
1. Hedge Accounting for Exposures (or E-Hedge Accounting/E-HA, for short) is the Hedge
Accounting solution when there is interest rate risk and the hedged item is not in Treasury
and Risk Management Position Management. The transaction codes to this solution start
with THM*, e.g. THMEX - Hedge Plan.
2. Hedge Accounting for Positions (or P-Hedge Accounting/P-HA, for short) is the solution in
which Treasury positions can be hedged in accordance with specific Hedge Accounting
rules. There is integration with Treasury and Risk Management Position Management for
when debt held in the Securities module is hedged, for example. This solution integrates
with Exposure Management 2.0 and works with the Hedge Management Cockpit. This
solution supports prospective effectiveness testing with linear regression and Market Data
Sets (MDS) to allow for effectiveness testing with multiple scenarios.
When functionality was being developed for the IFRS9 changes, SAP decided to make all the
new functionality available for the Hedge Accounting for Positions (or P-Hedge Accounting)
solution. Moving forward, we will discuss only the Hedge Accounting for Positions (or P-Hedge
Accounting) solution.
SAP's Hedge Management Solution:
● Is fully integrated into Treasury subledger, the SAP general ledger, and adhers to its basic
principles of business transactions
● Supports the most common use cases
● Includes process automation including automatic designation
● Is capable of managing high volumes of hedging transactions

● Offers a fully integrated snapshots of exposures of future transactions for management of

an audit trail or for accounting reasons
The way to the Hedge Accounting for FX Risks in SAP Treasury presented in this lesson is:
● Prerequisites:
- EhP 8 or S/4 HANA OP or S/4 HANA Finance
- New yield curve framework activated
- CVA/DVA in use
- Exposure Management 2.0 and Net Open Exposure Report
Hedge Management Solution
Figure 522: Hedge Management Solution
This figure shows the overall FX trading process that can be realized by using SAP and the
different components included in the process flow. The blue arrows show the interfaces
supported in the standard solution where data is passed between the different components.
The Hedge Management and Hedge Accounting process helps companies decrease volatility
to the P&L from foreign currency operating transactions.
The functionality helps you automate labor-intensive processes, such as calculating net open
exposure amount, creating hedging relationship for hedge item and hedge instrument,
determining the key figures calculation (NPV, Forward, CCBS, CVA/DVA), performing the
valuation of FX transaction, checking classification, dealing with the de-designation and
generating posting journal reports.
Based on the hedging policy rules, the net open exposures are reduced by trading financial
instruments such as an FX forward or FX option transaction. For expected inflows of a risk
currency, the resulting exposure ares closed by a FX forward that sells the inflow currency
and buys the local currency of the company code. For expected outflows, a FX forward
transaction is traded that buys the outflow currency and sells the local currency.
Exposures are captured in Exposure Management and are reflected in the Hedge
Management Cockpit.
The Hedge Management Cockpit gives a clear view on a company's hedge management
situation. It reflects exposures (from Exposure Management 2.0 and One Exposure), hedging
instruments, and hedge requests.

The trading platform integration is a cloud application that connects external front-office FX
trading platforms, such as 360T, with your SAP Treasury and Risk Management component
in your SAP S/4HANA Cloud or SAP S/4HANA on-premise system acting as the back-end
system. Trades are executed in the front-office FX trading platforms and flow to SAP where
they are automatically created in the Transaction Manager module. This will be covered more
in the next lesson.
In Transaction Manager, the end-to-end life-cycle of trades is supported.
IFRS9 and U.S. GAAP hedge accounting is supported in Hedge Accounting.
Trade valuations, as well as scenario testing is done in Market Risk Analyzer.
Hedge Management Cockpit
Figure 523: Hedge Management Cockpit
The Hedge Management Cockpit is the key application used for viewing a company's current
situation with respect to foreign exchange exposures. It is the driving applications for
Treasury departments to view current positions with respect to hedge management and to
quickly and easily enter into new hedging instruments.
Treasury departments are responsible for executing their company's hedging policy for
hedging the risk of forecasted cashflows in foreign currencies in future periods. The forecast
itself is represented as exposures in the Hedge Management Cockpit.
The Hedge Management Cockpit incorporates the following data into one view:
● Exposures (from Exposure Management 2.0 and One Exposure)
● Hedges (FX derivative trades)
● Hedging relationships
The Hedge Management Cockpit does the following:

● Shall support all roles in the FX Risk Management Process with fast and reliable
information
● Combines data from Exposures, Hedges and (planned) Hedging Relationships in a
configurable way
● Works on data by Hedging Area
● Allows multiple Layout Definitions with reuse for different Hedging Areas

● Supports different levels of aggregations

● Supports drill-down from highest level of aggregation down to individual exposures or
hedges
Hedging Area
Figure 524: Hedging Area
The Hedging Area is an element that represents a section of hedging policy of the company. It
defines which risk you want to monitor and on what level of granularity. Whether exposures
are shown on a net or gross basis in the Hedge Management Cockpit is derived from the
exposure aggregation level of the Hedging Area.
The Hedging Area provides visibility to hedged items and hedging instruments. It is the
central steering entity that contains all relevant settings for this process.
The creation of a Hedging Area is a necessary requirement to start the process of Hedge
Management and Hedge Accounting.
The Hedging Area is a type of master data.
A company can have multiple Hedging Areas for Hedge Accounting based on its hedging
policy.
From the Hedge Management Cockpit, the user is able to get to the Hedging Area by pressing
the Hedging Area in the upper right corner of the Hedge Management Cockpit.
The screen above shows when the hedging area is defined, the type of hedging area is
specified.
There are two types of hedging areas:
1. Period-based

2. Reference-based
With period-based hedging areas, the hedging instrument hedges an exposure on a period
basis.
In the case of period-based hedging areas, the rule framework for exposure item
determination is the following:
1. Check whether the Hedging Classification is marked as Hedge Accounting relevant for
given company code and valuation area at start date of TRL position. If not, then no
Exposure Item can be determined. No hedging relationship will be created.
2. Depending on start date of TRL position the Hedging Area Version is determined.
3. According to the differentiation criteria defined in the Hedging Area Version and by means
of the start and end date of TRL position the system determines the Exposure Item ID and
its values like amount, currency, snapshot-ID, due date, differentiation criteria.
4. The number of Hedging Relationships to be created is determined by number of entries of

the Designation Splitter setting of the Hedging Area: The FX Transaction is fully
designated into n Hedging Relationships.
For reference-based hedging areas, the hedging item (exposure) is specified directly in the
hedging instrument.
To understand the hedge management solution, it is important to understand what is being

driven by the settings in the Hedging Area.
In this section, the different settings are listed.
Main Data tab
● Analysis Item Definition; By Reference or By Period
● Risk Category: Foreign Exchange Risk
● Exposure Aggregation Level: for example, Net and Gross. It defines the level at which
exposure items are stored in a snapshot.
● Local Currency: <toggle>
● Hedge Accounting: <indicator>
● Product Type for Exposure Subitems:
● Number of Periods:
● Period Length: <Month> or <Quarter>

● Trading Platform Integration indicator
General Settings tab

● Company Codes
● Differentiation Criteria: for example, select the checkbox of differentiation criterion
Currency and Company Code
● Hedging Classifications
Currencies tab
● Currencies listed in the table are taken into account for displaying data in the Hedge
Management Cockpit.
● Currency is required differentiation criteria for management of FX Risks
● All risk-relevant currencies have to be listed (for all relevant company codes)
Filters for Exposures tab

● At least one filter has to be defined to have exposure data available in the Hedge
Management Cockpit.
● Entries in the attributes of the filter specify the selection criteria for data of the Exposure
Source System (i.e. Exposure Management 2.0)
● Choose the source E_EM2 Exposure Management 2.0 (for hedging areas with analysis
item definition By Time Period)
● Choose the source E_EM2REF Exposure Management 2.0 by Reference (for hedging areas
with analysis item definition By Reference).
● Data from several filters is merged according to the definitions in the differentiation criteria
Filters for Hedges tab

● At least one filter has to be defined to have Hedging Instrument data available in the Hedge
Management Cockpit.
● Entries in the attributes of the filter specify the selection criteria for the source system of
Hedging Instruments (i.e. Transaction Manager for FX Forward and FX Options)
● Data from several filters is merged according to the definitions in the differentiation criteria
Target Quotas tab

● Target quotas are set by Target Quota Type on the level of the company code and
currency groups.
● The Target Quota defines key figure determination in the Hedge Management Cockpit. For
example, the Amount to Hedge key figure is calculated from the target quota.
FX Hedge Request tab

The settings activate Automated Request Creation and are used for the automated creation
of FX hedge requests.
● The automated hedge requests created will have the status set in the Target Status for
Automation field. The choices are status "Created" or "Submitted".

● Select the Exclude Current Period indicator if a hedge for the current period should not be
created.
● The default value date of the hedge requests created is specified in the Valuation Date
Definition field and the Additional Days field. Valuation Date Definition field specifies the
starting point per period and the Additional Days field specifies the offset to that. In
addition, there is the Working Day Shift indicator and method specified to indicate how to
shift past non-working days.
Under the Hedge Request Settings section, for each pair of company code and currency the
additional settings must be specified:
● Default Instrument Category to be used for the hedge requests created.
● Hedging Classification to be used for the hedge requests created.
● Minimum amount of the hedge requests created. If the minimum amount is not met, the
hedge request for that period will not be created.
● (Optional) The rounding rule to be applied to the hedge requests created. The amount of
the hedge requests is rounded to the rule specified.
Hedge Accounting I tab

● Designation Level:
● Per Company Code and Valuation Area it is defined at which level it shall be designated.
● The activation of splitting opens another table which influences the attributes of the
Hedging Relationships (e.g. due date of hypothetical derivative, OCI reclassification date,
off/on balance crossover).
● Designation Activation:
● Hedge Accounting can be activated per Company Code, Valuation Area and Currency. If
activated the automated designation process is switched on,
Hedge Accounting II tab

● The Designation Type controls how instruments are treated during designation.
● The Hedging Profile is a central customizing entity of Hedge Accounting for Positions
which holds information about how to process Hedging Relationships.
● With the creation of a hedging relationship the Market Data Set is included in the
generated test plan and defines what market data is used for effectiveness testing.

Manage Layout
Figure 527: Manage Layout
What is displayed in the Hedge Management Cockpit is a result of the layout used, the
definitions of the hedging area and the underlying snapshot.
To view the definition of the layout currently being displayed, select the Manage Layouts
button.
● The layout definition is independent from Hedging Area.
● Layouts are either private (only available for one user) or public.
● The following functions are available for layouts (depending on authorization):display, edit,
delete, copy and create
● Layouts delivered by SAP (starting with a number) can be used as a reference, but cannot
be changed.
● The Key Figures displayed in the Hedge Management Cockpit are driven by the Key
Figures specified in the layout definition.
● Display mode determines the design of the result table- Row: Key figures in Rows, Periods
in columns- Column: Key figures in Columns, Periods in columns
Key Figures
Figure 528: Key Figures

Below is a summary of some of the key figures available to be displayed in the Hedge
Management Cockpit. The list is continuously growing with each new software release. As
mentioned in the last slide, the Key Figures displayed in the Hedge Management Cockpit are
driven by the Key Figures specified in the layout definition.
● Incoming Exposure
● Outgoing Exposure
● Net Exposure
● Designated Hedges
● Freestanding Hedges
● Net Open Exposures
● Hedge Quota [%]
● Target Quota [%]
● Hedged Rate: Nominal weighted average rate of financial transaction rates included
● Hedge Quota: Net Hedges / Net Exposure in [%]
● Open Amt Hedge Req: Reflects the released hedge requests
● Amount to Hedge: Hedge amount required to meet hedging requirements
Snapshots
Figure 529: Snapshots
The Hedge Management Cockpit data is based on Snapshot data (for exposures). A key date
is used to determine a valid Snapshot ID and to select the Hedging Instruments.
The Snapshot needs to be marked as 'Day Reference' for Hedge Accounting Processing.
A snapshot is used for audit purposes to record the exposures at the time the hedge is
entered into. Snapshots are taken using the Take Snapshot app (transaction code
TOESNAPO).

Snapshots are a mandatory step to record the exposures at the time the hedge is entered
into. This ensures that an auditor can always check the data that served as the basis for a
hedging decision.
You take a snapshot before executing a hedging contract by using the Take Snapshot app.
The data in the snapshot can be reviewed at any time after the snapshot is taken using the
Manage Snapshots app.
Integrated View of Components
Figure 530: Integrated View of Components
Animation: Integrated View of Components

For more information on Integrated View of Components, please view the
A hedging relationship is a combination of a hedged item (e.g. exposure) and a hedging

instrument (e.g. derivative financial transaction) to obtain hedge accounting and therefore
avoid the earnings volatility that would arise from accounting the hedging instrument at fair
value.
The phases of a hedging relationship can be divided into the above three phases, which are:
1. Inception of the hedging relationship
2. Ongoing life of hedging relationship
3. End of hedging relationship
The SAP hedge management solution supports the end-to-end hedge management process.

Definition of Terms
There are a number of new concepts introduced in this lesson so before moving forward, a
definition of the hedge management key terms is provided.
The Hedging Area is an entity that represents a section of hedging policy of the company. It
defines which risk you want to monitor on which level of granularity. It provides visibility to
hedged items and hedging instruments. It is the central steering entity that contains all
relevant settings for this process.
Within the hedging area, you define the following for a risk category (Foreign Exchange Risk):
● The risk-free currency
● The relevant company codes
● The hedging-relevant currencies
● Filters with which to find exposures and the corresponding hedging instruments used to
fulfill the hedging policy of your company.
You can have different versions of a hedging area.

The Hedge Management Cockpit is based on exactly one hedging area. It offers various drill-
down capabilities into the original data sources. On the basis of the settings in the relevant
hedging area version, the Hedge Management Cockpit (transaction TOENE) calculates and
displays the net open exposures. The selected differentiation criteria controls the level on
which the net open exposures are calculated. With the Hedge Management Cockpit, it is
possible to gain an overview of the net exposures, resulting from the difference between the
foreign exchange exposures in Exposure Management 2.0 and the corresponding hedging
instruments in the transaction management of the Transaction Manager that were used to
mitigate risk. The Hedge Management Cockpit is based on exactly one hedging area. It offers
various drill-down capabilities into the original data sources.
Hedging Relationship: Combination of a hedged item (e.g. exposure) and a hedging
instrument (e.g. derivative financial transaction) to obtain hedge accounting and therefore
avoid the earnings volatility that would arise from accounting the hedging instrument at fair
value. The hedging relationship holds general information and calculation methods for Hedge
Accounting processing.

The Hedged Item represents the portion of the underlying operational exposure after splitting
calculation. The Exposure Item data was determined automatically from the relevant version
of the Hedging Area Snapshot.
The Hedging Instrument represents the FX Transaction which was created for hedging the
operational Exposure Item. The portion of the FX Transaction nominal amount which is to be
designated into the Hedging Relationship is determined based on the settings of the
designation splitting of the Hedging Area.
Trading Platform Integration
Figure 533: Trading Platform Integration Architecture
The FX Risk Management process uses the Trading Platform Integration SCP App as the
connection between the FX Trading Platform, such as 360T or FXAll, and SAP's Treasury and
Risk Management module. The Trading Platform Integration app is highlighted in the
screenshot above. Using the FX Trading Platform integration app,figure FX hedge requests
can be made directly from Hedge Management Cockpit to the 3rd party trading application,
such as 360T or FXAll, and then the trades are created automatically in SAP.
The SAP Cloud Platform (SCP) apps are products developed by SAP for creating new
applications or extending existing applications in a secure cloud computing environment
managed by SAP. SCP apps are a relatively new type of app that SAP has introduced with S/
4HANA. The Trading Platform Integration is just one of these cloud platform apps. SCP apps
are not bound to any S/4HANA release. Enhancements to SCP apps are independent of the
S/4HANA releases.
With the use of the Trading Platform Integration app and the functionality delivered in
Treasury and Risk Management, companies can have an FX trading process that is very
automated and requires little manual interaction.
If the Trading Platform integration is activated in the hedging area, once FX hedge requests
are released, they are transferred to the trade request and a corresponding Trade Request ID
and a Trade Request Status is assigned to the FX hedge request.
The SAP back-end system can be an S/4HANA cloud system, or an S/4HANA on-premise
system, or an ECC system.

Trade Request, Hedge Request and Automated Request
Figure 534: Trade Request from Treasury and Risk Management
Animation: Trade Request from Treasury and Risk Management

For more information on Trade Request from Treasury and Risk Management,
please view the animation in the lesson Understanding the SAP Hedge
This figure shows the step-by-step process flow to initiate hedge requests from the Hedge
Management Cockpit.
The Trading Platform Integration SAP Cloud Platform (SCP) application enables customers to
integrate FX transactions made on trading platforms into SAP S/4HANA automatically. This
functionality covers both inbound and outbound communication with front-office training
platforms, such as 360T or FXAll, for trade requests from SAP and executed trades from the
trading platform to SAP.
The interfaces for 360T are included with the software. SAP makes generic interfaces
available to integrate other front-office trading systems. Brisken, an SAP partner, provides
interfaces for FXAll.
In this slide, the end-to-end FX trading process using the Trading Platform Integration SAP
Cloud Platform (SCP) application is outlined.
The Trading Process (Inbound) and Trade Request Process (Outbound) from Treasury and
Risk Management can be described in the following way:
1. Use the Hedge Management Cockpit to obtain an overview of your foreign exchange
exposures and the corresponding hedging instruments that you used to mitigate a risk in a
hedging area.
2. For direct communication with your traders, the Hedge Management Cockpit enables you
to create hedge requests for analysis items automatically.
3. Afterwards you can display and review all trade requests that were generated after the
release of the hedge requests in the Process Trade Requests app.

4. On the SAP Cloud Platform you handle incoming trade requests with the Manage Trade
Requests app. With the app customers have to possibility to split trade requests, block
trade them or to decline trade requests. Send the required trade requests to the external
trading platform e.g. 360T, for further processing.
5. The external trading platform receives the order. You will be able to get different quotes
and can choose your favorite offer. From the trading platform the completed trades are
send back to the Cloud Platform.
6. In the Manage Trades app the Trader can store competitive bids and the information is
forwarded to the Transaction Manager as FX contract to the SAP back-end system where
the trade is created automatically.
7. When the Hedge Management Cockpit is opened, the data reflects the trades that have
been executed.
Notice that the Trading Platform Integration app serves to process the trade requests from
the SAP back-end system before the trade requests are sent to the front-office trading
platform and map the executed trades from the front-office trading platform to the SAP back-
end elements before the trade is created on the back-end system.
Keep in mind, the process shown here is the end-to-end process flow. Some companies may
chose to implement only the inbound process (from the front-office trading system to the
SAP back-end system), which is possible.
Figure 536: Initiating Hedge Requests
There are a number of ways from the Hedge Management Cockpit where hedge requests can
be created.
The process of initiating hedge requests starts in the Hedge Management Cockpit with the
Hedge Request button. Under the Hedge Request button, there are the following options,
each of which will trigger a hedge request.
● FX Swap Request
● FX Hedge Request
● DeDesignation Request

Figure 537: Automated Request Creation
When viewing a hedging area within the Hedge Management Cockpit, you see the Automated
Request Creation button on the Hedge Management Cockpit, which will also trigger hedge
requests to be created.
It is the Amount to Hedge key figure that will drive the hedge requests created. The Amount to
Hedge key figure is driven by the Target Quota amount minus the current outstanding
hedges.
The system uses the predefined hedging requirement settings to generate hedge requests in
the Hedging Area on the FX Hedge Request tab.
● Minimum amount
● Rounding rules
● Holiday Check for value dates
Manage Trade Requests
Figure 538: Manage Trade Requests
Once Treasury has validated the characteristics of the hedge request, the hedge request then
moves to the Manage Trade Requests app, which is part of the Trading Platform Integration.

The Manage Trade Requests app provides users with the functionality to import and process
trade requests that were created in the SAP back-end system. After processing in the Manage
Trade Requests app, the trade requests are sent to the front-office trading system.
You can use this app to do the following:
● Import trade requests from your back-end system
● Split a trade request into several new trade requests
● Create a block of trade requests
● Assign trade requests to a block
● Decline trade requests that were imported from your back-end system
● Send trade requests to external trading platforms
● Reset trade requests to their error status to make them available for editing again
● View trading platform details
There are also features available to share information with colleagues or to export data to
spreadsheets.
With the SAP Cloud Platform application Trading Platform Integration and the Manage Trade
Requests app, it is possible to split the trade information into several smaller items.
It is also possible to group trades into a block trade to be done on the external trading
platform. Larger trades may get a better rate in the market.
For trades that are executed over the phone, it is possible to enter the trade at the Trading
Platform Integration app. In this scenario, the front-office trading platform is not used
because the trade was executed instead over the phone and directly with the counterparty or
broker. The trade would then flow to the SAP system where it would be automatically created.
Once the trade requests are sent (by pressing the 'Send' button), they go to the front-office
trading system, such as 360T or FXAll. The traders then execute the trades on the front-office
trading system, then the trades are sent back to SAP, passing through the Manage Trades
SCP app. When the trades reach SAP, they are created on an automated basis, and then
back-office processing can begin.
Figure 539: Manage Trades
Trades executed on the front-office trading system, are sent through the Manage Trades app
before being sent to the SAP back-end system.
In the Manage Trades app, users can view and process trades that were automatically
imported from an external trading platform before the trade information is sent to the SAP
back-end system where a trade is created automatically.

Key features of the Manage Trades app include:

● View trades that were imported from an external trading platform
● Create and edit phone trades directly in the app
● Edit trades to add missing information
● Reprocess trades that could not be imported automatically into your back-end system
● Reset trades to their error status to make them available for editing again
● View trading platform details
The inbound service of the process ensures that the transactions from the trading platform
are imported into the Trading Platform Integration tool. Here a matching of the acquired data
to the original trade request is performed.
The trades are again assigned to a status. When the application receives a trade, the trade is
assigned the status In process. From there, if no errors occur, the trade is assigned the
status Successful. If an error occurs, you can use the activities provided to resolve the errors
and complete the trade.
Finally the information from the trade is forwarded from the Trading Platform Integration tool
to the SAP System. After all the information from the trade is mapped between the Trading
Platform Integration to the back-end system trading information where the trades are created
automatically and the Hedge Management Cockpit displays the updated trade information.
Trading Platform Integration
Figure 540: Activate Trading Platform Integration
When defining a Hedging Area using the Define Hedging Area app, there is an Activate Trading
Platform Integration indicator shown above. This indicator should be set to activate
integration with the Treasury Management Integration for Trading Platforms application.

Figure 541: Trading Platform Integration
The SAP Trading Platform Integration tool automates, streamlines, and simplifies trading
activities, ensuring complete end-to-end processing.
For more information, please see this video describing the Trading Platform Integration app -
https://video.sap.com/media/t/1_230y7tw2
For information on what needs to be done to get the application up and running please see the
Administrator's Guide - Integration with SAP S/4HANA Cloud that describes the steps a
system administrator must take to set up and configure the application with an SAP S/
4HANA system.
Additionally, Trading Platform Integration for SAP Treasury and Risk Management - 2F5 is an
enablement course on the Trading Platform Integration.
End-to-End Hedge Management Process
Figure 542: End-to-End Hedge Management Process
This section summarizes the end-to-end Hedge Management and Hedge Accounting process
for forecast cash flows in foreign currencies. The hedging instruments could be FX forward,
FX option, or FX swap contracts.
Note:
This is a review the Hedge Management Process from the Treasury and Risk
Management Business Processes course.
The treasury department is responsible for executing a given hedging policy for hedging the
risk of forecast cash flows in foreign currencies of future periods. The purpose of FX hedging
is to decrease foreign currency volatility in the P&L. The forecast itself is represented as
exposures in the Hedge Management Cockpit. A snapshot is taken for the forecast exposures
from Exposure Management. Based on the snapshot, net open exposure amount, risk
currency, and period are detailed in the Hedge Management Cockpit. Based on the hedging
policy rules, the net open exposures are reduced by trading financial instruments such as an
FX forward transaction. For expected inflows of a risk currency, the resulting exposure are
closed by a FX forward that sells the inflow currency and buys the local currency of the

company code. For expected outflows, a FX forward transaction is traded that buys the
outflow currency and sells the local currency.
On the contract date of the hedging transaction, or the start date of the hedging relationship,
it is designated into a hedging relationship as a hedging instrument together with the
exposure item of the Hedge Management Cockpit as Hedged Item. The matching exposure
item is determined based on characteristics of the Hedging Instrument. For example, the
hedging classification, type of hedging area determined (period-based versus reference-
based), position currency of financial transaction, and / or maturity of financial transaction all
are used to determine the exposure item. After the designation step, the status of the hedging
relationship is Planned Designation.
Also happening on the same day as the designation, when market data is available, the
hedging relationship is released. In this step, the following happens:
● Hypothetical derivative is created
● Hedge documentation created
● Effectiveness test executed
After the release step, the status of the hedging relationship is Designated and the hedging
relationship is now ready for upcoming period-end activities. The release step completes the
designation process.
At period-end, the determination of NPVs including the decomposition of market values for
Hedging Instrument and the Hypothetical Derivative are performed, and the key date
valuation of the FX forward transactions is executed. Meanwhile, the measurement and
postings of the Hedging Reserve (OCI I), Cost of Hedging Reserve (OCI II), and effectiveness
are executed on exposure subitem level. The period-end close can be executed using two
different procedures: valuation and classification with Reset or without Reset.
With the maturity of the FX forward transaction, the cumulated Hedging Reserve and Cost of
Hedging Reserve amounts are classified as frozen. At the end date of the Exposure Subitem,
the cumulated Hedging Reserve and Cost of Hedging Reserve amounts are to be reclassified
to profit or loss as a reclassification adjustment. The processing of the settlement flows of the
hedging instrument take place.
At the Balance Sheet Recognition Date, the Reclassification Flows are automatically created.
Depending on the rule that was set in the Hedging Area Definition, the Reclassification Flows
are posted immediately or at the Exposure Subitem End Date.
Figure 543: End-to-End Hedge Management Process

Pre-process setup:
● When the Treasury department knows its hedge policy, it can create the Hedging Area,
which is a sort of master data. For many companies, the hedge policy will not change from
year to year. The Hedging Area holds information such as the currencies hedged, the
target quota, the hedging instruments, if a front-office trading system such as 360T is
used, etc.
● The Hedging Area drives what is displayed in the Hedge Management Cockpit.
● The Hedge Management Cockpit gives Treasury a consolidated view of the exposures and
hedges across all relevant currencies and company codes.
Determine forecasts:
The determination of forecasts is a way for a business to estimate their future business and
cash flows. This process is typically done at the company code level and then aggregated by
the Treasury department. At most companies, the determination of forecasts is typically a
quarterly activity but it could be done at any time, and there is no restriction from a system
perspective.
● Collect and determine forecast (exposure) data
● Create exposures in SAP
● Take a Snapshot to record the exposures at the time of making a hedging decision.
● Review Net Open Exposure in Hedge Management Cockpit
Day of trade:
On the contract date of the trade, three steps happen: 1) the hedging contract is created, 2)
the designation process takes place, 3) the hedging relationship is released.
Creating hedging contract:
● Agree on a hedging instrument
● Check a Credit Risk Limit Utilization report (Optional) to make a decision on the
counterparties that can be used.
● Create FX hedging contract with a Hedging Classification assigned.
- Create deliverable FX forward transaction
- Create non-deliverable FX forward (NDF) transaction
- FX option contract
Designation is the process of creating Hedging Relationship(s). The hedging relationship is

the determination of an exposure(s) for the hedging instrument. It is the Designation Type
that drives the type of designation.
1. Automatic designation as trade is created
2. End-of-day designation with the Reprocess Financial Transaction for Automated

Designation (TPM104)
Release of designated Hedging Relationship (TPM120 must happen on the same day as the
designation of the trade). The release of the hedging relationship is a step because market
data is needed for this step and the market data may not be imported until later in the day.

● Hypothetical derivative is created

● Hedge documentation created
● Effectiveness test executed
● Hedging relationship changes from Planned Designation Hedge Relationship to Designated
● Hedging relationship is now ready for upcoming period-end activities
The release of the hedging relationship completes the designation process.

Period-end processing
The Period End Close Process of designated FX Transactions is executed by:
1. Calculation of NPV, Forward, CCBS, CVA/DVA key figures
2. Valuation of FX Transaction
3. Classification of Hedging Relationship
Maturity of Hedging Contract

De-designation of FX hedging contract:
● FX Forward Transaction: De-designation at Cash Settlement or Fixing Date.
● Cash Settlement for Deliverable Forward or Fix Rate for Non-Deliverable Forward.
● FX Option Transaction: De-designation at Exercise Date.
Maturity processing of the hedging contract, e.g. settlement of the FX forward contract.
On the Exposure Subitem End Date, which may be the same as the maturity date of the
hedging contract but does not need to be, the Reclassification of Hedging Reserve and Cost of
Hedging Reserve of Exposure Subitem take place.
Hedging Area
The Hedging Area is an element that represents a section of hedging policy of the company. It
defines which risk you want to monitor and on what level of granularity. Whether exposures
are shown on a net or gross basis in the Hedge Management Cockpit is derived from the
exposure aggregation level of the Hedging Area.
The Hedging Area provides visibility to hedged items and hedging instruments. It is the

The creation of a Hedging Area is a necessary requirement to start the process of Hedge
Management and Hedge Accounting.
The Hedging Area is a type of master data.
policy.
From the Hedge Management Cockpit, the user is able to get to the Hedging Area by pressing
the Hedging Area in the upper right corner of the Hedge Management Cockpit.
Hedge Management and Hedge Accounting
Figure 545: Hedge Management and Hedge Accounting: Determine Forecasts
Determine forecasts:
The determination of forecasts is a way for a business to estimate their future business and
cash flows. This process is typically done at the company code level and then aggregated by
the Treasury department. At most companies, the determination of forecasts is typically a
quarterly activity but it could be done at any time, and there is no restriction from a system
perspective.
● Collect and determine forecast (exposure) data.
● Create exposures in SAP.

Figure 546: Hedge Management and Hedge Accounting: From Snapshot to Hedge Management Cockpit
Snapshot:
● A snapshot is used to document the net open exposures at a certain point in time.
● A snapshot can be taken for one or many Hedging Areas at the same time.
● Key Date for taking the snapshot is the system date.
● If - after taking a snapshot - exposure data or the hedging instrument situation change, the
data stored in the snapshot do not change. This means: data shown in transaction TOENE
and data stored in the snapshot differ.
● All exposure items of a hedging area are stored with the snapshot.
● Only one hedge accounting relevant snapshot can be taken per day.
Hedge Management Cockpit:

The Hedge Management Cockpit makes use of the Hedging Area. The Hedging Area is the
central steering entity that controls hedge management and hedge accounting process. Key
Date is the starting date of the reporting periods shown and the validity of exposures and
hedging instruments. The Exposure Display Mode at the Hedging Area controls if exposures
are shown separated into positive and negative amounts or netted.
● The Hedging Area is the system mapping of specific areas of a companies hedging policy.
● The Hedging Area is fully versioned and certain changes are only allowed in a new version
or a new hedging area.
What you see in the Hedge Management Cockpit is influenced by the chosen layout, the
definitions of the hedging area, and the underlying snapshot.
● The SAP standard function for layouts is used.
● Two nearly identical layouts exist: Key Figures in rows versus in columns.
● Drilldown paths to Exposure and Hedges are provided.
● There is more information available to explain what you see.
● To change an existing layout, check the definition of a layout or create a new layout, a
function is available.

The Hedge Management Cockpit distinguishes Analysis and Exposure Items:

● The Exposure item summarizes exposures of the same kind.
● The Analysis Item summarizes different exposures following the requirements of analysis.
Hint:
Users with proper authorizations can drilldown path to Exposure Management
(Originating Exposure Application) from the Hedge Management Cockpit.
Hint:
If exposures are shown net or gross is derived from the Exposure Aggregation
Level of the Hedging Area.
The SAP standard function for layouts is used:

● The Layout definition is independent from Hedging Area.
● Layouts are either private (only available for one user) or public.
● The following functions are available for layouts (depending on authorization):display, edit,
delete, copy and create.
● Layouts delivered by SAP (starting with a number) can be used as a reference, but cannot
be changed.
● Layout ID plus description
→ SAP Layout starts with a number
● Snapshot Exposures controls how snapshots are read:
- Snapshot ID, last snapshot or last day relevant snapshot
● Selection Key Date controls with which date hedging instruments are read:
- Current date or entry of key date
● Display mode determines the design of the result table:
- Row: Key figures in Rows, Periods in columns
- Column: Key figures in Columns, Periods in columns
● Display Level:
- 0 → Characteristic not displayed
- 1 → Characteristic is used as key (column)
● Private Layout: The defined layout is user specific and will not be shown for other users.
● Periods → displays time buckets as defined in hedging area.
● Total → displays a sum across all time buckets.
● Total of Year → displays a sum of all time buckets in a calendar year.

● Display Level:
- 0 → key figure not displayed.
- 1 → key figure is used.
Figure 547: Hedge Management and Hedge Accounting:Designation Process (FX Risk) Flow
Animation: Hedge Management and Hedge Accounting:Designation Process (FX

Risk) Flow
For more information on Hedge Management and Hedge Accounting:Designation
Process (FX Risk) Flow, please view the animation in the lesson Understanding
the SAP Hedge Management Solution, online in the SAP Learning Hub.
The process steps 1 to 4 are explained in detail on the subsequent pages:
1. Create FX Transaction
2. Check: Hedge Accounting relevant?
3. Designation
● Automatic designation as trade is created.
● End-of-day designation with the Reprocess Financial Transaction for Automated

Designation (TPM104).
4. Release of Hedging Relationship
With the process, comprehensive analysis/ audit/ display functions are available.

Creation of Hedging Instrument
Figure 549: Creation of Hedging Instrument
Animation: Creation of Hedging Instrument

For more information on Creation of Hedging Instrument, please view the
From the Hedging Classification assigned on the Administration tab of the hedging
instrument, the Hedge Accounting relevance is determined.
When the hedging instrument is saved, the Hedge Management Cockpit is immediately
updated to reflect the trade. Assuming a period-based hedging area, note the period
associated with the hedging instrument's maturity date and the Net Hedges key figure for
period-based hedging areas.
Remember to press the Start button to recalculate the key figures in the Hedge Management
Cockpit.
Designation
Figure 551: Designation

Animation: Designation
For more information on Designation, please view the animation in the lesson
Understanding the SAP Hedge Management Solution, online in the SAP Learning
Hub.
The designation step is relevant to all hedging contracts where the Hedge Classification is
marked as 'Hedge Accounting relevant'.
The designation takes place on the contract date of the hedging instrument.
In the designation step, the exposure is determined and a hedging relationship is created.
There are two types of designations: Automatic or End-of-Day
1. Automatic designation as trade is created.
2. End-of-day designation with the Reprocess Financial Transaction for Automated

Designation (TPM104).
The type of designation is driven by the Designation Type. The designation type is driven by
the Hedging Area settings. (See Hedge Accounting II tab of the Hedging Area.)
Run Reprocess Financial Transaction for Automated Designation (TPM104) for any trades
with an EOD designation. Note: This program is also used to analyze and post-process any
error situation in creating a hedging relationship for the designation.
An exposure item is determined from a relevant Snapshot. This becomes the Hedged Item. It
is the following attributes of the hedging contract that are used for the determination of the
Exposure Item from the relevant snapshot of a valid Hedging Area version:
● Company Code
● Valuation Area
● Currency
● Value Date
● Hedging Classification
The Hedging Classification Settings of the Hedging Area (General Settings tab) are enhanced
by field Due Date Shift. Due Date Shift is an optional setting which is relevant for period based
Hedging Areas only:
The Due Date Shift moves the due date of the hedged item from one month to the next.
Due Date Shift methods are:
● EOMN1: Shift of Maturity Date of Hedged Item to End of next month.
● BOMN1: Shift of Maturity Date of Hedged Item to Beginning of next month.
According to the Due Date Shift method the Exposure Item Period is determined based on the
maturity date of the FX Transaction.
Example: The FX Transaction matures at end of August, but hedges a Net Exposure of the
Exposure Item Period of September

A hedging relationship is created. The Hedging Relationship represents the link between
Hedging Instrument and Hedged Item which holds general information and calculation
methods for Hedge Accounting processing.
In the designation step, the Hedging Relationship(s) are created in Planned Designation
status.
Figure 553: Release of Designation - Execute Report
Animation: Release of Designation - Execute Report

For more information on Release of Designation - Execute Report, please view
the animation in the lesson Understanding the SAP Hedge Management
Solution, online in the SAP Learning Hub.
Release of Designation - Execute Report: transaction TPM120.

The Release of the Hedging Relationship becomes necessary as a separate step as not all
relevant information, e.g. Market Data, might be available with the creation of the Hedging
Relationship.
Process Steps of the Release of the Hedging Relationship:
● Creation of Hypothetical Derivative
● Hedge documentation created (specified in the definition of the Hedging Profile)
● Prospective Effectiveness test executed (specified in the definition of the Hedging Profile)
● Calculation and saving of start values of FX Transaction at Designation Date
● Calculation and saving of start values of Hypothetical Derivative at Designation Date
● Create and post a valuation of involved FX Transactions for setting start values of relevant
Position Management Components at Designation Date (if set up in Hedging Profile)
● Determine and store the result of the check of the ‚Cost of Hedging Reserve Calculation
Rule', which determines the calculation and posting of the measurement result of „Cost of
Hedging Reserve" (OCI II)
● Create and post a valuation of involved FX Transactions for setting start values of relevant
Position Management Components at Designation Date

● Hedging relationship status changes from Planned Designation to Designated

● With the Release of Designation all relevant key figures are calculated and stored on
Hedging Relationship level in the ‚Market Data Container'
An Activity Log documents the results of the Release of the Hedging Relationship.
The release step completes the designation process.
Fixation of Planned Designation Flows
The Flow Details provide an overview on the created designated subpositions and its position
transfer flows in status ‚fixed'.
Note:
The Hypothetical Derivative is the representation of Hedged Item for
determination of hedging relevant information for Hedge Accounting Processing,
i.e. execution of measurement at period-end.
Hedge Management and Hedge Accounting Period End Close Process: Steps
Figure 555: Hedge Management and Hedge Accounting Period End Close Process: steps
At period end the determination of NPVs including the decomposition of the hedging
instrument and the hypothetical derivative is performed.
The key date valuation of the FX Forward Transactions is executed including the
measurement of ineffectiveness:
● Postings of the Hedging Reserve and Cost of Hedging Reserve amounts are created on
Exposure Subitem level and
● P/L ineffective amounts on Financial Transaction level
NPV: Net Present Value

CCBS: Cross Currency Basis Swap
CVA: Credit Valuation Adjustment
DVA: Debit Valuation Adjustment

Hedge Management and Hedge Accounting:Balance Sheet Crossover
Figure 556: Hedge Management and Hedge Accounting:Balance Sheet Crossover
At the Balance Sheet Recognition date, you run the app Release Hedging Business
Transactions, the following activities are done by this app:
● Calculation and saving of NPV of FX Transaction
● Calculation and saving of NPV component values for FX Transaction and Hypothetical
Derivative
● Posting of key date valuation of the designated portion of the FX Transaction with actual
NPV values
● Posting of classification of the selected Hedging Relationship with actual NPV component
values
● Update amounts of Reclassification Update Types
● Fix scheduled Reclassification Updated Types
Two options are provided for the reclassification of Balance Sheet Crossover, they are
maintained in field Balance Sheet Recognition on tab Hedge Accounting I of a Hedging Area:
1. Immediate Reclassification at Balance Sheet Recognition Date.
2. Reclassification at the End Date of the Exposure Subitem: the classification result between
Designation Date and Balance Sheet Recognition Date is frozen until end date of the
Exposure Subitem.

Hedge Management and Hedge Accounting:Contract Close
Figure 557: Hedge Management and Hedge Accounting:Contract Close
The dedesignation of the Hedging Relationship is executed at the maturity date of the FX
Transaction. The close of the FX Transaction is executed with the fixation and posting of
Derived Business Transactions via app Post Derived Business Transactions (TPM18).
A final measurement of the Hedging Relationship is executed at the maturity date of the FX
Transaction to report and post latest balances of Hedging Reserve and Cost of Hedging
Reserve amounts. As the FX Transaction is matured with the dedesignation, the balances of
Hedging Reserve and Cost of Hedging Reserve are frozen, this is reflected in the transfer of
the balances from the designated position component to the free-standing position
component of the Exposure Subitem.
The balance of the free-standing position component is the basis for the reclassification.
The Reclassification of the Hedging Reserve and Cost of Hedging Reserve position amounts is
executed at the end date of the Exposure Subitem within the Derived Business Transaction
Framework: the app Post Derived Business Transactions for the fixation and posting of
Derived Business Transactions selects the Exposure Subitem position flows to be reclassified.
Postings are created for reclassification of Hedging Reserve and Cost of Hedging Reserve
position amounts to profit or loss.

Hedge Management and Hedge Accounting:Position Reporting and Posting Journal
Figure 558: Hedge Management and Hedge Accounting:Position Reporting and Posting Journal
The newly processed and posted valuation and measurement results can be reported in
Position and Flow Reporting as well as Posting Journal.
The newly introduced Product Group 'Exposure Item' is included to the existing reporting
capabilities of Position Reporting, Flow Reporting and Posting Journal.
Transaction codes:
● Position Reporting: TPM12
● Flow Reporting: TPM13
● Posting Journal: TPM20
Review of Terms and Concepts
Figure 559: Review of Terms and Concepts
In this section, there is a review of terms and concepts.

The purpose of hedging is to decrease foreign currency volatility in the P&L.
The phases of a hedging relationship can be divided into the below three phases, which are:
● Inception of the hedging relationship.

● Ongoing life of hedging relationship.

● End of hedging relationship.
The Hedging Relationship represents the link between Hedging Instrument and Hedged Item
which holds general information and calculation methods for Hedge Accounting processing.
The Exposure Subitem represents the hedged portion of an Exposure Item within a hedging
relationship.
The Hedge Management Cockpit is based on exactly one hedging area. The Hedge
Management Cockpit incorporates the following data into one view:
● Exposures
● Hedges
● Hedging relationships (reflected in key figures)
● Company's hedge policy
The Hedging Area is master data that is used to represents a section of hedging policy of the
company. It defines the risk you want to monitor on which level of granularity. The settings of
the Hedging Area drive the output displayed in the Hedge Management Cockpit. The Hedge
Management Cockpit provides visibility to hedged items and hedging instruments. It is the
There are two types of hedging areas:
● Period-based
● Reference-based
The Hedging Classification determines the hedging area and the accounting that will be done
for the trade. The Hedging Classification is entered on the Administration tab of the hedging
instrument. All hedge classifications that are active for hedge accounting are hedging area. In
the hedging area definition, the hedging classifications are set on the General Settings tab.
A Snapshot is taken to record the exposures for a Hedging Area. After a snapshot is taken, the
exposures can be reviewed in the Hedge Management Cockpit.
Designation (either at trade entry or at EOD) is driven by the Designation Type:
● Designation as trade is created.
● EOD designation, Reprocess Financial Transaction for Automated Designation (TPM104).
Designation should be done on the contract date of the hedging instrument. In the
designation step, the Hedging Relationship(s) are created in Planned Designation status. The
Designation Type controls how instruments are treated during designation. The Designation
Type is set in the Hedging Area in the Designation Control section on the Hedge Accounting II
tab.
Release of designated Hedging Relationship (TPM120) must be done on the date of the
designation of the hedging instrument. It is a separate step because market data is needed for
this step and the market data may not be imported until later in the day.
● Hedging relationship changes from Planned Designation Hedge Relationship to
Designated.
● Hypothetical derivative is created.

● Hedge documentation created.

● Effectiveness test executed.
● Hedging relationship is now ready for upcoming period-end activities.
● The Designation Process is completed with the Release of the Hedging Relationship.
The Hypothetical Derivative is the representation of Hedged Item (the exposure being
hedged) for determination of hedging relevant information for Hedge Accounting Processing,
i.e. execution of measurement at period-end.
Exposure Item: Representation of Operational Exposure originated from the revenue forecast.
Exposure Subitem:
● Representation of the hedged portion of an Exposure Item within a hedging relationship
according to Hedging Area settings.
● The Exposure Subitem is introduced for Position Management purposes and is created
automatically as the due date for the reclassification of Hedging Reserve and Cost of
Hedging Reserve can be after the dedesignation date of the Hedging Relationship.
Hedging Profile is defined in customizing and drives all the parameters that control the Hedge
Accounting process, such as hedge documentation, effectiveness testing parameters,
Hedging Relationship Scenario, Hedge Accounting Rule and execution of valuation at
Contract Date.
The Hedging Profile is mapped (on tab Hedge Accounting II of Hedging Area) to the Hedging
Classification used in the hedging instrument.
The Hedging Profile drives:
● Calculations of hedging instrument
● Hedge documentation
● Effectiveness Test
Hedging Relationship Scenario is an SAP defined element that holds information about the
Hedge Relationship Category (Cash Flow Hedge), Hedged Item Category (forecasted item),
Hedge Accounting Rule (determines rules for measurement; hedging reserve, cost of hedging
reserve), cardinality of Hedging Relationship. The Hedging Relationship Scenario is set in the
Hedging Profile.
The Hedging Relationship Scenario describes a specific use case of a Hedging Relationship.
The Hedging Relationship Scenario is a component which holds information about:
Hedging Relationship Category: Cash Flow Hedge
Hedged Item Category: Planned Forecast
Hedge Accounting Rule: Determines the rules for measurement calculation.
● Hedging Reserve = Spot
● Cost of Hedging Reserve = Forward + CCBS
Cardinality of Hedging Relationship: 1 : n

Hedge Category, e.g. Cash Flow Hedges, Fair Value Hedges, or Hedges of a Net Investment.
Hedge Category is specified in the Hedging Relationship Scenario, which is assigned to the
Hedging Profile (in customizing).

Hedge Accounting Rule of the Hedging Relationship Scenario determines how the amounts of
Hedging Reserve and Cost of Hedging Reserve are calculated. The Hedge Accounting Rule
defined by SAP.
Hedge effectiveness is defined as the extent to which changes in the fair value or cash flows of
the hedging instrument offset changes in the fair value or cash flows of the hedged item.
Designate hedge relationship: Create a hedge relationship in order to obtain hedge
accounting. The most important task of the designation is the proper documentation of the
hedge relationship. The Designation Process is completed with the Release of the Hedging
Relationship.
De-designate hedge relationship: Eliminate a hedge relationship, due to the relationship not
being effective, modifications of any of the components of the hedge relationship or any other
circumstance. Any accumulated amounts in OCI stay in OCI.
Prospective effectiveness: Future effectiveness of a hedge relationship.
The market data required for the designation business transaction is grouped together in a
market data container.
The Hedged Item represents the portion of the underlying operational exposure after splitting
calculation. The splitting calculation is based on the Designation Splitting settings on the
Hedge Accounting I tab of the Hedging Area. The Exposure Item data was determined
automatically from the relevant version of the Hedging Area Snapshot.
The Hedging Instrument represents the FX derivative trade that was created for hedging the
operational Exposure Item. The portion of the FX Transaction nominal amount which is to be
designated into the Hedging Relationship is determined based on the settings of the
designation splitting of the Hedging Area.
Free Standing: Portion of a Financial Transaction which is not designated into a Hedging
Relationship.
Hedging Reserve: Other Comprehensive Income I is calculated based on the spot component
of a derivative transaction.
Cost of Hedging Reserve: Other Comprehensive Income II is calculated based on the forward
component of a derivative transaction.
OCI: Other Comprehensive Income is a component of equity in the financial statements where
the effective portion of the gain or loss on a derivative instrument designated and qualifying,
as a cash flow hedging instrument shall be reported.
Reclassification Date is the date the accumulated OCI is transferred to the P&L.
LESSON SUMMARY
and US GAAP


Unit 7
Lesson 3
Creating Reference Based Hedging Areas
LESSON OBJECTIVES
hedging areas
hedging areas
Reference Based Hedging Areas
Figure 560: Reference Based Hedging Areas
Referenced-based hedging areas are relevant to both IRFS9 and US GAAP accounting.
With Reference-based hedging areas, the hedging instrument is directly assigned to an
underlying exposure. This is as opposed to a period-based hedging area where the hedging
instrument hedges an exposure on a period basis.
Analysis items, also known as exposures, of the Hedge Management Cockpit are defined by
date reference. The analysis items contain one exposure item based on a non-aggregated
exposure position.
Notice that the exposure item is displayed with a due date, an ID and a description in the
Hedge Management Cockpit. This is important because the hedging transaction is assigned
to a specific exposure. The user is able to see the information required on the display of the
Hedge Management Cockpit.

Lesson: Creating Reference Based Hedging Areas
When you create a Hedging Area for reference-based exposure items, the following applies in
the definition of the Hedging Area:
● The risk-free currency is set to Local Currency by default and this cannot be changed.
● The exposure aggregation level is not available.
● The reporting time pattern is set to None by default.
● Target quotas are not needed, so the target quota is set to None by default. Consequently,
on the General Settings tab, the Relevant for Target Quota column is hidden.
On the General Settings tab, the differentiation criteria Currency and Company Code are
selected and you cannot add another differentiation criterion.
Specific Hedging Classifications are assigned to the Hedging Area:
● Hedge Accounting relevant for designation processing within a Hedging Relationship
● Non-Hedge Accounting relevant for Balance Sheet processing only

Data sources are available as filters for exposures and hedging instruments. They represent
the database tables to be accessed for the selection of exposures and hedging instruments
within the Hedge Management Cockpit
On the Filters for Exposures tab, the exposure data source must be reference based. The data
source field on the Filters for Exposures tab will be driven by the system based on the Analysis
Item Definition setting for the hedging area.
● E_EM2 Exposure Management 2.0 for period-based hedging
● E_EM2REF Exposure Management 2.0 for reference-based hedging
The Exposure Position Type entered on the Filter for Exposures tab MUST match the
Exposure Position Type of the exposure entered.
On the Hedge Accounting I tab, splitting is not relevant for reference-based hedging areas.
Also, on the Hedge Accounting I tab, the designation type is specified to drive the designation
of a FX Transaction into a Hedging Relationship. For reference-based exposures, Designation
Category One Instrument for Hedging Profiles for FX Forward Transactions is used.
Notice that the exposure item is displayed with a due date, an ID and a description in the
Hedge Management Cockpit. This is important because the hedging transaction is assigned
to a specific exposure. The user is able to see the information required on the display of the
Hedge Management Cockpit.
What is displayed in the Hedge Management Cockpit is a result of the layout used. The Layout
Category should be set to Single References for reference-based hedging areas.
When using a reference-based hedging area, the Hedge Management Cockpit for reference-
based Exposure Items displays key figures for:
● Net Exposure
● Net Hedges Net Open Exposure
● Designated Hedges
● Hedge Quota [%]
● Hedged Rate

SAP has delivered the Layout ID 1_REF_ALL to be used when a reference-based hedging area
is used in the Hedge Management Cockpit. This layout contains the key figures just
mentioned.
The hedging instruments are assigned to the analysis items by adding the hedged exposure
item ID on the FX Hedge Management tab of the financial transaction data as shown in the
screens above. With this assignment, the hedging contract is reflected in the Hedge
Management Cockpit.
Figure 565: Exposure Settings
A particular Exposure Activity Type is defined in configuration in Exposure Management 2.0

for the creation of reference-based exposures. The Raw Exposure Description is newly
introduced field that allows the user to define the purpose of the specific exposure Item in the
Hedge Management Cockpit. This field is specified in the Field Selection of the Exposure
Activity Type.
Activity Types.
In addition, a new Exposure Position Type is defined that fulfills the two prerequisites to
display as Exposure Items on its maturity date in the Hedge Management Cockpit:
1. The reference based Exposure Position shall not be aggregated.

2. No Planning Period flag shall be set.
Position Types.
As an additional step, it may be necessary to create Derivation Strategies to derive fields such
as the Exposure Position Type, which would be done using the Define Exposure Fields
Derivation Strategy configuration.
fields Derivation Strategies.
Hedging Classifications
Figure 566: Hedging Classifications
The Hedging Classification is a key field in the hedge management process.

The Hedging Classification is the entity which is responsible for Hedge Management and
Hedge Accounting processing. A Hedging Classification that is hedge accounting relevant can
only be assigned to one Hedging Area.
The definition of the Hedging Classification includes a description and a flag indicating if the
Hedging Classification if relevant to Hedge Accounting.
In the definition of your Hedging Area (using the app Define Hedging Area), the relevant
Hedging Classifications are assigned on the General Settings tab. See the Hedging
Classifications sub-box of the Hedging Area on the General Settings tab, which is shown
above.
The Hedging Classification settings of the Hedging Area are enhanced by field Due Date Shift.
The Due Date Shift is an optional setting which is relevant for period-based Hedging Areas
only. The Due Date Shift moves the due date of the hedged item from one month to the next.
Due Date Shift methods are:
● BOMN1: Shift of Maturity Date of Hedged Item to Beginning of next month
● EOMN1: Shift of Maturity Date of Hedged Item to End of next month
● EOMP1: Shift of Maturity Date of Hedged Item to End of Previous month
Additionally the Due Date Shift method influences the determination of the Exposure Item
Period and the maturity Date of the Hypothetical Derivative.

The Hedging Classifications are created using the customizing path Financial Supply Chain
→ Hedge Management → Define Hedging Classifications.
When an FX hedge contract is created, the Hedging Classification is assigned as additional

attribute on the Administration tab, as shown above.
If the Hedging Classification is active for hedge accounting, this information is relevant for the
automated designation process. Using the data from the FX hedge contract including the
hedging classification, the system can identify the relevant hedging area version and the
relevant exposure item so that the hedged item, hedging instrument, hedging relationship,
and the planned designation flows can be created according to your settings for the hedging
area.
You can define derivation rules for the hedging classification under Define Derivation Rules for
Hedging Classifications to automatically fill the hedging classification field during the creation
of financial transactions.
Transaction Manage r→ General Settings → Transaction Management → Derivation of
Hedging Classification → Define Derivation Rules for Hedging Classifications.

The hedging classification is a characteristic available for Automated Determination of the

Account Assignment Reference configuration. This allows the automatic determination of
different Account Assignment References, e.g. for FX Transactions which are used as
Hedging Instruments for different Hedging Categories, e.g. Cash Flow Hedges, Fair Value
Hedges, or Hedges of a Net Investment. The Account Assignment Reference is a key field in
the trade to drive the accounting of the financial transaction.
With the hedging classification as a field in the Automated Determination of the Account
Assignment Reference configuration, configuration can easily be set to have different G/L
accounts used for accounting for trades depending on the hedging classification.
Transaction Manager → General Settings → Accounting → Link to Other Accounting
Components → Define Account Assignment Reference Determination.
Create Hedging Classification
Simulation: Create Hedging Classification

For more information on Create Hedging Classification, please view the
simulation in the lesson Creating Reference Based Hedging Areas online in the
SAP Learning Hub.

Unit 7
Exercise 30
Business Example
As the SAP support person for the Treasury department, you have been asked to meet the
requirements of the department around micro hedges, which are hedges that are made to
hedge a specific exposure. (The micro-hedges are executed using Reference-Based Hedging
Areas.)
To meet these requirements, you will create a specific hedging classification. The Hedging
Classification is a key field in the hedge management process.
Note:
1. Create a new Hedging Classification using the following information:
Table 87: Hedging Classification Data

Field Name Value
Hedging Classification HCR##
Description FX Risk; CFH; Spot, Forward + CCBS;
Group ##
Hedge Accounting <Active>

Unit 7
Solution 30
Business Example
As the SAP support person for the Treasury department, you have been asked to meet the
requirements of the department around micro hedges, which are hedges that are made to
hedge a specific exposure. (The micro-hedges are executed using Reference-Based Hedging
Areas.)
To meet these requirements, you will create a specific hedging classification. The Hedging
Classification is a key field in the hedge management process.
Note:
1. Create a new Hedging Classification using the following information:
Table 87: Hedging Classification Data

Field Name Value
Hedging Classification HCR##
Description FX Risk; CFH; Spot, Forward + CCBS;
Group ##
Hedge Accounting <Active>
a) Navigate to the following customizing path: Financial Supply Chain Management →

Treasury and Risk Management → Transaction Manager → General Settings → Hedge
Management → Define Hedging Classifications.
b) Create a new Hedging Classification using the information provided in the table
Hedging Classification Data.
Note:
A Hedging Classification that is hedge accounting relevant can only be
assigned to one Hedging Area.

Unit 7
Exercise 31
Create a Reference-Based Hedging Area
Business Example
The Hedging Area is an entity that represents a section of hedging policy of the company. The
creation of a Hedging Area is a necessary requirement to start the process of Hedge
Management and Hedge Accounting. It is the central steering entity that contains all relevant
settings for this process.
As was discussed in the lesson, there are two types of Hedging Areas:
● Period-based
● Reference-based
You have an exposure that will happen on a specific date in the future, and you want to hedge
this exposure specifically. Reference-based hedging areas allow the hedging instrument to be
directly assigned to an underlying exposure.
Dependencies: Create Exposure Activity Type and Reference Based Exposure and Create
Hedging Classification with Automatic Determination.
1. Create the new Hedging Area using the following information:
Table 88: Create Hedging Area 1

Field Name Value
Hedging Area HAR_##
Version 1

Screen Field Name Value
Create Hedging Area Hedging Area HAR_##
Description Hedging Area ## - Refer-
ence Based
Authorization Group HAG01
Valid From 01.01 of current year
Analysis Item Def By Reference
Without Template <select>
2. On the Main Data tab of the Hedging Area, determine basic settings such as the Risk
Category, whether Hedge Accounting is performed, if there is integration with a front-
office trading system and Trading Platform Integration. Use the following data:

Table 90: Main Data Information

Tab Area Field Name Value
Memo Memo Hedge Policy <cur-
rent year>
Main Data Integration Hedge Accounting <select>
Product Type for Ex- 91A
posure Subitems
Activate Trading <Not selected>
Platform Integration
Consideration of Fi- Consider Hedging Value Date of Hedg-
nancial Transactions Instrument Until ing Instrument
Target Quota <none>
3. On the General Settings tab, notice that the differentiation Criteria are set to Company
Code and Currency and cannot be changed.
policy. However, a hedge accounting relevant Hedging Classification can only be assigned
to one Hedging Area for Hedge Accounting, therefore creating additional Hedging Area for
Hedge Accounting means the necessity of defining additional Hedging Classifications.
Define general settings using the following data:
Table 91: General Settings Information

General Settings Company Code TA##
Differentiation Crite- Currency <select>
ria
Company Code <select>
Hedging Classifica- Hedging Classifica- HCR##
tion tion
4. On the Currencies tab, specify the currencies that will be hedged. Use the following data:
Table 92: Currencies Information

Currencies Hedge-Relevant Cur- Currency USD
rencies
Currency Group USD
5. On the Filter for Exposures tab, determine the sources of Exposures and limit the objects
transferred to the Hedging area.
Currently, the Exposure Management 2.0 is available as a source for Hedged Items. The
data source field on the Filters for Exposures tab will be driven by the system based on the

Analysis Item Definition setting for the hedging area, which in this case was set to By
Reference, and should be set to E_EM2REF.
Use the following information to create Filters for Exposures:
Table 93: Filters for Exposures Information 1

Filters for Exposures Filter List for Expo- Filter TA## Exposures
sures
Filter Description TA## Reference Ex-
posures
Source E_EM2REF

Filters for Exposures Filter Specific Re- Company Code TA##
strictions of General
Selections
Other Filters Exposure Position YFX_R
Type
6. On the Filter for Hedges tab, determine the sources of the Hedges and limit the objects
Currently, the Transaction Manager module is available as a source for Hedging
Instruments. Use the following information:
Table 95: Filters for Hedges Information 1

Filters for Hedges New Filter for Hedg- Filter TA## Hedges
es
Filter Description TA## Hedges
Source H_TM

Filters Details Filter Specific Re- Company Code TA##
Selections
Other Filters Product Type 60A
7. Skip the FX Hedge Request tab.

In this case, the Trading Platform Integration has not been activated so the FX Hedge
Request tab will not be filled out, as it is not relevant without the Trading Platform
Integration.
8. The Hedge Accounting I information allows the user to specify important details for Hedge
Accounting: which company code(s) and Valuation area Hedge accounting is performed
and if splitting and designation are active. For reference-based hedging areas, splitting is
not relevant. Define Hedge Accounting I information, using the following data:
Table 97: Hedge Accounting I Information

Hedge Accounting I Designation Level Company Code TA##
Valuation Area 001
Splitting <leave blank!!>
Sequence N
Designation Activa- Company Code TA##
tion
Valuation Area 001
Currency USD
Designation 1 (active)
9. In the Designation Control area on the Hedge Accounting II, the Company Code, Valuation
area, Hedging Classification, Designation Type, and Hedging Profile are assigned. Define
Hedge Accounting II information, using the following data:
Table 98: Hedge Accounting II Information

Hedge Accounting II Designation Control Company Code TA##
Valuation Area 001
Hedg Class HCR##
Designation Type YFX1W
HdgProfile F00
MDS ID <blank>

Unit 7
Solution 31
Business Example
The Hedging Area is an entity that represents a section of hedging policy of the company. The
creation of a Hedging Area is a necessary requirement to start the process of Hedge
Management and Hedge Accounting. It is the central steering entity that contains all relevant
settings for this process.
As was discussed in the lesson, there are two types of Hedging Areas:
● Period-based
● Reference-based
You have an exposure that will happen on a specific date in the future, and you want to hedge
this exposure specifically. Reference-based hedging areas allow the hedging instrument to be
directly assigned to an underlying exposure.
Dependencies: Create Exposure Activity Type and Reference Based Exposure and Create
Hedging Classification with Automatic Determination.
1. Create the new Hedging Area using the following information:

Field Name Value
Hedging Area HAR_##
Version 1

Create Hedging Area Hedging Area HAR_##
Description Hedging Area ## - Refer-
ence Based
Authorization Group HAG01
Valid From 01.01 of current year
Analysis Item Def By Reference
Without Template <select>
a) Choose the Hedging Area app (Treasury - Hedge Management).

b) Create the new Hedging Area using the data provided in the table Create Hedging Area
1.
c) Choose the Create button.
d) On the pop-up window, enter the information provided in the table Create Hedging
Area 2.
e) Choose the Create button at the bottom right of pop-up window.
2. On the Main Data tab of the Hedging Area, determine basic settings such as the Risk
Category, whether Hedge Accounting is performed, if there is integration with a front-
office trading system and Trading Platform Integration. Use the following data:
Table 90: Main Data Information

Memo Memo Hedge Policy <cur-
rent year>
Main Data Integration Hedge Accounting <select>
Product Type for Ex- 91A
posure Subitems
Activate Trading <Not selected>
Platform Integration
Consideration of Fi- Consider Hedging Value Date of Hedg-
nancial Transactions Instrument Until ing Instrument
Target Quota <none>
3. On the General Settings tab, notice that the differentiation Criteria are set to Company
Code and Currency and cannot be changed.
policy. However, a hedge accounting relevant Hedging Classification can only be assigned
to one Hedging Area for Hedge Accounting, therefore creating additional Hedging Area for
Hedge Accounting means the necessity of defining additional Hedging Classifications.
Define general settings using the following data:
Table 91: General Settings Information

General Settings Company Code TA##
Differentiation Crite- Currency <select>
ria
Company Code <select>
Hedging Classifica- Hedging Classifica- HCR##
tion tion
a) Navigate to the General Settings tab.
b) Enter the data provided in the table General Settings Information.

4. On the Currencies tab, specify the currencies that will be hedged. Use the following data:
Table 92: Currencies Information

Currencies Hedge-Relevant Cur- Currency USD
rencies
Currency Group USD
a) To insert the currency information, use the Add Currency button for each entry to
create an additional line of data.
b) Then, select the currency using the selection button, or the F4 help in the data field
Currency, or key it in.
5. On the Filter for Exposures tab, determine the sources of Exposures and limit the objects
Currently, the Exposure Management 2.0 is available as a source for Hedged Items. The
data source field on the Filters for Exposures tab will be driven by the system based on the
Analysis Item Definition setting for the hedging area, which in this case was set to By
Reference, and should be set to E_EM2REF.
Use the following information to create Filters for Exposures:

Filters for Exposures Filter List for Expo- Filter TA## Exposures
sures
Filter Description TA## Reference Ex-
posures
Source E_EM2REF

Filters for Exposures Filter Specific Re- Company Code TA##
Selections
Other Filters Exposure Position YFX_R
Type
a) Navigate to the Filter for Exposures tab.
b) Enter the data provided in the table Filters for Exposures Information 1.
c) Choose the Create Filter button on the pop-up window.
d) Press the Enter key and enter the data provided in the table Filters for Exposures
Information 2.

6. On the Filter for Hedges tab, determine the sources of the Hedges and limit the objects
Currently, the Transaction Manager module is available as a source for Hedging
Instruments. Use the following information:

Filters for Hedges New Filter for Hedg- Filter TA## Hedges
es
Filter Description TA## Hedges
Source H_TM

Filters Details Filter Specific Re- Company Code TA##
Selections
Other Filters Product Type 60A
a) Navigate to the Filter for Hedges tab.
b) Choose the + icon and enter the data provided in the table Filters for Hedges
Information 1.
c) Choose the Create Filter button on the pop-up window.
d) Press the Enter key and enter the data provided in the table Filters for Hedges
Information 2.
7. Skip the FX Hedge Request tab.

In this case, the Trading Platform Integration has not been activated so the FX Hedge
Request tab will not be filled out, as it is not relevant without the Trading Platform
Integration.
8. The Hedge Accounting I information allows the user to specify important details for Hedge
Accounting: which company code(s) and Valuation area Hedge accounting is performed
and if splitting and designation are active. For reference-based hedging areas, splitting is
not relevant. Define Hedge Accounting I information, using the following data:
Table 97: Hedge Accounting I Information

Hedge Accounting I Designation Level Company Code TA##
Valuation Area 001
Splitting <leave blank!!>
Sequence N


Designation Activa- Company Code TA##
tion
Valuation Area 001
Currency USD
Designation 1 (active)
a) Navigate to the Hedge Accounting I tab.
b) Enter the data provided in the table Hedge Accounting I Information, choosing the +
(Insert) icon to add a row.
9. In the Designation Control area on the Hedge Accounting II, the Company Code, Valuation
area, Hedging Classification, Designation Type, and Hedging Profile are assigned. Define
Hedge Accounting II information, using the following data:
Table 98: Hedge Accounting II Information

Hedge Accounting II Designation Control Company Code TA##
Valuation Area 001
Hedg Class HCR##
Designation Type YFX1W
HdgProfile F00
MDS ID <blank>
a) Navigate to the Hedge Accounting II tab.
b) Enter the data provided in the table Hedge Accounting II Information.
c) Choose the Check button to validate that there are no errors in the data entered.
d) Choose the Save button on the lower right corner to save the Hedging Area.

Simulation: Create a Reference-Based Hedging Area

For more information on Create a Reference-Based Hedging Area, please view
the simulation in the lesson Creating Reference Based Hedging Areas online in

LESSON SUMMARY
hedging areas
hedging areas

Unit 7
Lesson 4
Customizing Hedge Management Elements
LESSON OBJECTIVES
Designation Types
Figure 572: End-of-Day Designation
For customers that want to be able to change their exposures throughout the day, and not
have the hedging relationships created until later in the day, the end-of-day designation
setting can be used.
There are two options on when the designation takes place:
1. As the hedge trade is saved. (EOD Designation indicator is not selected.)
2. When the reprocessing program is run at the end of day. (EOD Designation indicator is
selected.)
It is with the designation step that a hedging relationship is created.

With end-of-day designation, the hedge is created but a hedging relationship is not created at
this point in time. The designation, and thus when the hedging relationship is created,
happens when the Reprocess Transactions Automated Designation report (TPM104) is
executed. This functionality allows Treasury to change the exposures throughout the day and,
thus, take several snapshots a day with the Day Reference indicator.

Lesson: Customizing Hedge Management Elements
Note:
When the EOD designation setting is on, there is a warning message
(Reprocessing of financial transaction required) when the trade is saved indicating
that the Reprocessing of Financial transaction is required.
Figure 573: Designation Types
The Designation Type, shown above, is defined in configuration. It controls how instruments
are treated during the designation process. The designation process is when the exposures
and hedges are linked to form a hedging relationship.
Designation Types control the following:
1. The Designation Type drives how many instruments can be designated together into one
The Designation Category has the following options:
● One Instrument Designation Pattern (one hedging instrument links to one exposure)
● Two Instruments (Collar) Designation Pattern
● N Instruments (Swap) Designation Pattern
2. If end-of-day designation is used, the indicator should be set.
3. If counter-confirmation is required before a hedging relationship can be released. If this

indicator is set, the hedging relationship can be released only after the FX transaction has
been successfully counter-confirmed.
For Designation Types used in Reference Based Hedging Areas, the Designation Category
must be set to One Instrument Designation Pattern. This is because, by definition, in
Reference Based Hedging Areas there is one hedging instrument to hedge one exposure.
If the indicator to set counter-confirmation as required is selected, be sure to select the status
of FX transaction to 'Counter confirmed' automatically after receiving the incoming
confirmation from counter-party. This Automatic Settlement on Counter-confirmation
configuration setting is at the Define Transaction Type level of the FX trade type.
Note:
All designation types relevant for a hedging area must have the same settings
concerning the end-of-day designation. They all provide either for end-of-day
designation or for immediate designation.
Transaction Manager → General Settings → Hedge Accounting for Positions → Settings for
Automated Designation of Exposure Items (FX Risk) → Define Designation Types.

Figure 574: Designation Types
The Designation Type which is specified on tab Hedge Accounting II of Hedging Area and is
assigned in combination with a Hedging Classification and a Hedging Profile.
In the Hedging Area data on the Hedge Accounting II tab, the Designation Type is assigned for
a combination of the values of the following criteria:
● Company code
● Valuation area
● Company code on behalf of which the financial transaction is created
● Hedging classification
Define Additional Hedge Management Elements
Figure 575: Define Hedging Profile
The Hedging Profile is a central customizing entity of Hedge Accounting for Positions which
holds information about how to process Hedging Relationships.
The Hedging Profile is a customizing entity which contains all the parameters that control the
Hedge Accounting process, i.e., entry and management of the hedging relationship's header
data, the execution of valuation on the contract date, the hedging scenario, the type of
documentation to be generated, and the rules of the effectiveness test.
Below are some of the fields set in the definition of a hedging profile:

● Scenario: The hedging scenario contains the complete Hedge Accounting logic, i.e., the
type of hedge involved (e.g., fair value hedge, cash flow hedge), product categories
supported in the hedging scenario, permitted cardinalities of hedged items for hedge
transactions, option of a rollover, and effect of Hedge Accountings on valuation for
accounting purposes.
● Test Plan Category: Contains a list of points in time during the term of a hedging
relationship when effectiveness tests can or must be performed.
● Prospective Effectiveness Method and Retrospective Effectiveness Method fields - All
settings used for effectiveness tests.
● Effectiveness testing for derived business transactions.
● Hypothetical derivative category - For cash flow hedges, this parameter controls whether
the hypothetical derivative is to be created with a net present value of zero or with the net
present value of the hedging instrument at the time of designation.
● Effectiveness testing validity period - The validity period for the effectiveness test indicates
the maximum permitted period (in days) for an effectiveness test, which applies when the
valuation for accounting purposes searches for the effectiveness tests of a hedging
relationship before applying the hedge accounting rules.
The hedging profile is defined in SAP customizing under the path Financial Supply Chain
→ Hedge Accounting for Positions → Settings for Automated Exposure Item Hedging (FX
Risk) → Define Hedging Profile.
Figure 576: Define Hedging Profiles
With the exercise of a FX Option an underlying FX Spot Transaction is designated into the
existing Hedging Relationship:
● The Hedging Profile definition is enhanced by an additional attribute 'Hedging Profile
Underlying'.
● The 'Hedging Profile Underlying' determines the Hedge Accounting Rule of the underlying
for Component Calculations at FX Option Exercise and Classification at Period End Close.
Transaction Manager → General Settings → Hedge Accounting for Positions → Define
Hedging Profiles.

Figure 577: Hedge Documentation
Whether hedge documentation is created or not is driven by settings in the Hedging Profile.
Hedge Documentation is created only if flag ‚Semi Automatic Documentation is activated.
Under Documentation Handling, you can set documentation as optional by selecting the
Documentation Optional checkbox. If you make this setting, documentation is not a
prerequisite for the release of the designation.
To ensure that documentation is created for the designation, do not select the
Documentation Optional parameter in the profile of the hedging relationship. This means that
you can now fix and post a designation transaction only if documentation exists for this
transaction.
SAP provides Adobe template forms that customers can copy to create their own Hedge
Documentation form. Below are the two SAP delivered Adobe hedge documentation forms:
● FX Forward: TR_F_THX_NOTE_HREL_FXRISK_FX
● FX Option: TR_F_THX_NOTE_HREL_FXRISK_OP
SAP provides Hedge Documentation templates as .pdf form for FX Forward and FX Options as
Hedging Instruments to be copied and adapted to meet customer's needs.
The creation of Hedge Documentation is included as an additional process step with the
Release of the Hedging Relationship. The Hedge Documentation is created automatically and
can be accessed in the Manage Hedging Relationships (TPM100).
Note:
As the creation of the Hedge Documentation is part of the automated processing
it can not be changed manually in the Manage Hedging Relationships. The Release
of the Hedging Relationship needs to be reversed; this changes the status of the
Hedge Documentation to revoked.

Figure 578: Hedging Profile Assignment in Hedging Area
As a reminder, for a hedging relationship, the Hedging Profile is derived from these steps:
1. The Hedging Classification entered in the trade determines the Hedging Area.
2. The settings in the Designation Control section on the Hedge Accounting II tab of the
Hedging Area are used to derive the Hedging Profile based on a combination of the
following criteria:
● Valuation area
Figure 579: Define Hedging Scenario
The Hedging Scenario is not configurable (it is defined by SAP) but it is worth pointing out in
more detail.
The Hedging Relationship Scenario is a system defined entity which holds information about:
● Hedging Relationship Category: Cash Flow Hedge / Fair Value Hedge / Net Investment
Hedge.
● Hedged Item Category: Planned Forecast / Balance Sheet Item.
● Hedge Accounting Rule (see below).
● Risk Details: Currency Risk.
It is the Hedge Accounting Rule specified in the Hedging Relationship Scenario determines
how the amounts of Hedging Reserve and Cost of Hedging Reserve are calculated.
Hedging Reserve: Designated Component.
Cost of Hedging Reserve: Non-designated Component.

Rule for Calculating Cost of Hedging Reserve:

● The result of the 'Cost of Hedging Reserve Calculation Rule' check determines the
calculation and posting of the measurement result of ‚Cost of Hedging Reserve (OCI II).
● Depending on the assigned Hedge Accounting Rule, the relevant elements and/or
components of the hedging instrument (actual values) are compared against the
corresponding values of the hypothetical derivative (aligned values).
● One of the following calculation rules is then applied to determine the amounts that are
posted to the cost of hedging reserve:
1. Actual Value = Aligned Value

The change in the amount of the actual value is posted to the cost of hedging reserve.
2. Actual Value > Aligned Value

The change in the amount of the aligned value is posted to the cost of hedging reserve.
3. Aligned Value > Actual Value

The cost of hedging reserve is determined based on the lower-of test. The smaller
amount of the actual and aligned value is posted to the cost of hedging reserve, and the
remaining amount is posted to the P/L statement.
Example:
If the hedge accounting rule 611 was assigned to the hedging scenario, the calculation rule of
the cost of hedging reserve is determined based on the comparison result of the following
elements:(Forward + CCBS) of the hedging instrument vs. (Forward + CCBS) of the
hypothetical derivative.
Effectiveness Test Method
Figure 580: Effectiveness Test Method
In the Effectiveness Test Method customizing activity, the effectiveness test methods are
defined. The Effectiveness Test Methods are then assigned in the Hedging Profile. It is then
the Hedging Profile that is assigned to the hedging relationship and driving the effectiveness
test settings for the hedging relationship.
The main take aways from this slide are that the effectiveness test methods are configurable,
they are set in the Hedging Profile, and SAP supports the most basic effectiveness test such
as the Dollar Offset method to linear regression with Market Data Scenarios (MDSs), which

allow for many market data scenarios to be tested and factored into the effectiveness testing.
This is a sort of stress test within the effectiveness test.
Whether an effectiveness test is based on period-to-period or cumulative is specified in the
definition.
Lastly, if linear regression is used, the parameters of the linear regression are specified in the
effectiveness definition.
Transaction Manager → General Settings → Hedge Accounting for Positions → Effectiveness
Test → Effectiveness Test Method.
Update Types for Hedging Business Transaction
Figure 581: Define Update Types for Hedging Business Transaction
The Hedging Business Transactions are designate, de-designate, classify, re-classification,

swap transfer, etc. These business transactions are used in position management to track the
business transactions. Hedge Accounting interacts with the other components in position
management by triggering Derived Business Transactions in some cases. Key actions in
Hedge Accounting generate original business transactions (designate, de-designate, classify,
etc.), which trigger Derived Business Transactions. For example, designation and de-
designation are original business transactions with associated derived business transaction
flows, such as original transactions of transaction or position management.
In addition, specific to FX options, de-designation transfer and designation transfer are two
Hedging Business Transactions.
● Dedesignation Transfer: Transfer out component values from exercised FX Option.
● Designation Transfer: Transfer in component values to underlying FX Spot/Forward
Transaction.
In this customizing step, associated update types are defined and assigned for each of these
Hedging Business Transactions.
Update types used in hedge management position management are defined (1) and then
assigned the usage Hedge Accounting for Positions (2). For the assignment of update types
for Hedging Business Transactions, the update types are assigned at the product type level
(3).

As mentioned, the update types defined here are used for position management and do not
transfer to the SAP general ledger. The business transaction, e.g. re-classification, is triggered
using the updates types defined here then a corresponding Transfers derived business
transaction flow is created and posted to the SAP general ledger.
For example, when the sub-position is created within the designation, classification, etc., the
position components that exist at this point in time are transfer posted in accordance with the
nominal values. A derived business transaction is generated for the relevant original business
transaction, which, like all other derived business transactions, is configured in customizing. It
is the corresponding derived business transaction flow is created and then posted to the SAP
general ledger.
For more information on the derived business transaction settings related to hedge
management, please see the lesson on Hedge Management Account Determination.
Define and assign the usage for the Hedging Business Transactions by following the IMG path
Manager → General Settings → Hedge Accounting for Positions → Update Types → Define
Update Types and Assign Usages.
Define and assign the usage for the Hedging Business Transactions by following the IMG path
Manager → General Settings → Hedge Accounting for Positions → Update Types → Assign
Update Types for Business Transactions (P-HA) to Product Types.
Product Types for Exposure Subitems
Figure 582: Define Product Types for Exposure Subitems
The Exposure Subitem represents the hedged portion of an Exposure Item within a hedging
relationship and is specified in the Hedging Area definition.
A Product Category ‚Exposure Item' is introduced to enable Position Management and
Accounting Processes on Exposure Subitem level. The Exposure Subitem represents the
hedged portion of an Exposure Item within a hedging relationship. The product category 991
must be used for the subitem product type.
The product types for exposure subitem product type are defined in the SAP customizing by
following the path Financial Supply Chain Management → Treasury and Risk Management →
Transaction Manager → General Settings → Hedge Accounting for Positions → Settings for
Automated Exposure Item Hedging (FX Risk) → Define Product types for Exposure Subitems.
The exposure subitem requires the same definitions, such as a position management
procedure that is defined and assigned, a default general valuation class, an account

assignment reference, etc., as would be required for a new product type in Transaction
Manager.
Customize Hedge Management
Simulation: Customize Hedge Management

For more information on Customize Hedge Management, please view the
simulation in the lesson Customizing Hedge Management Elements online in the
SAP Learning Hub.


Unit 7
Exercise 32
Business Example
In this exercise, you will create a Designation Type and a Hedging Profile, which you will then
use in the next exercise.
The Designation Type controls how instruments are treated during the designation process.
The designation process is when the exposures and hedges are linked to form a hedging
relationship.
holds information about how to process Hedging Relationships. It is an entity that contains all
the parameters that control the Hedge Accounting process, i.e., entry and management of the
hedging relationship’s header data, the execution of valuation on the contract date, the
hedging scenario, the type of documentation to be generated, and the rules of the
effectiveness test.
Note:
1. Create a Designation Type using the following information:
Table 99: Designation Type Data

Field Name Value
Des. Type Y##1W
Description Designation of a single Hedging Instrument
w/o counterconf. ##
Designation Category One Instrument Designation
Req. CConf <blank>
EOD Des. <blank>
2. Create a Hedging Profile using the following information:

Table 100: Hedging Profile Data

Field Name Value
Hedging Profile X##
Maintenance View for Hedg- Profile Description Group ##; Forward + CCBS,
ing Relationship Profiles Cash Flow Hedge
Scenario CFH: FX Risk with Spot, For-
ward + CCBS
Test Plan Category Effectiveness Testing is Dis-
abled (such as Shortcut
Method)
Test Plan Rhythm Monthly
Eff Test Handling in DBTs Simulate ‘Always Effective’
if no ET is Available
Calculation Type Calculation Type: from Cur-
rency = Leading Currency
Apply Critical Terms Match Critical term match is not
set automatically
Documentation Handling Semi-Automatic Documen- <select>
tation
PDF-Based Forms: Form TR_F_THX_NOTE_HREL
Name
Note:
Leave any fields not listed in the table blank.

Unit 7
Solution 32
Business Example
In this exercise, you will create a Designation Type and a Hedging Profile, which you will then
use in the next exercise.
The Designation Type controls how instruments are treated during the designation process.
The designation process is when the exposures and hedges are linked to form a hedging
relationship.
holds information about how to process Hedging Relationships. It is an entity that contains all
the parameters that control the Hedge Accounting process, i.e., entry and management of the
hedging relationship’s header data, the execution of valuation on the contract date, the
hedging scenario, the type of documentation to be generated, and the rules of the
effectiveness test.
Note:
1. Create a Designation Type using the following information:
Table 99: Designation Type Data

Field Name Value
Des. Type Y##1W
Description Designation of a single Hedging Instrument
w/o counterconf. ##
Designation Category One Instrument Designation
Req. CConf <blank>
EOD Des. <blank>
a) Go to the customizing under the path: Financial Supply Chain Management → Treasury
and Risk Management → Transaction Manager → General Settings → Hedge
Accounting for Positions → Settings for Automated Designation of Exposure Items (FX
Risk) → Define Designation Types.

b) Choose the New Entries button and create the Designation Type with the information
provided in the table Designation Type Data.
c) Choose Save.
2. Create a Hedging Profile using the following information:
Table 100: Hedging Profile Data

Field Name Value
Hedging Profile X##
Maintenance View for Hedg- Profile Description Group ##; Forward + CCBS,
ing Relationship Profiles Cash Flow Hedge
Scenario CFH: FX Risk with Spot, For-
ward + CCBS
Test Plan Category Effectiveness Testing is Dis-
abled (such as Shortcut
Method)
Test Plan Rhythm Monthly
Eff Test Handling in DBTs Simulate ‘Always Effective’
if no ET is Available
Calculation Type Calculation Type: from Cur-
rency = Leading Currency
Apply Critical Terms Match Critical term match is not
set automatically
Documentation Handling Semi-Automatic Documen- <select>
tation
PDF-Based Forms: Form TR_F_THX_NOTE_HREL
Name
Note:
Leave any fields not listed in the table blank.
a) Go to the customizing under the path Financial Supply Chain Management → Treasury
and Risk Management → Transaction Manager → General Settings → Hedge
Accounting for Positions → Define Hedging Profile.
b) Choose the New Entries button and create the Hedging Profile using the information
provided in the table Hedging Profile Data.
Note:
Enter the data for the fields then press the Enter key to have the screen
refresh to show all the fields that need to be populated.
c) Choose Save.

Update a Reference Based Hedging Area and Create FX Trade
Simulation: Update a Reference Based Hedging Area and Create FX Trade

For more information on Update a Reference Based Hedging Area and Create FX
Trade, please view the simulation in the lesson Customizing Hedge Management
Elements online in the SAP Learning Hub.


Unit 7
Exercise 33
Update a Reference Based Hedging Area and
Create FX Trade
In this exercise on hedge management, you update the Reference Based Hedging Area
created in the exercise Create a Reference-Based Hedging Area, create a Hedging Instrument
for your Hedging requirements, check the hedging relationships, and demonstrate the Hedge
Accounting process including displaying and explaining the generated postings.
Hedging Area are used to derive the Designation Type and Hedging Profile based on a
combination of the following criteria:
● Valuation area
1. Update the Hedging Area with the new Hedging Profile using the following information:
Table 101: Hedging Area Data

Filed Name Value
Hedging Area HAR_##
Version 1
Table 102: Hedge Accounting II Tab Data

Filed Name Value
Des.Type Y##1W
HdgProfile X##
2. Take a snapshot of the exposure data belonging to specific hedging area. (The exposure
was entered in the exercise Create Exposure Activity Type and Reference Based
Exposure.) For the subsequent process of Hedge Management and Hedge Accounting, it
is mandatory to rely on fully versioned data. This ensures that at all times an auditor can
check which data served as the basis for a hedging decision. Take a Snapshot using the
following data:

Note:
Before you can use a Hedging Area in the Hedge Management cockpit, you
need to take a snapshot.
Table 103: Snapshot Information

Field Name Value
Hedging Area HAR_##
Description Snapshot <current date>
Day Reference <select>
Reset Target Quota <blank>
3. Create a Foreign Exchange Forward Contract with Hedging Classification.

In this step, you create a FX Forward Transaction as a Hedging Instrument. The saving of
the FX Transaction with a Hedge Accounting-specific Hedging Classification initiates the
Hedge Accounting processing. Use the following information:
Table 104: Spot/Forward Transaction

Spot/Forward Transaction Company Code TA##
Initial Screen
Product Type 60A Foreign Exchange (FX)
Transaction Type 102 Foreign Exchange
(FX)Forward Transaction
Spot/Froward Transaction Rate EUR/USD 1,20
Create Structure Screen
Buy/Sell Sell
Traded Amount USD 10.000.000 (80% of
the Net Open exposure, in
our case: incoming)
Value Date ++2 (= date (month) of the
exposure in the exercise
Create Exposure Activity
Type and Reference Based
Exposure)
Tab: Administration Hedging Classification HCR##
Tab: FX Hedge Management Exp. Item Use the pop-up on this field
to select your exposure item

Note:
For reference-based Hedging Areas, the hedging item (exposure) is specified
directly in the hedging instrument.
4. Review the exposure data, the hedging instrument and the hedge in the app Hedge
Management Cockpit app, based on the snapshot you prepared in the previous step. Make
yourself familiar with the many display and analysis options of the Hedge Management
Cockpit.
To validate the exposures entered in the previous exercise, use the following data:
Table 105: Hedge Management Cockpit Information

Field Name Value
Hedging Area HAR_##
Layout 1_REF_ALL
Scaling None
5. Settle the FX contract using the following data:

Field Name Value
Company Code TA##
Transaction <trade number created above>
6. Release the hedging relationship using the following data:
Table 106: Release Designation Information

Field Name Value
Company Code TA##
Save Values with Warnings <select>
Detail Log (Market Val. Calc.) <select>
Test Run 1st selected; 2nd deselected
7. View the posting log.
8. View the market value calculations, which are driven by the Hedging Profile settings.
9. View the Hedge Documentation, which is also driven by the hedging profile.

Unit 7
Solution 33
Update a Reference Based Hedging Area and
Create FX Trade
In this exercise on hedge management, you update the Reference Based Hedging Area
created in the exercise Create a Reference-Based Hedging Area, create a Hedging Instrument
for your Hedging requirements, check the hedging relationships, and demonstrate the Hedge
Accounting process including displaying and explaining the generated postings.
Hedging Area are used to derive the Designation Type and Hedging Profile based on a
combination of the following criteria:
● Valuation area
1. Update the Hedging Area with the new Hedging Profile using the following information:
Table 101: Hedging Area Data

Filed Name Value
Hedging Area HAR_##
Version 1
Table 102: Hedge Accounting II Tab Data

Filed Name Value
Des.Type Y##1W
HdgProfile X##
a) Start the Hedging Area app (Treasury - Hedge Management).
b) Enter the information provided in the table Hedging Area Data. The press the Enter
key.
c) Choose the Change button.

d) Choose the Hedge Accounting II tab and enter the information provided in the table
Hedge Accounting II Tab Data.
e) Press the Save button in the lower right corner of the screen.
2. Take a snapshot of the exposure data belonging to specific hedging area. (The exposure
was entered in the exercise Create Exposure Activity Type and Reference Based
Exposure.) For the subsequent process of Hedge Management and Hedge Accounting, it
is mandatory to rely on fully versioned data. This ensures that at all times an auditor can
check which data served as the basis for a hedging decision. Take a Snapshot using the
following data:
Note:
Before you can use a Hedging Area in the Hedge Management cockpit, you
need to take a snapshot.
Table 103: Snapshot Information

Field Name Value
Hedging Area HAR_##
Description Snapshot <current date>
Day Reference <select>
Reset Target Quota <blank>
a) Navigate to the Take Snapshot app (Treasury - Hedge Management).
b) Enter the data provided in the table Snapshot Information.
c) Choose the Execute button on the lower right corner of the screen.
A success message displays.
3. Create a Foreign Exchange Forward Contract with Hedging Classification.

In this step, you create a FX Forward Transaction as a Hedging Instrument. The saving of
the FX Transaction with a Hedge Accounting-specific Hedging Classification initiates the
Hedge Accounting processing. Use the following information:
Table 104: Spot/Forward Transaction

Spot/Forward Transaction Company Code TA##
Initial Screen
Product Type 60A Foreign Exchange (FX)
Transaction Type 102 Foreign Exchange
(FX)Forward Transaction
Spot/Froward Transaction Rate EUR/USD 1,20
Create Structure Screen
Buy/Sell Sell


Traded Amount USD 10.000.000 (80% of
the Net Open exposure, in
our case: incoming)
Value Date ++2 (= date (month) of the
exposure in the exercise
Create Exposure Activity
Type and Reference Based
Exposure)
Tab: Administration Hedging Classification HCR##
Tab: FX Hedge Management Exp. Item Use the pop-up on this field
to select your exposure item
a) Navigate to the group Treasury – Trade Processing.
b) Select the Create Financial Transaction (FTR_CREATE) app.
c) Enter the data provided in the table Spot/Forward Transaction.
d) Choose the Save button.
e) Note the transaction number created.
Note:
For reference-based Hedging Areas, the hedging item (exposure) is specified
directly in the hedging instrument.
4. Review the exposure data, the hedging instrument and the hedge in the app Hedge
Management Cockpit app, based on the snapshot you prepared in the previous step. Make
yourself familiar with the many display and analysis options of the Hedge Management
Cockpit.
To validate the exposures entered in the previous exercise, use the following data:
Table 105: Hedge Management Cockpit Information

Field Name Value
Hedging Area HAR_##
Layout 1_REF_ALL
Scaling None
a) Navigate to the Hedge Management Cockpit app (Treasury - Hedge Management).
b) Enter the data provided in the table Hedge Management Cockpit Information.
c) Choose the Start button to display the data.

You should see the exposure entered in the previous exercise and the FX hedging
instrument in the FX hedges key figure.

d) Select the NetOpenExp cell to view the open exposures. Drill down and view the details
of the exposure(s).
5. Settle the FX contract using the following data:

Field Name Value
Company Code TA##
a) Navigate to the group Treasury – Trade Processing.
b) Select the Process Treasury Transaction (FTR_EDIT) app.
c) Enter the number of the transaction you have just created and choose the Settle
button.
d) On the Spot/Forward Transaction Contract Settlement: Structure screen, briefly check

the transaction. Press the Save button to settle the trade.
6. Release the hedging relationship using the following data:
Table 106: Release Designation Information

Field Name Value
Company Code TA##
Save Values with Warnings <select>
Detail Log (Market Val. Calc.) <select>
Test Run 1st selected; 2nd deselected
a) Navigate to the group Treasury – Hedge Management.
b) Select the Release Designation app and enter the data provided in the table.
7. View the posting log.

a) Select the row of the hedging relationship on the output screen and choose the Display
Log button.
b) Choose the Posting Log button.
8. View the market value calculations, which are driven by the Hedging Profile settings.
a) Select the indicator to the left of the hedging relationship on the output screen and
press the Display Market Value Calculation Details button.
b) Select the Hedge Accounting Key Figures.
c) Press the back arrow ('<') once.
9. View the Hedge Documentation, which is also driven by the hedging profile.
a) Select the row of the hedging relationship on the output screen and choose the Hedge
Documentation button.

LESSON SUMMARY

Unit 7
Lesson 5
Understanding FX Options Process and
Customizing
LESSON OBJECTIVES
FX Options in Hedge Management
Figure 585: FX Options in Hedge Management Process Flow
FX option contracts can be used in the same way as FX forward contracts are used in hedge
management. In both cases, the Hedge Classification is specified on the Administration tab of
the trade.
Let us look at the processing flow of a European FX option contract that ends in-the-money
(ITM) so it can be exercised at its maturity, as the processing is different than for an FX
forward contract.
Close to maturity of the FX option, assuming it is in-the-money, with the settlement of the
exercise of the contract, the status of the FX option is changed to Exercise Settlement and the
underlying FX Spot/Forward transaction is created automatically by the system and is in
status Contract.

Note:
The processing category is specified in the configuration of the transaction type of
the FX option. The processing category controls the different processing steps for
the trade, e.g. if the settlement step is required or not.
Determination of Exposure Item Period
Figure 586: FX Option: Determination of Exposure Item Period
The field 'Date Exposure Item for FX Options' on the Hedging Area is introduced on the Main
Data tab to distinguish the Exposure Item determination when an FX option is the hedging
instrument.
The choices for this field are the following:
● Exercise Date FX Option:
- The Exercise Date of the FX Option is used to determine the Exposure Item Period.
● Value Date of Underlying:
- The Value Date of the Underlying of the FX Option is used to determine the Exposure
Item Period.

Lesson: Understanding FX Options Process and Customizing
Figure 587: FX Option: Determination of Exposure Item Period using Exercise Date
In the case of a Scenario: No Due Date Shift, the Expiry Date of the FX Option is used for the
determination of the Exposure Item Period.
Figure 588: FX Options in Hedge Management
The Hedging Classification of the FX Option is specified on the 'Administration' tab of the
trade, as is done for FX forward contracts.
● The underlying FX Spot/Forward Transaction is designated into the existing Hedging
Relationship (full nominal amount).
If the Hedging Classification is not populated on the Administration tab of the trade, the FX
Spot/underlying is not designated into a Hedging Relationship!

The FX Option exercise is executed at the Exercise Date of the European option contract. The
status of the FX Option is changed to Exercise.
With the settlement of the exercise of the contract, the status of the FX option is changed to
Exercise Settlement and the underlying FX Spot/Forward transaction is created in status
Contract.
Note:
The processing category is specified in the configuration of the transaction type of
the FX option. The processing category controls the different processing steps for
the trade, e.g. if the settlement step is required or not.
The underlying FX Spot/Forward product type is specified in customizing under the path
Manager → OTC Derivatives → Transaction Management → Product Types → Define Product
Types. Then, in the OTC Options, Forwards folder, double click on product type 76A.
After the FX Option is exercised, the system shows the underlying FX Spot/Forward as
second hedging instrument. The status of the Hedging Relationship is Planned Designation
Transfer.
When viewing the hedging relationships in Display Hedging Relationships (TPM100), on the
Hedging Instrument tab, now both the FX option and the spot contract are displayed.
Figure 591: Release Hedging Business Transactions - Option Exercise Transfer
The Release of the Hedging Business Transactions (TPM120) resulting from the FX Option
exercise:

1. Calculates the Hedge Accounting Key Figures at the exercise date
2. Assigns an additional Market Data Container to the Hedging Relationship for the FX Option
as well as for the underlying FX spot/forward
Manage Hedging Relationships
Figure 592: Manage Hedging Relationships - Navigation to Market Data Container of exercised FX Option
The market data required for the designation business transaction is grouped together in a
market data container.
When viewing the hedging relationships in Manage Hedging Relationships (TPM100), on the
Hedging Instrument tab, now both the FX option and the spot contract are displayed.
Figure 593: Manage Hedging Relationships - Navigation to Market Data Container of the exercised underlying
contract
Figure 594: Release of Hedging Relationship FX Option: Exercise Date of Hypothetical Derivative
The Hedge Accounting Calculation Type customizing is enhanced by the attribute 'Option
Hypothetical Derivative Determination' which allows the setting of the Exercise Date of the
Hypothetical Derivative to the Exercise Date of the Hedging Instrument.

Figure 595: Define Hedging Profiles
When the option contract is exercised and an FX spot transaction is created, the settings in
the Define Hedging Profiles customizing based on the hedging profile in the FX option
contract hedging relationship, determines the Hedge Accounting Rule of the underlying for
Component Calculations at FX Option Exercise and Classification at Period-End Close.
With the exercise of a FX Option, the underlying FX spot transaction is designated into the
existing FX option hedging relationship:
● The Hedging Profile definition is enhanced by an additional attribute 'Hedging Profile
Underlying' shown above.
● The 'Hedging Profile Underlying' setting determines the Hedging Profile for the FX spot
underlying. The Hedging Profile drives the Hedge Accounting Rule of the underlying for
Component Calculations.
The hedging profile is defined in SAP customizing under the path Financial Supply Chain
→ Hedge Accounting for Positions → Settings for Automated Exposure Item Hedging (FX
Risk) → Define Hedging Profile.
Figure 596: Define and Assign Update Types
Define and Assign Update Types for Hedging Business Transaction for Designation Transfer /
De-designation Transfer
New Update Types have to be defined to enable the newly introduced Hedging Business
Transactions for the Exercise of the FX Option:
● De-designation Transfer: Transfer out component values from exercised FX Option.
● Designation Transfer: Transfer in component values to underlying FX Spot/Forward
Transaction.

The new update types are defined in SAP customizing under the path Financial Supply Chain
→ Hedge Accounting for Positions → Update Types → Define Update Types and Assign
Usages.
The newly defined Update Types need to be assigned to the relevant Product Types of Hedge
Accounting for Positions.
The new update types are assigned in SAP customizing under the path Financial Supply Chain
→ Hedge Accounting for Positions → Update Types → Assign Update Types for Business
Transactions (P-HA) to Product Types.
LESSON SUMMARY


Unit 7
Lesson 6
Understanding Hedge Accounting
LESSON OBJECTIVES
Hedge Accounting Customizing Settings

Hedge Management Accounting
Figure 597: Hedge Management Accounting
First, let's summarize how and when the hedge management accounting is triggered.
At period-end, the determination of the fair market value (NPVs) including the decomposition
of the hedging instrument and the hypothetical derivative is performed.
The key date valuation of the FX hedging instrument is executed and the postings of the
Hedging Reserve and Cost of Hedging Reserve amounts are created on the Exposure Subitem
level and P/L ineffective amounts on financial transaction level. The postings executed are
driven by the Run Valuation (TPM1) app and the Run Classification app (TPM101).
The period-end close process of designated FX Transactions consists of the following steps:
● Calculation of NPV, Forward, CCBS, CVA/DVA key figures (TPM60CVA)
● Valuation of FX Transaction (TPM1)
● Classification of Hedging Relationship (TPM101)
- Hedging Reserve (aka OCI I)
- Cost of Hedging Reserve (aka OCI II) amounts are created on Exposure Subitem level
- P/L ineffective amounts on Financial Transaction level.
At maturity of the hedging contracts, the posting of the realized gain / loss on the hedging
instrument and the reclassification postings are executed by executing the Derived Business
Transactions (TPM18) app.

The newly processed and posted valuation and measurement results can be reported in
Position and Flow Reporting as well as Posting Journal.
Figure 598: Hedge Management Accounting
Before getting started on the hedge management accounting configuration, let's review the
settings in the trade that drive the valuation and internal position processing for the trade.
When the trade is entered, a General Valuation Class is entered on the Administration tab of
the trade. The General Valuation Class drives the holding category (general accounting
treatment) for the trade. In our example, let's assume we are entering an FX forward contract
that will be used as a hedging instrument of a forecasted item. The General Valuation Class
will be set to FX Derivatives: 001 Cash Flow Hedge, indicating that for valuation area 001, this
trade should be treated as a cash flow hedge.
The setting of the General Valuation Class will typically drive the Position Management
Procedure for the trade. The Position Management Procedure controls 1) how the trade is
valued (Determine NPV (TPM60CVA) and Run Valuation (TPM1)) and 2) how the internal
position management is handled for the trade, both of which are very important and relevant
to understanding the hedge accounting customizing. In other words, both the valuations and
derived business transactions are driven by the Position Management Procedure of the trade.
The Position Management Procedure is defined under the customizing path: Financial Supply
Settings → Accounting → Settings for Position Management → Define Position Management
Procedure.
The Position Management Procedure is assigned to a trade under the customizing path:
Manager → General Settings → Accounting → Settings for Position Management → Assign
Position Management Procedure.

Lesson: Understanding Hedge Accounting
Figure 599: Hedge Management and Hedge Accounting:Postings at Period End Close: Sample
In this slide, you see sample hedge management period-end postings. The postings are called
sample postings as postings and account names can differ in your company!
Postings 1: Run Valuation (TPM1), Postings for subpostions of FX Transaction (60 to 40
relation): from Asset account to Hedge Accounting clearing account.
Postings 2: Classification (TPM101), Postings for position Exposure Subitem, from Hedge
Accounting clearing account (split) to Hedging Reserve, Cost of Hedging reserve, Profit + L
account hedging/ ineffective part.
Note:
The Run Valuation (TPM1) run posts to a hedge management clearing account.
The Classification step posts from the hedge management clearing account to the
OCI and P&L accounts. It is a two-step posting process.
Valuations
Figure 600: Valuations
For valuations of trades in a hedging relationship, the same valuation customizing nodes are
used as for the valuation of derivatives that are freestanding. The position management
procedure would be different though.

Hedge Accounting rules are defined within the Key Date Valuation for accounting purposes
and are triggered when the Run Valuation (TPM1) app is executed. The type of valuation being
triggered drives which update types are used. Note the Sec. valuation tab, which is used for a
Security valuation step defined in the Position Management Procedure assigned to the
hedging instrument. Please see last slide.
Valuation postings related to derivative hedging instruments would typically post one side to a
hedge management technical clearing account in the Run Valuation (TPM1) step. The
Classification step then offsets the entry in the hedge management technical clearing account
with the other side of the entry to the appropriate balance sheet or P&L accounts.
→ Accounting → Key Date Valuation → Update Types → Assign Update Types for Valuation.
Derived Business Transactions
Derived business transactions are very relevant to hedge accounting.

complement them. For example, when the sub-position is created within the designation,
classification, etc., the position components that exist at this point in time are transfer posted
in accordance with the nominal values. A derived business transaction is generated for the
relevant original business transaction, which, like all other derived business transactions, is
configured here in customizing. It is the corresponding derived business transaction flow that
then is posted to the SAP general ledger.
The derived business transactions are specific to the given valuation area. This means that
the derived business transactions can be different for different valuation areas, even if they
stem from the same operative business transactions.
When defining update types, first the update type is defined with a long description, then the
derived business transactions is Derived Business Transactions. Always when defining update
types, these two steps are followed.
→ Accounting → Derived Business Transactions → Update Types → Define Update Types
and Assign Usages.

The derived business transactions that are relevant to hedge accounting are transfers,
position outflows, hedge accounting classifications, and transfers between sub-positions, as
shown on the slide above. For each of these derived business transaction groups, the
corresponding update types must be populated, based on the expected processing for hedge
management, as would be done for non-hedge management processing related to derived
business transactions.
The Derived Business Transaction folders relevant to hedge management are shown below.
Transfers = D
Position Outflows = E
P-Hedge Accounting: Classification = K
P-Hedge Accounting: Transfers Between Subpositions = M
For example, the derived business transactions relevant to classification postings are
triggered from the Hedge Accounting for Positions: Classification (K), shown above.
When the Execute Classification (TPM101) app is run, the classification postings are triggered.
The classification postings should move the amounts from the technical hedge management
clearing account to the appropriate balance sheet or P&L account based on the configuration
settings and the accounting treatment for the hedging instrument.
The updates types under "Reset" need to be populated only if "With Reset" option for the
Valuation Category is selected when the Run Valuation (TPM1) app is executed.
In the maintenance dialog of the Hedge Accounting for Positions: Transfers Between
Subpositions (M) dialog structure entry, enter the update types for the transfer postings
between the freestanding position and the hedged position for each component that is to be
transferred. This is done for positive amount (inflows) and negative amounts (outflows).
After the update types are defined, they are assigned for the required derived business
transactions. The assignment of derived business transactions is done by Position
Management Procedure.

Note:
The SAP naming convention of the update types corresponding to each folder
follows the alphabet, e.g. the first folder Inflows has DBT update types with an A,
the second folder Realized Gains/Losses has DBT update types with a B, etc.
To enter assign the update types to the derived business transactions, use the customizing
Manager → General Settings → Accounting → Derived Business Transactions → Update
Types → Assign Update Types for Derived Business Transactions.
Figure 603: Classifications
Figure 604: Account Determination
As with all other financial transaction-related processes, the account determination for
Treasury and Risk Management is done by following the customizing menu path. For further
information regarding this customizing, please reference Unit 4, Lesson 9 Configuring
account determination.
Note:
The Account Symbol 9.1.5 is the SAP standard delivered symbol for the hedge
management technical clearing account.

→ Accounting → Link to Other Accounting Components→ Define Account Determination.
LESSON SUMMARY


Unit 7
Learning Assessment
1. The exposure activity type gives semantic meaning to an exposure.

X True
X False
2. Raw exposures must be released before they can be used in a hedging relationship.
X True
X False
3. When releasing raw exposures, they can be released either manually or automatically or
both ways.
X True
X False
4. Which of the following best defines a fair value hedge?

X A A fair value hedge is a protection against the change of an expected cash flow as a
result of certain risk.
X B A fair value hedge is a protection of the present value of the cumulative change in
the value of a foreign direct investment.
X C A fair value hedge is a protection against price or market value change of a

recognized assets or liability.
X D A fair value hedge is a protection of an investment in a foreign business

5. Which of the following is true of a hedging area?

X A The hedging area defines which risks a company wants to monitor.
X B The company code specific data is stored in hedging area.
X C The risk categories for a foreign exchange risks are defined in a hedging area.
X D The hedging area provides visibility to hedged items and hedging instruments.
6. Which of the following is true of hedging classification?

X A A hedging classification that is hedge accounting relevant can be assigned to

multiple hedging areas.
X B A hedging classification is responsible for hedge accounting processing.
X C A hedge classification distinguishes between risky and risk-free currencies.
X D A hedging classification is a characteristic available for Automated Determination

of the Account Assignment Reference configuration
7. Which of the following is set at the Hedging Profile definition?

X A Hedge Accounting Rule
X B Hedging currency
X C Hedging Relationship Scenario
X D Designation Type
8. The Designation Type describes how many instruments can be designated together in one
X True
X False

9. The Hedge Management Cockpit pulls which of the following into one view?
X A Exposures
X B Hedging Instruments
X C Hedge Policy
10. Which of the following best describes reference-based Hedging Areas?

X A Release of the hedging relationships is not required
X B The exposure being hedged is specified in the hedging instrument
X C The exposure being hedged is determined by a rule framework.
11. Which of the following is driven by the Hedging Profile?

X A End-of-day designation
X B Creation of hedging relationship
X C Effectiveness testing
X D Hedge documentation created
12. Which of the following may happen with the release of a hedging relationship?
X A Creation of hedge request
X B Creation of hedging relationship
X C Hypothetical derivative is created
X D Hedge documentation is created
13. Which of the following describes the Trading Platform Integration app?
X A Integrates an SAP back-end system with a front-office trading system
X B Is an SAP Cloud Application
X C Works with ECC and S/4 HANA SAP implementations

14. Which of the following are available choices for determining the exposure for an FX
Option?
X A Contract date of the FX option
X B Exercise date of the FX option
X C Value date of the FX option
15. There is one central customizing node used for all account determination, including hedge
accounting, for Transaction Manager.
X True
X False
16. Which of the following are steps in the period-end close for hedging instruments?
X A Determination of the fair market value (NPVs) including the decomposition of the
hedging instrument
X B Post the valuation to the SAP general ledger
X C Execute the classification run
X D Post interest accruals
17. The Evaluation Type and CVA Type to be used for an FX derivative's hedge accounting
valuation are assigned at what level?
X A Hedge Profile level
X B Position Management Procedure level
X C Hedging Relationship Scenario level
X D Account Assignment Reference level

UNIT 8 Market Data
Lesson 1
Defining Market Data 642
Exercise 34: Reference Interest Rates and Yield Curves 655
Exercise 35: Define Credit Spreads 675
Lesson 2
Importing Market Data into SAP 687
UNIT OBJECTIVES
● Understand market data

● Understand and maintain reference interest rates and yield curves
● Understand currency settings
● Set security prices
● Understand credit spreads
● Maintain credit spreads
● Maintain factor types
● Maintain statistical market data
● Describe the different ways market data can be imported into SAP
● Understand the most common way to import market data into SAP

Unit 8
Lesson 1
Defining Market Data
LESSON OBJECTIVES
Types of Market Data
Figure 605: Usages of Market Data
Market data is required for risk controlling and closing. Treasury and Risk Management uses
different types of market data, which are usually uploaded once a day from the data provider.
Market data is data that changes every second, hour, or day. In this context it is important to
use up-to-date data for the purpose of valuations.
The currency exchange rates are the most important component here because all SAP
components use these for the conversion to local currency.
All other market data types are required almost exclusively in the Asset Management area
(including FI-AA, Loans Management, Transaction Manager, and Risk Management).

Lesson: Defining Market Data
Figure 606: Types of Market Data
Animation: Types of Market Data

For more information on Types of Market Data, please view the animation in the
lesson Defining Market Data, online in the SAP Learning Hub.
There are many different market data types that can be used for market risk analysis and
related valuations.
This overview depicts the areas and types of market data:
Interest:
● Interest rates
● Yield curves
Prices of exchange traded contracts:

● Security Prices
● Indices
Foreign Exchange:
● Currency rates
● Forex swap rates
Statistical values:
● Volatilities
● Correlations
Risk information:
● Credit spreads

Unit 8: Market Data
● Credit spread curves/new yield curve framework
Yield Curves in application processing
Figure 608: Reference Rates and Yield Curves
Explain the difference between reference rates and yield curves.

A reference interest rate is one point on a yield curve (for example, one week LIBOR or one
month LIBOR). (LIBOR stands for London Interbank Offered Rate and is a commonly used
benchmark interest rate.)
Reference interest rates are always currency-dependent and time-dependent so that a fixed
number of reference interest rates makes up a yield curve. All values of a yield curve differ
only in the term and time unit.
Note, that yield curves are required because not for all remaining times of each financial
transactions reference rates are available. Give an example.
Reference Interest Rate Overview
Figure 609: Interest Rate Setting Configuration Steps

Animation: Interest Rate Setting Configuration Steps

For more information on Interest Rate Setting Configuration Steps, please view
the animation in the lesson Defining Market Data, online in the SAP Learning
Hub.
The slide above outlines the steps to configuring interest rates.
Figure 611: Reference Interest Rates
To make the basic interest rate settings needed for the Market Risk Analyzer, you must first
define the reference interest rates and then define the yield curve type.
The maximum size of the reference interest rate key is limited to 10 digits. The reference
interest rates of a type, for example, LIBOR, EURIBOR, with different terms then form the
yield curve.
The screenshot above shows the overview of reference interest rates. To view the details of a
reference interest rate, double-click on an entry.
Basic Functions → Market Data Management → Master Data → Settings for Reference
Interest and Yield Curves for the Analyzers → Define Reference Interest Rates.
Figure 612: Reference Interest Rates Details

Unit 8: Market Data
The screenshot above show the detail of a reference interest rate definition.
The quotation distinguishes between bid, middle, and ask rate. A spread consists of the bid
rate and ask rate (purchase or sale of the currency), which usually depends on the volatility of
the rate. The middle rate can be calculated from the bid rate and ask rate (middle = (bid +
ask) / 2). In SAP, a user exit in the market data upload is also available to calculate the mid
rates.
A reference interest rate is defined and structured by the following fields: Yield Category,
Currency, Interest Calculation Method, Quotation type, Term, Unit of Time, Forward YC Type,
Calendar, Fixing Period, and Working Day Rule. The Date from and Financial Center fields are
used for information only.
The Yield Category field can be selected as a par rate or zero bond yields. Par rates are based
on a bond with an annual interest payment; zero bond yields are based on a bond with an
interest payment at the end of term. The zero bond discounting factors are always calculated
on the basis of zero bond yields. Therefore, par rates are first converted to zero bond yields
via bootstrapping before the respective zero bond discounting factors are determined by
means of the yields.
The Term field, in combination with the Unit of Time field (in days, months, or years), defines
the term of the reference interest rate.
Yield Curves Overview
Figure 613: Yield Curve Types
Yield curve types are described using the attributes yield category, read procedure,
interpolation procedure, and an unlimited number of currencies. For each yield curve, you
then have a structure containing markers from which the yield curve is constructed.
A yield curve is made up of the reference interest rates/markers, which have the following
common features:
● The reference interest rates are assigned to the same yield curve type.
● The reference interest rates are defined for the same currency.
The system builds the extended yield curve/yield table on the basis of this information. This
contains the following values:

● The interest rates in the markers

● The interpolated interest rates in the yearly marker values (only with yield category par
rate)
● Zero coupons and zero coupon discounting factors in the markers
● Yearly marker values with the yield category par rate
The interest calculation methods in the yield curves and the reference interest rates do not
have to be the same. When the concrete interest rates are saved in the extended yield table,
the system converts them into the interest calculation methods for the yield curves.
If Continuous Compounding Zero Interpolation is activated, zero rates with continuous
interest and interest calculation method Act/365 are determined irrespective of the yield
category from the zero bond discounting factors.
Figure 614: Market Data: Defining Yield Curves
After defining the reference interest rates for the yield curves, the reference interest rates are
used to compose the yield curves. Here it is important to have a strict separation by currency
and quotation type.
Specify the yield curve type and then choose Create, Display, or Change.
You see an overview of the master data of the yield curve. The master data contains
information about the interpolation procedure for grid points for which daily rates are not
available.
Settings for Yield Curve Type
In the Curve Properties area, choose the following settings for the YC type:
Payment Frequency - The time interval between interest payments. The following frequencies
are available:
● Zero Interest Rate: One Interest Payment at End of Term
● Interest Paid Annually

Unit 8: Market Data
● Interest Paid Semiannually

● Interest Paid Quarterly
● Interest Paid Monthly
Compounding Frequency - The compounding frequency determines how frequently interest

is calculated. The following options are available:
● Standard (=Payment Frequency, but Never Longer than 1 Year).
● The compounding frequency is same as payment frequency. In the case of zero interest
rates with a maturity of more than one year, this option assumes that compounding occurs
once a year.
● Annual Compounding (m = 1).
● Semiannually Compounding (m = 2).
● Quarterly Compounding (m = 4).
● Monthly Compounding (m = 12).
● Daily Compounding (m = 365).
● Continuous Compounding (m = infinity).
Extrapolation Method
Extrapolation Method - This indicator determines how a yield curve is extrapolated for terms
(maturities) that are longer than the longest term currently available in a yield curve. The
longest available term is the term of the reference interest rate with the longest term in the
yield curve and for which an interest rate was found.
● Keep Continuously Interest-Bearing Zero Rate Constant
The system assumes that the continuous compounding zero rate for terms in the
extrapolated part of the curve are exactly the same as the last continuous compounding zero
rate that currently exists in the yield curve.
● Keep Par Interest Rate Constant
The system assumes that the last par interest rate available in the yield curve, converted into
a continuous compounding rate, is exactly the same as the continuous compounding forward
rate in the extrapolated part of the curve. This means that the par interest rates are
practically constant for terms in the extrapolated part of the curve. However, it does not mean
that the par interest rates in the extrapolated part of the curve are exactly the same as the par
interest rate of the last grid point.
● Keep Continuously Interest-Bearing Forward Rate Constant
The system assumes that the continuous compounding forward rate of the last grid point in
the yield curve is exactly the same as the continuous compounding forward rate in the
extrapolated part of the curve.
In the Market Data Properties area, you define the allowed Maximum Age (in days) for the
market data. The maximum age specifies how old (in days) market data that is requested for
a given date can be without the system issuing a message that the maximum age has been
exceeded.
Assign a basis spread curve type to the yield curve type for forward calculation. When you
assign a basis spread curve type to the yield curve type and you use a yield curve of this yield

curve type for forward calculation, you can combine a basis spread curve with the yield curve
during forward calculation. The possible basis spread curves are taken from the assigned
basis spread curve type.
When you do not assign a basis spread curve type, then it is not possible to derive basis
spread curves during forward calculation.
In the bottom part, the individual currencies for which a yield curve has been created are
assigned. Double-click an entry.
Basic Functions → Market Data Management → Master Data → Settings for Reference
Interest and Yield Curves for the Analyzers → Define Yield Curve Type.
Reference Interest Rates
Figure 615: Market Data: Interest Rates
Double-clicking on a currency from the last screen, takes the user to the screen shown above,
where the reference interest rates to for the yield curve by currency are specified. Also, the
interest calculation method to be used for the yield curve is assigned. Definition of the interest
calculation method and the calendar (defines the number of days per month and year, as well
as public or bank holidays) are assigned. The interest calculation method describes the
number of days per year, e.g. with the act/360 calculation method has 360 days for years.
Depending on the currency, the yield curves are defined by assigning reference interest rates.
In the time units area, day, month, and year are distinguished. For valuations, yield curves are
used because not every Transaction Manager transaction accurately reflects the existing time
structure of an individual reference interest rate.
You can use the Markup/down column to define company-internal spreads based on specific
reference interest rates.
For interest rates over one year, swap rates can be used.

Unit 8: Market Data
Set Yield Curves
Figure 616: Interpolation of Interest Rates
Animation: Interpolation of Interest Rates

For more information on Interpolation of Interest Rates, please view the
animation in the lesson Defining Market Data, online in the SAP Learning Hub.
Since a yield curve can consist of different numbers of grid points (reference interest rates)
that are specified with different terms, it is possible that not all values are available every day
where a corresponding interest rate is needed for a calculation. These missing grid points can
then be calculated using the different interpolation procedures.
SAP distinguishes between the following interpolation procedures:
• Cubic spline interpolation
• Linear interpolation
The cubic spline interpolation uses third-degree polynomials for the calculation. This has
advantages over the standard linear interpolation procedure. The advantage in comparison to
linear interpolation is that instead of having a constant curve, continuous differentiation is
possible, resulting in a "smoother" curve.

Market Data: Interest Rates
It is possible to view or change interest rates via the individual entry of reference interest
rates or the maintenance of yield curves.
Yield curves can be viewed as of a specific date or period, as shown above.
Here, you can maintain interest rates directly via the yield curve or via the individual reference
interest rates. In our example, we will only look at the maintenance of yield curve "1002" in
currency "EUR". Select a yield curve type, currency, and entry date or entry period.
To view yield curves on the application side processing, follow the menu path Financial Supply
Chain Management → Basic Functions → Market Data Management → Manual Market Data
Input → Interest → Enter and Evaluation Yield Curves (JBYC).

Unit 8: Market Data
The screenshot above shows the yield curve details. The reference interest rates are display
as well as the corresponding number of days out each reference interest rate applies to. In
addition, the zero coupon and ZBDF values are displayed.
There is also an overview that gives the user a sense of the timeliness of the data.
The overview shows the already maintained status of yield curves depending on the read
procedure. In our example, no current interest rates are maintained; they are all prescribed by
the read procedure.
● %SC: This field displays the percentage of maintained reference interest rates in the yield
curve on the validity date. It does so in accordance to the read procedure for the assigned
reference rates. Example: If an interest rate is found for every assigned reference interest
rate on the yield curve's validity date (which might also include reading past dates,
depending on the read procedure), then the match will be 100%. If, however, no interest
rates have been maintained for the yield curves validity date and the read procedure is
'Direct Read', then the percentage would be 0.
● %SD: This field shows the percentage of maintained reference interest rates on the validity
date. Example: If the yield curve has been assigned 10 reference interest rates and five of
those are maintained on the validity date, that would be 50%. This calculation does not
take any kind of read procedure into account. It counts only the interest rates maintained
for that day.

As the screen shows, the yield curve is composed of several individual reference interest
rates.
From the entered date, the times of the grid points are calculated from the customizing
settings. After maintaining the grid point values, you can use the graphic icon to generate a
yield curve.
In the Calculation Base area you can see which values were used to generate the selected
yield curve for each currency and key date.
Double-click the graphic icon to graphically display the selected yield curve. This helps to
perform investigations on the current interest history (for example, inverse yield curve,
normal yield curve) and to use it for making investment decisions.
Reference Interest Rates and Yield Curves
Simulation: Reference Interest Rates and Yield Curves

For more information on Reference Interest Rates and Yield Curves, please view
the simulation in the lesson Defining Market Data online in the SAP Learning Hub.

Unit 8: Market Data

Unit 8
Exercise 34
Business Example
You now want to create a new reference interest and yield curve.
Note:
1. The existing one-year swap reference rates (EURSWP01YM) are no longer available and
you would like to switch to the current forward rate. Enter a new reference interest rate
(EURY01_##) with the following values:
Ref. int. rate EURY01_##

Payment Frequency Zero Interest Rate: One Interest Payment
at End of Term
Compounding Frequency Standard
Description <User defined>
Long Text <User defined + group number>
Currency EUR
Int. calc. method Act/360
Quotation type Middle
Term 1
Unit of Time Year
Forward YC Type 0001
Date from 01.01.1900
Financial Calendar <Blank>
Calendar 01
Fixing -2
Working Day Shift 0

Unit 8: Market Data
2. Create a new yield curve type 70## to be of EUR currency. The properties of the curve are
provided in the tables, and a maximum age of 10 years for market data. In addition, assign
the interest rates below to your yield curve.
Table 107: Curve Properties

Property Setting
Description < User defined + group number>

at End of Term
Extrapolation Method PC Keep Par Interest Rate Constant
Quotation Type Middle
Age 10
Table 108: Currency Field Details

Calendar 01
Int.Calc.Method Act/360
Table 109: Interest Rates

Reference Rate Long Text
EURD01EUR EUR 1 Day Rate

EURD14EUR EUR 2 Week Rate
EURM01EUR EUR 1 Month Rate
EURY01_## EUR 1 Year Rate
3. Enter the interest rate 1.5% for reference rate EURY01_## with today’s date. All other
reference rates that are relevant for this yield curve are defined by your instructor

Enter the missing rate for reference rate EURY01_##.
Reference EURY01_##
Currency EUR
Valid From today
Interest Rate 1.5
4. Evaluate the yield curve

Unit 8
Solution 34
Business Example
You now want to create a new reference interest and yield curve.
Note:
1. The existing one-year swap reference rates (EURSWP01YM) are no longer available and
you would like to switch to the current forward rate. Enter a new reference interest rate
(EURY01_##) with the following values:
Ref. int. rate EURY01_##

at End of Term
Description <User defined>
Long Text <User defined + group number>
Currency EUR
Int. calc. method Act/360
Quotation type Middle
Term 1
Unit of Time Year
Forward YC Type 0001
Date from 01.01.1900
Financial Calendar <Blank>
Calendar 01
Fixing -2
Working Day Shift 0

a) In SAP Customizing, choose Financial Supply Chain Management → Treasury and Risk
Management → Basic Functions → Market Data Management → Master
Data → Settings for Ref. Interest Rates and Yield Curves → Define Reference Interest
Rates.
d) Choose Save.
2. Create a new yield curve type 70## to be of EUR currency. The properties of the curve are
provided in the tables, and a maximum age of 10 years for market data. In addition, assign
the interest rates below to your yield curve.
Table 107: Curve Properties

Property Setting
Description < User defined + group number>

at End of Term
Extrapolation Method PC Keep Par Interest Rate Constant
Quotation Type Middle
Age 10
Table 108: Currency Field Details

Calendar 01
Int.Calc.Method Act/360
Table 109: Interest Rates


EURD14EUR EUR 2 Week Rate

Unit 8: Market Data

EURY01_## EUR 1 Year Rate
a) In the SAP Customizing menu, choose Financial Supply Chain

Management → Treasury and Risk Management → Basic Functions → Market Data
Management → Master Data → Settings for Ref. Interest Rates and Yield
Curves → Define Yield Curve Types.
b) To create a yield curve type 70##, in the YldCurve Type field, enter 70##, and choose
Create.
c) Enter the data provided in the table, Curve Properties.
d) Choose New Currency.

A dialog appears.
e) On the dialog, select the EUR indicator, and press Enter.
f) Double-click on EUR in the Currency field.

A new screen appears.
g) On the new screen, enter the data provided in the table, Currency Field Details.
h) Choose Save.
i) Choose New Reference Interest Rate.

A dialog appears.
j) On the dialog, select the indicator associated with the rates outlined in the table,
Interest Rates.
k) Choose Save.
3. Enter the interest rate 1.5% for reference rate EURY01_## with today’s date. All other
reference rates that are relevant for this yield curve are defined by your instructor
Enter the missing rate for reference rate EURY01_##.
Reference EURY01_##
Currency EUR
Valid From today
Interest Rate 1.5

Management → Manual Market Data Entry → Interest → Enter Reference Interest
Rates. Alternatively use transaction code JBIRM.

b) Select the Ref.interest rate indicator at the popup. Press the Enter key. Enter
EURY01_XX in the Ref.interest rate field. Press the Enter key again.
d) Enter the data provided in the table.
e) Click the Save icon to save your data.
Note:
In a productive system, entering master data will not trigger a transport
request.
4. Evaluate the yield curve

Management → Manual Market Data Entry → Interest → Manage Yield Curves.
b) Enter yield Curve Type 70##, currency EUR and today’s date. Click the Overview
button. Double-click at the displayed line. Validate the data on the three tabs (YC
Values, Calculation Bases, and Graphic Display).

Unit 8: Market Data
Exchange Rates Overview
Figure 622: Exchange Rates Overview
Business Example
You will define relevant customizing settings in the area of exchange rates and forward points.
You want to do the following:
● Define Currency Codes
● Check Exchange Rate Types
● Translation Ratios
● Rounding Rules
● Exchange Rate and Swap Rate Maintenance in the Application
As SAP is an integrated system, foreign exchange rates types are used from all SAP modules.
For month and year-end closing, the same rate for all modules is used.
Figure 623: Currency Settings Configuration Steps

Animation: Currency Settings Configuration Steps

For more information on Currency Settings Configuration Steps, please view the
The slide above outlines the steps to configuring currencies.
Currency Codes
Figure 625: Currency Codes
Animation: Currency Codes

For more information on Currency Codes, please view the animation in the
The first step in customizing exchange rates is that each currency to be used on SAP must be
defined. The currency settings are delivered with the SAP system and it is unlikely new
currencies would need to be added.
When defining a currency, a short description is maintained in SAP with the currency codes.
Basic Functions → Market Data Management → Master Data → Currencies → Check
Currency Codes.

Unit 8: Market Data
Figure 627: Define Decimal Places
The next step is to define the number of decimal places to be used for each currency. For
example, the EUR and USD both use two decimal places, but JPY does not have decimal
places.
The settings made here should follow the market convention for each currency.
Basic Functions → Market Data Management → Master Data → Currencies → Define Decimal
Places.
Exchange Rate Types
Figure 628: Define Exchange Rate Types
The next step is to define exchange rate types and their usage. By defining different exchange
rate types, it is possible to store several different exchange rates or swap rates for one
currency pair on the same date. For example, the exchange rate type M is used for month-end
exchange rates, whereas the exchange rate type D is used for daily exchange rates.
Both exchange rates and forward points are entered into SAP by exchange rate types.
Using the Ref.crncy field, the conversion is done using the reference currency, e.g.
triangulation. In other words, only the rates from/to the reference currency have to be
maintained rather ran all the currency pairs.
Exchange Rate Types.

Translation Ratios
Figure 629: Translation Ratios
The next step is to set the indirect or direct quotation as the standard quotation for each
currency pair and define conversion factors for currency conversion.
The use of translation ratios is important so that values with more than four decimal places
are not used for some rates. To be able to use a uniform exchange rate type (for example, M)
but also country-specific exchange rate types (for example, EURX), you can specify a
reference to another currency type in the different course type column.
The date is this table is the valid from date, which can be changed by adding the date of the
change, which may be needed in the case of a devaluation of a currency.
Translation Ratios for Currency Translation.
Figure 630: Rounding Rules for Currencies
Individual rounding rules can be defined depending on the company code and the currency.
For the company code/currency combination for which payments are to be made not in the
smallest denomination, but in a multiple of it, enter the currency unit (rounding unit) to which
amounts are to be rounded. Doing this step ensures that the amounts in this currency are
always rounded to this unit (providing the amounts you enter manually are also rounded in
line with your entry). The payment program evaluates your entries to determine the cash
discount and rounds off the amount accordingly.
For example, for CHF transactions in the Swiss company codes, it is decided that five
centimes is to be the smallest denomination for payment transactions. For Swiss company
codes and the Swiss franc, therefore enter 5 in the "Rounding unit" column. Cash discount
amounts are then rounded off to this currency unit. In the case of Swiss franc amounts
entered manually, that part of the amount after the decimal point must be divisible by five.
Basic Functions → Market Data Management → Master Data → Currencies → Rounding
Rules for Currencies.

Unit 8: Market Data
Exchange Rates in the Application
Figure 631: Market Data: Currency Rates in Application
When maintaining foreign exchange rates manually, you can store the rate for each currency
pair on the basis of either indirect or direct quotation, depending on the rate type and
effective date. If the quotation differs from the currency pair's standard quotation, the rate is
highlighted.
Once the individual currencies and rate relations have been specified in customizing, the
corresponding rate values have to be provided for each key date/working day and rate type.
We distinguish between price and quantity notation.
● Indirect quoted exchange rate (amount based): The exchange rate gives the amount of the
from currency that you get for a unit (10, 100,...) of the to currency. An example is that you
get 1.30 USD for 1.00 EUR.
● Direct Quoted Exchange Rate (price based): The exchange rate gives the price in the to
currency that you have to pay for a unit (10, 100,...) of the from currency. An example is
that you have to pay 0.7042 CHF for 1 USD.
To view exchange rates in the system, follow the path Accounting → Financial Supply Chain
Management → Treasury and Risk Management → Manual Market Data Entry → Currency →
Enter Exchange Rates, or use the tile Enter Exchange Rate (TMDFX) in the Treasury – Market
Data submenu.
Figure 632: Market Data: Swap Rates in Application
SAP uses the term "swap rate" to define forward points.

Forward points or foreign exchange swap rates provide default values when creating FX
forward contracts, and are required for the key-date valuation (Transaction TPM1 / tile Run

Valuation) if the position management includes a rate valuation that uses the forward rate of
one or both sides of the financial transaction.
To view exchange rates in the system, follow the path Accounting → Financial Supply Chain
Management →Treasury and Risk Management → Basic Functions → Manual Market Data
Entry → Currency → Enter Forex Swap Rates.
Forward points or swap points can also be uploaded into SAP by file upload or a datafeed
interface.
How to Validate Exchange Rate Settings
Simulation: How to Validate Exchange Rate Settings

For more information on How to Validate Exchange Rate Settings, please view
the simulation in the lesson Defining Market Data online in the SAP Learning Hub.
Exchanges
Figure 634: Market Data: Security Prices
Learn how to perform these steps on the following pages.
The definition of security prices takes place via security class and exchange.

Unit 8: Market Data
The definition of security prices takes place per exchange or source of data, because of the
different time zones and market requirements. For the same security, the market price
between Frankfurt and London can differ, assuming the same security is traded in both
places.
To enter security price data into SAP, use the path Financial Supply Chain Management →
Treasury and Risk Management → Basic Functions → Market Data Management → Manual
Market Data Entry→ Security and Index → Enter Security Prices or use the Enter Security
Prices tile.
Price Types
Figure 636: Securities: Exchanges
The first step to configure security prices is to create an exchange. The exchange represents
the source of the security prices.
To make it technically possible to map and evaluate securities and traded derivatives in the
system on the basis of different exchanges, you must define exchanges. This is important
because the quotation can vary significantly between the individual exchanges, and this can
affect price determination.
To take into account the times when the exchanges are closed (weekends and public
holidays), country-specific calendars are assigned. In the definition of a security class, the
exchange can later be included in the application.
To create an exchange, follow the customizing path Financial Supply Chain Management →
Treasury and Risk Management → Basic Functions → Market Data Management → Master
Data → Securities → Define Exchange.

Figure 637: Securities - Class
In the definition of a security class, the exchange can later be included in the application, as
shown above.
By pressing the Market Prices button, the user is able to see the market prices for the specific
security.
For different reporting and valuation purposes, different price types are defined. For example,
it may be necessary to upload in SAP the closing price but also the opening price. When the
prices are loaded into SAP, the price type is specified so it is tracked on SAP along with the
market data.
In addition to the exchange, the quotation form plays a central role for all tradable products.
For example, you can define and use individual quotation forms for the year-end valuation.
To create an exchange, follow the customizing path Financial Supply Chain Management →
Treasury and Risk Management → Basic Functions → Market Data Management → Master
Data → Securities → Define Security Price Types.

Unit 8: Market Data
Credit Spread Overview
Figure 639: Understanding Credit Spreads
Debt issued by the United States Treasury is used as the benchmark risk free rate for USD. A
credit spread is the difference in yield between a risk free rate, e.g. U.S. Treasury bond rate,
and a debt security with the same maturity but of lesser quality. Credit spreads vary from one
security to another based on the credit rating of the issuer of the bond. As the default risk of
the issuer increases, its spread widens.
For example, if a 10-year Treasury note has a yield of 2.54% while a 10-year corporate bond
has a yield of 4.60%, then the corporate bond has a credit spread of 206 basis points over the
Treasury note. Credit spreads are used to include rating information in the valuation results.
The risk free rate for interest rates is only used for a AAA rated company. Companies that
have less than a AAA rating, must add a spread to the interest rate.
A credit spread expresses the credit risk of a securities issuer, the counterparty of an OTC
transaction, or a main borrower towards an investor. In the price calculator of the Market Risk
Analyzer, a credit spread therefore results in a parallel displacement of the yield curve and is
stored in the corresponding evaluation type or valuation rule for the application.
Credit Spread Types
Figure 640: Define Credit Spread Types
In finance, a credit spread is the yield spread, or difference in yield between different
securities, due to the difference in credit quality for those different securities. The credit
spread reflects the additional net yield an investor can earn from a security with more credit
risk relative to one with less credit risk. The credit spread of a particular security is often
quoted in relation to the yield on a credit-risk-free benchmark security or reference rate.

For risk controlling, different credit spread types can be defined to include changed market
situations in reporting and analysis.
Management → Master Data → Define Credit Spread Types.
When defining a credit spread, a two digit identifier for the credit spread, a short name, and a
long description are entered.
Figure 641: Credit Spread in Application
Credit spreads can be entered for:

● OTC transactions (money market instruments, foreign exchange instruments, options
contracts)
● Securities, for example, bonds
● Loans (transactions from Loans Management)
In the application side menu, under Treasury and Risk Management → Basic Functions →
Market Data Management → Manual Market Data Entry → Credit Spreads, you use the
following transactions to enter credit spreads for the individual financial instruments:
● For money market transactions, use transaction code FTR_CSPRD to enter the credit
spread.
● For securities transactions, use transaction code FW_CSPRD to enter the credit spread.
● For Loans Management, use transaction code FNV_CSPRD to enter the credit spread.
The credit spread can change over time, an update therefore is required. Liquidity/rating
information from the issuer is included in the valuation run via the definition of credit spreads.

Unit 8: Market Data
Figure 642: Define Credit Spread IDs
The credit spread IDs define general properties of credit spreads.

To define a credit spread ID, use the customizing path: Financial Supply Chain Management
→ Treasury and Risk Management → Basic Functions → Market Data Management → Master
Data → Credit Spread Curves→ Define Credit Spread IDs.
When defining a credit spread ID, a 15-character identifier is entered as well as a description
for the credit spread ID.
In the Market Data Quotation area, you can define how the yield curve framework interprets
the market data by setting the following fields:
● Payment Frequency
● Compounding Frequency
● Fixing Period
● Working Day Shift
● Calendar
● Interest Calculation Method
● Maturity at Month End
In the Expert Settings area, choose the default setting in the Usage field, unless you want to
implement a conversion logic of your own to convert the market data to spreads for usage in
the yield curve framework.
To store market data, you also need to specify the reference entity (such as your business
partner) to which a spread refers. To do this, you need to define reference entities.
Defining a credit spread ID must be done before the following can take place:
● Entering credit spread market data into SAP
● Constructing credit spread curves using credit spreads with different times to maturity

When you want to use credit spread curves in the price calculator, you have to activate the
business function FIN_TRM_YCF and activate the yield curve framework in the Customizing
activity Activate Yield Curve Framework.
Figure 643: Define Credit Spread Curve Structures
Credit spread IDs are the terms on the credit spread curve structures. In other words, credit
spread IDs define the term structure of the curve. For this reason, each credit spread ID used
to form the credit spread curve must be defined before defining the credit spread structures.
In combination with a reference entity, a credit spread curve structure describes a concrete
credit spread curve. In this way, credit spread curve structures can be assigned to reference
entities.
To define a credit spread curve structure, use the customizing path: Financial Supply Chain
Management → Master Data → Credit Spread Curves→ Define Credit Spread Curve
Structures.
Figure 644: Define Credit Spread Curve Structures

Unit 8: Market Data
Animation: Define Credit Spread Curve Structures

For more information on Define Credit Spread Curve Structures, please view the
This slide shows a picture of a credit spread curve structure. The orange rectangles represent
the credit spread IDs. The line in green formed by the credit spread IDs is the credit spread
curve.
Define Credit Spreads
Simulation: Define Credit Spreads

For more information on Define Credit Spreads, please view the simulation in the
lesson Defining Market Data online in the SAP Learning Hub.

Unit 8
Exercise 35
Business Example
You want to define credit spreads for the fixed-term deposit transaction created in a previous
exercise.
Dependencies
This exercise uses the fixed-term deposit trade created in the exercise Carry Out Settlement
and Interest Accrual.
Note:
1. Enter a credit spread for the financial transaction you created in the exercise Carry Out
Settlement and Interest Accrual. The current credit spread for Business Partner BP## is
0.2%.
Company Code TA##

Transaction <Enter transaction number from the exer-
cise Carry Out Settlement and Interest Ac-
crual>
Valuate from today
Credit spread type 01
Credit Spread 0.2

Unit 8
Solution 35
Business Example
You want to define credit spreads for the fixed-term deposit transaction created in a previous
exercise.
Dependencies
This exercise uses the fixed-term deposit trade created in the exercise Carry Out Settlement
and Interest Accrual.
Note:
1. Enter a credit spread for the financial transaction you created in the exercise Carry Out
Settlement and Interest Accrual. The current credit spread for Business Partner BP## is
0.2%.
Company Code TA##

Transaction <Enter transaction number from the exer-
cise Carry Out Settlement and Interest Ac-
crual>
Valuate from today
Credit spread type 01
Credit Spread 0.2
a) Start transaction FTR_CSPRD.
c) Choose Save.

Factor Types Overview
Figure 647: Business Example Factor Types
You will be doing the set-up on SAP to support the market data entry.
Figure 648: Maintain Factor Types
In this step, factor types are defined, which are used to categorize different factors. When you
create a factor type, you enter the factor type ID and description describing the factor type.
Examples of factor types are dividends for a money market funds and MBS factors.
Money market funds pay their earnings as dividends, which are entered into SAP as a type of
market data.
A paydown factor is the portion of cash subtracted each month from the principal of a
mortgage-backed security (MBS) divided by the original principal of the loan. Paydown
factors for MBS investments are typically calculated monthly.
The customizing activity to Define Factor Types is available in Customizing under Treasury
and Risk Management -> Basic Functions -> Market Data Management -> Master Data ->
Securities -> Define Factor Types.
Figure 649: Maintain Factor Type Values
As discussed, factor values are needed for investment certificates, which often represent
money market funds, with factor-based dividend conditions.

Unit 8: Market Data
You enter factor values for securities which have factor based dividend conditions, for
example, money market funds. The factors are communicated for the specific financial
instruments and are needed to calculate the amounts of dividends. In detail, the published
factor for money market funds determines for a period (normally one day) the accrued
dividend or daily dividend of a money market fund. The accrued dividend (which is not paid) /
daily dividend for a period (normally one day) is calculated by units * dividend factor.
Factors are also used for mortgage backed security investments.
When entering factor values a security ID, factor type, effective from date, and factor value
are entered.
The customizing activity Enter Factor Values is available under Treasury and Risk
Management -> Basic Functions -> Market Data Management -> Manual Market Data Entry ->
Securities, Indices, and Factors -> Enter Factor Values.
Alternatively, factor values can be imported into SAP on the application side by following the
menu path Accounting -> Financial Supply Chain Management -> Treasury and Risk
Management -> Basic Functions -> Market Data Management -> Manual Market Data Entry ->
Securities, Indices and Factors Enter Factor Values.
Statistics Type
Figure 650: Maintain Statistical Market Data
Statistic market data are required for pricing options, the calculation of Value at Risk, and
other Market Risk Analyzer reporting.

Figure 651: Maintaining Statistical Market Data
Statistical market data types are created on SAP to categorize different types of statistical
data to be loaded into SAP and be used in valuations and Market Risk Analyzer analysis.
Figure 652: Define Statistics Type
The statistics type determines how volatilities and correlations are calculated and interpreted
for specific volatility and correlation types.
To calculate statistical market data, the sample size and the confidence interval are the most
important definition characteristics for guaranteeing a reliable evaluation. The confidence
interval determines the uncertainty factor so that, for example, 95% of all historical or
simulated data is within this interval. A standard normal distribution is assumed as the basis.
When defining the statistics type, the user specifies the absolute, relative, or logarithmic
calculation. An exchange rate type is also assigned.
Management → Master Data → Statistical Data → Define Statistics Type.

Unit 8: Market Data
The statistics type is defined as a 3-digit identifier with a short and long description.
To enable the harmonic smoothing of the sample size, the input values can be calculated as
absolute, relative, or logarithmic. Below are other fields defined in the statistics type.
● Sample Size:
The sample size specifies how much historic or simulated data is to be used for the
calculation of the statistical size.
● Determination Category:
The determination category specifies whether sample elements are calculated on an
absolute, relative, or logarithmic basis.
● Calculation Category:
The calculation category for the retention period indicates the procedure that determines
a holding period of longer than a day. Currently, only one retention period calculation
category is supported. With volatilities estimated using logarithms, the root method is
used; otherwise the linear interpolation is used.
Volatility Type
Figure 653: Define Volatility Type
Volatility is one of the most important statistical measures. Volatility is by definition is a

statistical measure of the dispersion of returns for a given security or market index.
The Volatility Type defines the classifications of types of volatilities to be maintained on SAP.
The volatilities stored on SAP can be for underlying transactions, such as foreign exchange
rates, interest rates, securities, or commodities.
One example of where volatility types are used is they are assigned within the definition of
evaluation types, which drive the market data used in valuations on SAP.
Management → Master Data → Statistical Data → Define Volatility Type.
Within the definition of the Volatility Type, the type (bid, mid, ask) is specified. In addition, a
Statistics Type is assigned to use a distribution function for estimating the values.
Volatilities can only be calculated for the following market data:
● Reference interest rates
● Yield curves
● Exchange rates

● Securities prices
● Index values
● Commodity prices
In addition, you can use different rate types (ask, middle, bid) for the calculation. The
volatilities are a prerequisite for analyzing option-type financial instruments.
Correlation Type
Figure 654: Define Correlation Type
Similar to a volatility type, correlation types are defined to classify different types of
correlations to be loaded into SAP and be used in the Market Risk Analyzer analysis, such as
the variance/covariance approach of Value at Risk.
Correlation by definition is a measure of interdependence between two or more things, such
as the interdependence of two currencies such as EUR to CHF.
To be able to calculate a relation between two currencies, reference interest rates, indexes,
commodity types, and/or security types, you must define a correlation type. A correlation
type is also assigned a defined statistics type so that the same basis is taken into account
when evaluations are performed. Correlation types are also assigned within the definition of
evaluation types, which drive the market data used in valuations on SAP.
Management → Master Data → Statistical Data → Define Correlation Type.
Similar to a volatility type, a Statistics Type is assigned to a correlation type to use a
distribution function for estimating the values.

Unit 8: Market Data
NPV Type
Figure 655: Define Price/NPV Type
Different Price/NPV types are defined to represent different valuation approaches to be used
on SAP. The valuation of OTC transactions can take place on the basis of different market
data or quotation forms (bid, middle, ask rate), which are defined as different NPV types, and
later saved in the corresponding NPV tables in the application.
Below are possible Price/NPV types needed:
● End-of-day valuation
● Hedge accounting
● Current valuation - bid rates
● Current valuation - mid rates
● Current valuation - ask rates
Management → Master Data → Statistical Data → Define Rate and NPV Type.
Volatilities
Figure 656: Volatilities in the Application

The calculation of volatilities can take place outside of SAP or with the statistics calculator.
The volatilities are stored in market data tables in SAP and used in Market Risk Analyzer
analysis.
The volatilities can be entered into SAP manually using the following menu path: Accounting
→ Financial Supply Chain Management → Treasury and Risk Management → Basic Functions
→ Market Data Management → Manual Market Data Input → Statistical Data → Enter Interest
Volatilities.
Statistical market data must also be retrieved in the SAP system for the purpose of
evaluation. This ensures that the market data that was used for calculating the net present
values is also used for calculating volatilities; the calculation should use the statistics
calculator. It is also possible to enter these values manually or import them into the system
using a data interface.
This example shows how volatilities are maintained manually in the system for every key date
and term. The entry is made for each volatility type and is therefore only valid for the
respective type.
In finance, volatility most frequently refers to the standard deviation of the continuously
compounded returns of a financial instrument within a specific time horizon. It is used to
quantify the risk of the financial instrument over the specified time period. Volatility is
normally expressed in annualized terms, and it may either be an absolute number ($5) or a
fraction of the mean (5%).
Volatility as described here refers to the actual current volatility of a market data instrument
for a specified period, e.g. 30 days or 90 days. It is the volatility of a market data instrument
based on historical prices over the specified period with the last observation the most recent
price.
The volatility type is used to classify volatilities. For each volatility type, volatilities for user-
defined underlying transactions such as exchange rates, reference interest rates, security
classes, or share index volatilities can be stored in the system. Further descriptive parameters
are linked to the volatility type.
Volatilities can be entered in the market data tables manually, or calculated automatically
using the statistics calculator. Using the SAP statistics calculator has the advantage that the
market data is known and cannot be changed. If this data is drawn externally, you do not
necessarily know the basis on which it has been calculated.
Figure 657: Correlations in the Application
The correlations are stored in market data tables in SAP and used in Market Risk Analyzer
analysis, such as Value at Risk.
The correlations can be entered into SAP manually using the following menu path: Accounting
→ Financial Supply Chain Management → Treasury and Risk Management → Market Data
Management → Manual Market Data Input → Statistical Data → Enter Correlations.

Unit 8: Market Data
In statistics, correlation and dependence are any of a broad class of statistical relationships
between two or more market data variables.
The correlation +1 in the case of a perfect positive (increasing) linear relationship
(correlation), −1 in the case of a perfect decreasing (negative) linear relationship
(anticorrelation), and some value between −1 and 1 in all other cases indicates the degree of
linear dependence between the variables.
As it approaches zero, there is less of a relationship (closer to uncorrelated). The closer the
coefficient is to either −1 or 1, the stronger the correlation between the variables. The
correlation type is an entity used for classifying correlations. Further descriptive parameters
are linked to the correlation type.
Statistics Calculator
Figure 658: Statistics Calculator
The statistics calculator can be found by following the menu path: Accounting → Financial
Supply Chain Management → Treasury and Risk Management → Market Risk Analyzer →
Tools→ Price Calculators → Statistics Calculator.
Animation: Statistics Calculator

For more information on Statistics Calculator, please view the animation in the
You can use the statistics calculator to calculate the volatilities and correlations required for
the variance/covariance approach. Alternatively, you can also import this information into
SAP.
When you start the statistics calculator, you have to enter the input parameters shown above.
You can also choose to calculate just volatilities or just correlations, as opposed to both. After
starting the statistics calculator, you can exclude certain volatilities and/or correlations.
In the interest area, volatilities are calculated for zero coupon rates (the NPV is always
determined based on zero coupon rates/curves). If par coupon rates are used as the
calculation base, the rates are transformed to the corresponding zero coupon rates via the
assigned yield curve. The volatilities are then determined for the zero coupon rates and stored
in the table Interest rate volatilities curve. The historical volatilities calculated in this way
should not be confused with the par rate volatilities (usually implied volatilities) stored in the

Interest rate volatilities table. Interest rate volatilities from par rates are needed to calculate
interest rate options; here there is no transformation to zero coupon volatilities.
If the statistics calculator is used to calculate interest rate volatilities on the basis of original
zero-coupon curves, no transformation is necessary. You can store the calculated values
directly in the interest rate volatilities table since allocation to a yield curve (from which the
corresponding zero rates are calculated in the case of par rates) is not necessary here.
Figure 660: Statistics Calculator
This example illustrates how the statistics calculator can be used to calculate correlations and
volatilities on the basis of existing market data. The advantage of this method is that there is a
dependency of all market data and possible errors can thus be avoided.
Only once you have deactivated the test run will the calculated statistical data be stored in the
relevant market data tables. You can overwrite these entries with a new calculation at any
time.
The calculation is based on the correlation and volatility types defined in customizing. Based
on these settings, you can include the desired error tolerance and sample size.
Since there is no guarantee that all required market data is always available on time, you can
include an allowed error tolerance. This is the maximum number of missing values.

Unit 8: Market Data
LESSON SUMMARY

Unit 8
Lesson 2
Importing Market Data into SAP
LESSON OBJECTIVES
Market Data Import Options
Figure 661: Importing Market Data
Animation: Importing Market Data

For more information on Importing Market Data, please view the animation in the
lesson Importing Market Data into SAP, online in the SAP Learning Hub.
Market data consists of information such as exchange rates, interest rates, volatilities,
security prices. The market data is typically imported from an external source such as
Bloomberg or Reuters. The SAP system supports a number of different options of importing
market data. The volume of market data to be imported typically drives the method selected
of uploading market data into the SAP system and would be an implementation-specific
decision.
There are different options for implementing the retrieval in SAP.
Below are the different options of importing market data into SAP:

Unit 8: Market Data
1. Manual entry
2. File interface
3. Datafeed
4. Some market data, in particular statistical data (volatilities and correlations), can also be
calculated directly in SAP.
The most common way to import market data into SAP has traditionally been by using a
market data file interface.
Figure 663: Define File Interface Market Data Source
When importing market data into SAP, the source of the data should be held with the data. In
this step, the market data source is defined. Define a name for the source of the data. You use
this name when importing market data from a file from within the application.
Select the 'Conv.keys' indicator if the market data is to be converted according to the
requirements in the conversion code tables.
To enter this configuration, following the customizing path Financial Supply Chain
Management → File Interface → Define Source of Market Data and Conversion Codes.
Figure 664: Define Market Data Monitoring
Using Define Market Data Monitoring, you can specify deviation limits against which the
market data being imported is checked. The file interface and datafeed import programs use
the market data monitoring feature. When the deviation limits are exceeded, a warning
message is displayed in the data import execution log. Note that, in addition to correct rates,
market data that deviates from the entered percentage are also stored in the respective
market data table. Using the error log of market data monitoring, specific users can then edit
the market data manually.
The tolerances are set by the class of market data. The slide above shows a description of the
different classes.

Lesson: Importing Market Data into SAP
In SAP standard, the tolerance limit for all instrument classes is set to 5 percent.
The Define Market Data Monitoring can be found in customizing, under Financial Supply Chain
Management → Define Market Data Monitoring.
Figure 665: Define File Interface
Foreign exchange rates, security prices, reference interest rates, indexes, and prices for
commodity forwards are transferred with the Import Market Data program (Transaction code
TBDM) or use the File Interface Import Market Data tile. This transaction can be found in the
menu, under Treasury and Risk Management → Basic Functions → Market Data Management
→ File Interface → Rates and Prices.
The Output Control area defines whether the transfer is a test run and Output control whether
only the incorrect or correctly transferred market data sets are supposed to be specified in
the execution log.
Variants can be created that hold the correct input settings for the upload program for each
type of market data.
The user will select the latest .prn file. Press the Execute button once the inputs are correct.
The user will see a screen indicating the data has been successfully imported into SAP.
Figure 666: Define File Interface

Unit 8: Market Data
When importing market data using the Import Market Data program, SAP requires the data
be in a specific space delimited file. The screenshot above shows a file of security prices.
Save the Excel spreadsheets to .prn files by following the steps below.
Open the attached relevant Excel Upload Template and save it to your local hard drive.
Choose File → Save As.
Choose Formatted Text (Space delimited) (*.prn) from the 'Save as' type list.
Choose a location and name for the file and save it.
Close the .PRN file.
Import .PRN file into SAP.
SAP Market Rates Management SCP App / Datafeed
Figure 667: SAP Market Rates Management SCP App / Datafeed
Animation: SAP Market Rates Management SCP App / Datafeed

For more information on SAP Market Rates Management SCP App / Datafeed ,
please view the animation in the lesson Importing Market Data into SAP, online in
The REFINITIV data option for SAP Market Rates Management provides market rates on a
daily basis or for a specified date range that you can use in SAP S/4HANA systems.
Single Market Data Service is powered by SCP App to be used to feed all SAP Systems.
This is an out-of-the-box S/4 HANA pull service to import market data into SAP.
Another different option is the SAP Market Rates Management Bring Your Own Rates data
option, which allows you to upload and download your own market rates licensed from third
party data providers. It includes upload and download APIs that enable you to upload and
download market data in a format compatible with an SAP S/4HANA system. You can
distribute the downloaded rates in all connected systems in your landscape.
The Market Rates, Bring Your Own Rates provides you with support for 12 market data types.
They are as follows:

Lesson: Importing Market Data into SAP
● Exchange Rates
● Securities
● Interest Rates
● Credit Spreads
● Basis Spreads
● Forex swap rates
● Indexes
● General volatilities (volatilities with moneyness)
● Exchange rates volatilities
● Security price volatilities
● Interest rate volatilities
● Index volatilities
REFINITIV is the new Brand name of ThomsonReuters.

These services use the Treasury and Risk Management datafeed functionality to incorporate
current and historic market data into your SAP systems by means of the different SAP Market
Rates Management services.
Please see OSS note 2431370 / Usage of the Market Rates Management Service for the use
of this service.
How to upload Interest Rates into SAP
Simulation: How to Upload Interest Rates into SAP

For more information on How to Upload Interest Rates into SAP, please view the
simulation in the lesson Importing Market Data into SAP online in the SAP
Learning Hub.
LESSON SUMMARY

Unit 8: Market Data

Unit 8
Learning Assessment
1. The exchange rate settings made on SAP are used by all modules.
X True
X False
2. The credit spread functionality on SAP applies to which trade types?

X A FX spot contracts
X B Interest rate swap derivatives
X C Money market trades
X D Securities trades
3. Which are the ways of importing market data into SAP?

X A Manual entry
X B File interface
X C Datafeed
X D SAP Market Rates Management SCP app
X E Statistical data (volatilities and correlations) can be calculated on SAP
4. What is the most common way of importing market data into SAP?
X A File interface.
X B Datafeed.
X C SAP provided service.
X D Statistical data (volatilities and correlations) can be calculated on SAP.


UNIT 9 Risk Management
Lesson 1
Configuring the Market Risk Analyzer 696
Exercise 36: Define Market Data Settings and Structures 711
Exercise 37: Define the Basic Analyzer Settings 721
Exercise 38: Define Value at Risk 731
Lesson 2
Credit Risk Analyzer 742
Exercise 39: Activate the Credit Risk Analyzer Integration 755
Exercise 40: Set Up Limit Types and Limits 773
Exercise 41: Set Up the Limit Management Application 779
UNIT OBJECTIVES
● Understand the Market Risk Analyzer

● Define the basic settings of the Market Risk Analyzer
● Define portfolio hierarchies and evaluation types
● Activate trade integration
● Execute Market Risk Analyzer reports
● Understand Value at Risk
● Understand the results database
● Understand the Credit Risk Analyzer
● Define the basic settings for the Credit Risk Analyzer
● Define limit management
● Execute the Credit Risk Analyzer functionality

Unit 9
Lesson 1
Configuring the Market Risk Analyzer
LESSON OBJECTIVES
Market Risk Analyzer
Figure 670: Overview of Market Risk Analyzer
Within SAP's Treasury and Risk Management modules are three analyzers: Market Risk
Analyzer, Credit Risk Analyzer, and Portfolio Analyzer. In this lesson, we look at Market Risk
Analyzer, which is a series of analysis reports and functions.
The analysis reports in Market Risk Analyzer help an organization or, more specifically, a
treasury department, to assess and quantify the risks of its financial positions. Once the risks
of an organization are analyzed and quantified, they can be more easily controlled. The inputs

Lesson: Configuring the Market Risk Analyzer
to Market Risk Analyzer are operational exposures, treasury trades, and ledger positions.
With SAP being an integrated system, leveraging the benefits of Market Risk Analyzer is easy.
With Market Risk Analyzer, a company can use analytical reports to determine its financial
trade positions and risks. For example, using the FX Exposure report (transaction code
AISFSS), a company is able to see its exposure to foreign currencies broken down into
predefined time buckets. The grid analysis report (transaction code JBRI) can be used to see
how sensitive a portfolio of trades is to changes in the market. For example, this report could
be used to show the change in value of a portfolio to within a 5 percent change in US dollar
interest rates and a 5 percent drop in the US dollar or euro exchange rates. The financial
trades are included in the Transaction Management sub-modules (e.g., Money Market,
Foreign Exchange, and Derivatives). The market data pulled into Market Risk Analyzer is used
for valuations.
The inputs to Market Risk Analyzer reports are treasury trades, cash management positions,
and market data. The market data consists of exchange rates, interest rates, volatilities, and
security prices. The output of Market Risk Analyzer reports is an analysis of the inputs.
Because market data is a key input to Market Risk Analyzer reports, the different options for
importing market data into the SAP system are described. Because Market Risk Analyzer is a
reporting module, it makes sense to consider a number of the reports that can be generated.
Figure 671: What are Market Risks?
Animation: What are Market Risks?

For more information on What are Market Risks?, please view the animation in
the lesson Configuring the Market Risk Analyzer, online in the SAP Learning Hub.
You can use the Market Risk Analyzer to calculate and assess different market risks at single
transaction level or at portfolio level. A market risk refers to the risk on a financial instrument
that is the result purely of changes to market parameters (for example, interest rates, rates,
commodities, indexes, currency exchange rates, and volatilities).

Unit 9: Risk Management
In the context of risk identification, we first ask ourselves what risks exist and which risks are
to be recorded in the context of risk management. In risk identification, it can be helpful to be
aware that risks have a cause and an effect (for example, changes in value and revenue) on a
certain object. Once the risks have been identified, you must decide in the next step, which of
the identified risks are analyzed and which key figures are determined. In the context of risk
management, the purpose is to limit excessive risks taken and to distribute the total of the
risks taken to the individual risk sources.
Figure 673: Market Risk Analyzer
Definition of terms used in Market Risk Analyzer

Analysis structure: This is the technical carrier of the characteristics and configuration
assigned to an implementation of Market Risk Analyzer.
Characteristic: A field used in the Analysis Structure in Market Risk Analyzer that can be used
for selecting and summarizing results. Examples of commonly used characteristics are
portfolio, company code, business partner, currency, and trader. It is possible within Market
Risk Analyzer to define custom characteristics.
Evaluation date: The date on which the market data is pulled into the report. Any trade
outstanding as of the evaluation date and meeting the input criteria is pulled into the report.
Evaluation type: The evaluation type is an input to most Market Risk Analyzer reports. The
evaluation type determines the market data used in calculations in the report. The market
data consists of exchange rates, interest rates, volatilities, and security prices, as some
examples. When defining an evaluation type, the exchange rate types, yield curves or volatility
types are entered into the definition of an evaluation type. The evaluation type defines the
yield curve type for discounting. By using different evaluation types, users are able to use
different yield curves for determining the forward-interest rates and for discounting. As
another example, different evaluation types could also be used to have valuations done using
either the monthly rate of exchange (the M exchange rate type) or daily exchange rates.
Key figures: Key figures are calculated financial numbers used in analysis such as net present
value, duration of a bond, clean price of a bond, intrinsic value of an option, and time value of
an option.

Financial objects: A financial object is an internal object used by Market Risk Analyzer
typically to represent a trade, but it can also represent a ledger position or an operational
exposure. Each financial object contains the values corresponding to each characteristic
assigned to the analysis structure.
Horizon date: The horizon date is the date to which the trades are discounted.
Market data: Market data consists of exchange rates, interest rates, volatilities, and security
prices. The market data is imported from an external source such as Bloomberg or Reuters.
An SAP system supports manual entry, file uploads, or a data-feed interface to load market
data. The volume and frequency of the market data to be imported typically drives the
method selected for uploading market data into the SAP system. For example, if market data
is loaded into the SAP system on a monthly basis, a file interface should be sufficient.
Market data shifts: A market data shift is an absolute or relative change from the current
market data environment. It is possible to define shifts to any type of market data such as
exchange rates, yield curves, and volatilities.
Portfolio hierarchies: Portfolio hierarchies enable the user to create sub-portfolios. Each sub-
portfolio is a portfolio node. The user is able to see the aggregated numbers by portfolio
hierarchy and by portfolio hierarchy nodes.
Reference interest rate: A reference interest rate is one point on a yield curve (e.g., one week
LIBOR or one month LIBOR). (LIBOR stands for London Interbank Offered Rate and is a
commonly used benchmark interest rate.)
Risk category: The different risk categories in Market Risk Analyzer are exchange rate,
interest rate, and commodity price risk.
Scenarios: A scenario is a hypothetical market environment. In contrast to a market data
shift, a scenario is a hypothetical market environment defined by entering specific market
data to be used in place of the current market environment data. The market data is entered
into the scenario without a date. The date is determined when a Market Risk Analyzer report
is run. In Market Risk Analyzer, the user can define scenarios, such as a fall in the USD/EUR
exchange rate or a steep increase in USD interest rates and value their portfolio using the
defined scenarios. Market Risk Analyzer reports show the changes in the portfolio for each
scenario.
Scenario process: This is a sequence of scenarios where the dates for the scenario are
explicitly specified.
Yield curves: The yield curves are defined in configuration by specifying reference interest
rates with their terms in ascending order. The reference interest rates are the points along the
yield curve. When Market Risk Analyzer uses the yield curves in calculations, values along the
curve that are between the data points are interpolated; values before the first or beyond the
last data point are extrapolated. Zero Bond Discounting Factors are used in the SAP system
to discount cash flows for the net present value determination or to determine future interest
payments with forward-interest rates.
Valuation rule: A valuation rule holds settings on how specific trade types should be valued.
The valuation rule is assigned to product types in configuration. The valuation rule is also
assigned to the evaluation type, which controls the valuation settings and the market data
used for valuations.

Basic analyzer settings
Figure 674: Overview of Market Risk Analyzer
You create characteristics independently of data structures in the analysis structure.

The following alternative methods are available for creating characteristics:
• Copy from a reference table.
• Define your own characteristics (with separate value maintenance, without value
maintenance, or with reference to a data element).
• Copy from the field catalog for bank profitability analysis.
You can transfer the client-dependent customizing settings for an analysis structure from the
sample customizing delivered from SAP. Additional fields and derived rules can be defined.
With SAP standard some characteristics are predefined.
● Rating
● Rating Procedure
● Business Area
● Business Partner
● Controlling Area
● Profit Center
● Valuation Rule
● Bank Product
● Contract Number
● Costing Rule
● Transaction

● Portfolio
● Currency
● Contract Type
● Product Category
● Position Currency
● Product Type
● Security Account
● Trader
● Country
● Future Account
● ID Number (Security Class)
● Industry Sector
● Hedge
Analysis Characteristics
Figure 675: Define Analysis Characteristcs
Animation: Define Analysis Characteristics

For more information on Define Analysis Characteristics, please view the
animation in the lesson Configuring the Market Risk Analyzer, online in the SAP
Learning Hub.
The steps to define an analysis structure are shown above.

The analysis structure is the technical container for all characteristics in risk management.
You can define several analysis structures and assign multiple characteristics to them. Each
client has exactly one analysis structure enabled. The analysis structure forms the basis for
the summarization levels that can be analyzed as part of the NPV, value-at-risk, gap, and ALM
procedures. Each data pool transaction contains a finance object that allows assignments to
the relevant portfolios of the summarization levels (views). You therefore need to derive the
analysis structure from the internal requirements before the data interfaces are

implemented. Otherwise, you may have to adjust the transfer of the characteristics if they are
not transferred in full.
One way to configure the base settings for Market Risk Analyzer is to copy the SAP sample
settings. The other way is to make all the configuration settings from scratch. By copying the
SAP sample settings, you see how SAP intended certain configuration nodes to be configured.
Copying the SAP sample settings is a two-step process. The first is to create the cross-client
configuration, and the second is to create the client-specific Market Risk Analyzer
configuration. After copying the SAP-delivered settings, you can make any necessary
adjustments to the copied settings to meet your company's needs.
Figure 677: Define Analysis Characteristcs
The characteristics to be used in Market Risk Analyzer reports are defined. Analysis
Characteristics are the data or fields that you want to use to value and report on your
positions in Market Risk Analyzer. The SAP-delivered characteristics are fields such as
company code, business partner, currency, portfolio, and trader. You can also create new
characteristics that can be used in analysis in Market Risk Analyzer.
When creating a new characteristic, you specify how the values for that characteristic need to
be defined. You have the following options:
● Enter the valid values for the characteristics in this configuration
● Link the new characteristic to an existing SAP table and field, which defines the valid values
for the characteristic
● Don't set up any validation checking for the characteristic values
The definition of the characteristics takes place irrespective of the an analysis structure and it
applies to all clients.
To define an analysis structure, follow the customizing path Financial Supply Chain
Management → Treasury and Risk Management → Basic Analyzer Settings → Reporting →
Characteristics → Define Analysis Characteristics.
Press the Display button to display the SAP standard characteristics that are available. The
analysis structure TRM is defined in the test system. Select analysis structure TRM to assign
a risk characteristic. This customizing step requires that the analyzing structure is already
created. The definition is explained in the next step.
You define the analysis structure by selecting some of the characteristics from previously
defined characteristics. Dependent characteristics are also supported (characteristics such
as trader and company code). You can define the dependency for the fields you have defined
yourself or copy it from the properties of a table field. Dependent characteristics must always
be included in a shared analysis structure. You also can use currencies as characteristics.
This means you can reference the TCURR table directly. In the past, you could only do this by
maintaining the corresponding values manually.

Each characteristic is classified by a data element and the corresponding origin or check
table. The defined characteristics therefore differ from the data element description, since
these are only used for SAP risk management (MRA, CRA, and Portfolio Analyzer). All other
data element descriptions are defined globally. Characteristics that are assigned in the
analysis structure but are not relevant for the Loans Management area, for example, are
simply not evaluated. The principle that only characteristics that are used can be evaluated
applies.
For changes to characteristic use, after portfolio hierarchies have been defined, and
especially after results have been written to the results database, you should note the
following:
● After changes are made in Transaction AFWS, the assignment of financial objects to
segments must be updated. This can be done by mass processing functions for financial
objects.
● The values in the results database are only stored for future evaluations corresponding to
the new characteristic use. Valuation results already generated are not changed. The
comparability of results may therefore be limited.
Analysis Structure
Figure 678: Define the Analysis Structure
An Analysis Structure is the data structure (technical carrier) for all characteristics that can
be used in risk analysis. The characteristics and their values depict the selection criteria
according to which transactions selected in the reports and which you can use for navigating
the results display of the analysis reports.
To define an analysis structure, follow the customizing path Financial Supply Chain
Management → Treasury and Risk Management → Basic Analyzer Settings → Reporting
Characteristics → Define Analysis Structure.
Analysis Structures are defined across all clients. You can only activate one Analysis
Structure for each client, however. Characteristics are assigned to the Analysis Structures
that represent the underlying data structure. The Analysis Structure is used to create
portfolio hierarchies that enable you to drill down the analyzed results of an investment
structure by characteristic values in reporting.

Regarding the analyzing structure, the following steps are required:

● The Analysis Structure contains all attributes that can be used as characteristics of a
transaction for analysis purposes.
● These attributes include default characteristics such as company codes, product types,
portfolios, and others, as well as characteristics defined by the customers themselves.
● The Analysis Structure is defined across all clients.
● The Analysis Structure is activated on a client-specific basis.
● The portfolio hierarchy is defined on the basis of the Analysis Structure.
● Only one Analysis Structure can be active for each client at the same time.
Once the Analysis Structure has been created, you must assign the valuation relevant
characteristics to this structure. The same characteristics can be used in different analysis
structures, but only one Analysis Structure can be activated per system at the same time.
Only one Analysis Structure can be active for each client at the same time. The Analysis
Structure is the technical basis for all evaluations in the Market Risk, Credit Risk, and Portfolio
Analyzer components.
Note: Because of how the configuration nodes were designed in the SAP system, a number of
Market Risk Analyzer configuration settings are not entered into transports when they are
created. When configuring Market Risk Analyzer, you need to make sure all settings make it
into a transport.
Figure 679: Segment Level Characteristics
In this next step, you specify specific to the client Analysis Structure, which characteristics
are used for forming segments. The characteristics defined in this step as segments can be
used as nodes in portfolio hierarchies.
In this customizing activity, the characteristics that are used to form segments are specified.
You make the specification with respect to an Analysis Structure and client. Segments are
internal keys that describe combinations of characteristic values. In many functions they are

used instead of the original characteristic values. Key figures in the results database are
stored by segment, for example.
For performance reasons, it is necessary to differentiate between characteristics that are
relevant for segments and characteristics that are not relevant for segments. If a
characteristic such as "Transaction number" were used for segment formation, there would
be just as many segments as transactions (if not more). Data storage would inflate
enormously and performance would worsen.
When you select characteristics for segment formation, for performance reasons you should
make absolutely sure that no more than 10,000 different combinations of segment-relevant
characteristics are possible (what counts are the combinations that actually come to pass,
not those that are theoretically possible). Since this is hard to estimate, a rule of thumb is to
avoid using characteristics - like the transaction number - that have a different value for
virtually every transaction.
To specify the segments for an Analysis Structure, follow the customizing path Financial
Supply Chain Management → Treasury and Risk Management → Basic Analyzer Settings →
Reporting Characteristics → Edit Segment Level Characteristics.
Select the Segment indicator if the characteristic is to be a segment.
Valuation Rules
Figure 680: Valuation Rules, Evaluation Types, and Portfolio Hierarchies
Learn on the next pages about the general settings required before the Market Risk Analyzer
can be used.

Figure 681: Valuation Rules, Evaluation Types, and Portfolio Hierarchies
The Evaluation Date field determines the trades included in the analysis report. If a trade is
outstanding on the evaluation date, it is included in the analysis. The evaluation date also
determines the market data. The market data is read as of the evaluation date. (If the
evaluation date is a date in the past, the market data is historical data.) The Horizon field is for
the date to which trades are discounted in calculating the NPV.
Click the Gen Selections (general selections) tab to specify the Report Layout. The report
layout defines the key figures to be displayed on the output screen. When you click the Define
Report Layout button, it is possible to define new layouts.
An SAP system is delivered with numerous key figures used as NPV, basis point value,
convexity, modified duration, yield to maturity, and the derivatives of option contracts (delta,
gamma, theta, and vega). Users can define various layouts to show different key figures. In
this example, you use a layout that shows duration numbers and the yield to maturity.
(Duration is a measure of sensitivity of the price of a fixed income investment to a change in
interest rates.)
You specify the portfolio hierarchy by which the output should be displayed.
You can drill down to the individual trades by double-clicking the trade numbers (in blue).
All Market Risk Analyzer output screens include Detail Log, Calc. Bases, and Error Log
buttons. Clicking the Detail Log button displays a log. This log outlines how the key figures
were calculated. The calculations and market data used are displayed in the detail log.

Figure 682: Define Valuation Rule
In this step, valuation rules are defined. Valuation rules are used to control the evaluation type
settings so that the evaluation types settings can be specified based on the type of
instruments being valued in the Market Risk Analyzer reports.
To create valuation rules, following the customizing path Financial Supply Chain Management
→ Treasury and Risk Management → Basic Analyzer Settings → Valuation → Define Valuation
Rule.
After the valuation rules have been created, the valuation rules are assigned to the different
product types. This second customizing steps is done by following the customizing path
Financial Supply Chain Management → Treasury and Risk Management → Basic Analyzer
Settings → Valuation → Other Transactions: Assign Valuation Rule via Product Type. Note
that the transaction type is not relevant in this step.
Evaluation Types
Figure 683: Evaluation Types
In this customizing activity, you define evaluation types. Evaluation types control valuation
related settings for market data, evaluation control, datafeed and valuation settings.

A company can create as many evaluation types as are needed. For example, the Treasury
department may want to run valuations using a daily exchange rate and also the monthly
exchange rates. To do this, two evaluations types should be created: one for each of the
exchange rate types mentioned. The same concept can be used for other types of market
data such as interest rates and volatilities.
Evaluation types have valuation specific settings. The valuation specific settings are
accomplished by using the create Valuation-Rule-Specific settings button. In this way,
different evaluation type settings are assigned to different valuation rules, which are assigned
to different product types.
Evaluation types can be defined by following the customizing path Financial Supply Chain
Management → Treasury and Risk Management → Basic Analyzer Settings → Valuation →
Define and Set-up Evaluation Types.
Hedge accounting uses Market Risk Analyzer for the effectiveness test. The evaluation type
customizing settings are particularly important for hedge accounting. On the Evaluation
Control tab, the evaluation Evaluation type type. In terms of parameters, you should set the
Select on Day ofCanx./Settlement and Select FX Netting Transactions indicators in the
Valuation Control screen area. You should always select these two indicators on the
evaluation type used for hedge accounting.
The Include Cash Flow on Horizon indicator plays a special role. This indicator controls
whether the net present value calculation considers the flows that fall due on a key date. The
risk category should determine whether you set the Include Cash Flow in Horizon indicator.
You should set the indicator for exchange rate risks, but not for interest rate risks. If you are
using only one evaluation type for hedge accounting and you are hedging both exchange rate
risks and interest rate risks, you are faced with the problem of setting the evaluation type
correctly. You can solve this problem by using different Valuation Rules, each of which
contains the Include Cash Flow in Horizon indicator and, at the same time, overrides the
settings in the evaluation type. You can then assign the respective Valuation Rule to specific
product types and add it to the Evaluation Type.
Additional settings are needed for valuations of securities and listed derivatives. To analyze
securities, a security price type is specified on the Evaluation Control tab page. The reason for
this is that securities can be valued on the basis of yield curves (special security valuation) or
using the security price. In addition to the previously defined market data categories, you
must include additional information in the area of securities, commodity, credit spread and
listed derivatives in order to make valuation possible.
On the External Function Control tab, it is specified if for that evaluation type the valuation is
externally supplied or the valuation should be defined on SAP. In this case, the valuations
would be performed outside of SAP and uploaded to SAP, and only the accounting entries
made on SAP.

Portfolio Hierarchies
Figure 684: Define Portfolio Hierarchies
Portfolio hierarchies are used in Market Risk Analyzer reports to define flexible views of
positions with different levels of aggregation, as shown above.
The definition of portfolio hierarchy can be defined and modified in the customizing or on the
application side.
The portfolio hierarchy is defined based on the characteristics of an analysis structure.
Figure 685: Define Portfolio Hierarchies
Portfolio hierarchies can be defined only from characteristics defined as segments in the
Analysis Structure, and are primarily used to achieve a structured and aggregated views on
characteristics and key figures. This is important in the Market Risk Analyzer reports, for
example, to display totals nodes.

Define Market Data Settings and Structures
Simulation: Define Market Data Settings and Structures

For more information on Define Market Data Settings and Structures, please
view the simulation in the lesson Configuring the Market Risk Analyzer online in

Unit 9
Exercise 36
Business Example
For market risk reporting, different market data settings, and structures need to be defined.
In addition, different evaluation types are needed. Create an evaluation type, a portfolio
hierarchy, and a valuation rule.
Dependencies
In the exercise Carry Out Settlement and Interest Accrual, a fixed-term deposit trade was
created.
Note:
1. Create a new portfolio hierarchy with a three-digit code (1##). Assign the characteristics
company code, portfolio, and product type to it.
Table 110: Portfolio Hierarchy Details

Field Name Values
Portfolio Hierarchy 1##

Short name CoCd/Portfolio/Prod.type
Long description CoCd/Portfolio/Prod.type
Table 111: Risk Characteristics

Field Name Values
Characteristic Company code (1)/portfolio (2)/product

type (3)
Sorting result 1/2/3
2. Create a new evaluation type EV##. Use the same settings as for the Evaluation type
Y001. Change the settings for yield curves type from 1 to 70##.
Evaluation type EV##

Short name individual + ##
Long description individual + ##

Yield Curve Type (Tab: Market Data Cate- 70##

gories)
3. Define valuation rule MM0## for product type 5##.

Valuation rule MM0##

Short name Standard MM trading
Long name Standard Money Market trading
4. Assign a valuation rule MM0## to product type 5##.

Product type 5##

5. Enter a credit spread for the financial transaction, which you have created in the previous
exercise. The current credit spread for business partner EV## is 0.2%.
Company Code TA##

Transaction number see previous exercise
Credit spread type 01 (Standard Spread)
Valid From today
Credit Spread 0,2
6. Calculate the NPV for the money market transaction from the exercise Correspondence
Activities. Select company code TA## and transaction number, to avoid NPV calculation
for all existing transactions. Display the calculation log.
Product Groups Select the OTC Transactions indicator

Company Code TA##
Transaction <Enter the transaction number from the
Correspondence Activities exercise.>
Evaluation Currency EUR
Evaluation Type EV##
Key date last day of this month
Test run 1st not selected; 2nd selected
Save values with warning Yes

Unit 9
Solution 36
Business Example
For market risk reporting, different market data settings, and structures need to be defined.
In addition, different evaluation types are needed. Create an evaluation type, a portfolio
hierarchy, and a valuation rule.
Dependencies
In the exercise Carry Out Settlement and Interest Accrual, a fixed-term deposit trade was
created.
Note:
1. Create a new portfolio hierarchy with a three-digit code (1##). Assign the characteristics
company code, portfolio, and product type to it.
Table 110: Portfolio Hierarchy Details

Field Name Values
Portfolio Hierarchy 1##

Short name CoCd/Portfolio/Prod.type
Long description CoCd/Portfolio/Prod.type
Table 111: Risk Characteristics

Field Name Values
Characteristic Company code (1)/portfolio (2)/product

type (3)
Sorting result 1/2/3

Management → Treasury and Risk Management → Basic Analyzer Settings → Define
Portfolio Hierarchy.
b) Start the customizing program and choose New Entries.
c) Enter the settings provided in the table, Portfolio Hierarchy Details.

d) Choose Save.
e) Select tab to the left of portfolio hierarchy 1## and double-click the Structure folder.
f) Choose New Entries.
g) Assign the settings provided in the table, Risk Characteristics.
h) Choose Save.
2. Create a new evaluation type EV##. Use the same settings as for the Evaluation type
Y001. Change the settings for yield curves type from 1 to 70##.
Evaluation type EV##

Short name individual + ##
Long description individual + ##
Yield Curve Type (Tab: Market Data Cate- 70##
gories)

Management → Treasury and Risk Management → Basic Analyzer
Settings → Valuation → Define and Set up Evaluation Types.
b) To create evaluation type EV##, select the Y001 Evaluation Type folder and choose
Copy As and copy all of the settings from evaluation type Y001. At the popup, select
Copy All . Change the following settings:
c) In evaluation type EV##, change the settings to those provided in the table.
d) Choose Save.
3. Define valuation rule MM0## for product type 5##.


Short name Standard MM trading
Long name Standard Money Market trading

Settings → Valuation → Define Valuation Rule.
c) Enter the settings provided in the table.
d) Choose Save.
4. Assign a valuation rule MM0## to product type 5##.

Product type 5##


Management → Basic Analyzer Settings → Valuation → Other Transactions: Assign
Valuation Rule via Product Type.
b) Choose New Entries, and enter the settings provided in the table.
c) Choose Save.
5. Enter a credit spread for the financial transaction, which you have created in the previous
exercise. The current credit spread for business partner EV## is 0.2%.
Company Code TA##

Transaction number see previous exercise
Credit spread type 01 (Standard Spread)
Valid From today
Credit Spread 0,2
a) At the Fiori launchpad, search for the Enter Credit Spread for OTC tile, or start the
transaction code FTR_CSPRD.
d) Choose Save.
6. Calculate the NPV for the money market transaction from the exercise Correspondence
Activities. Select company code TA## and transaction number, to avoid NPV calculation
for all existing transactions. Display the calculation log.
Product Groups Select the OTC Transactions indicator

Company Code TA##
Transaction <Enter the transaction number from the
Correspondence Activities exercise.>
Evaluation Type EV##
Key date last day of this month
Test run 1st not selected; 2nd selected
Save values with warning Yes

a) Choose the Calculate Net Present Values Tile (TPM60), tile located in Group Treasury -
Accounting.
c) Open all folders of the portfolio hierarchy on the left panel to see the individual trades.
The output screen has various buttons in the application toolbar that you can use to
gain further information about the calculation steps.
d) Place your cursor on a trade and then choose Detail Log.

You see the calculations used to determine the NPV.
e) To check the Market Data used in the calculations, choose Calc. Bases.
f) To see any errors encountered from the analysis run, choose Error Log.

Financial Object Integration
Figure 687: Financial Object Integration
In this step, you must activate/deactivate financial object integration for each product area
(money market, foreign currency, OTC derivatives, and securities). Set the components to be
used in risk management:
● Analysis → MRA
● Default Risk Limit → CRA
● Profitability Analysis → Portfolio Analyzer
To be able to enter financial object data at the same time as you create master data, set the
Component Active indicator. When you set this indicator in online processing, the system
displays the relevant screens for entering transaction data for the component in question
(such as Profitability Analysis and Default Risk Limitation). You can then enter the information
required for the financial objects.
You also define how the system is to react to errors:
● Completely active if the system is not to save the master data for the transaction if there
are errors
● Partially active if you want the system to save the master data but not to save the financial
object part that is incorrect. In this case, a warning message is triggered when the system
saves the data.
To activate financial object integration, follow the customizing path Financial Supply Chain
Management → Treasury and Risk Management → Basic Analyzer Settings → Automatic
Integration of Financial Objects in Transaction Master Data → Money Market → Activate/
Deactivate Financial Object Integration.

Derivation Strategies
Figure 688: Characteristic Derivation
In this key configuration node, you define derivation strategies to derive the characteristic
values for characteristics defined for the Analysis Structure for each trade or financial object.
The derivation strategies may be derivation rules, table lookups, moves, clears, or
enhancements. The derivation strategies populate the characteristics in Market Risk Analyzer
structures for each trade or financial object. If the characteristics are not derived, they are not
populated in Market Risk Analyzer and therefore cannot be reported on in Market Risk
Analyzer for the particular financial objects.
An important derivation strategy is to activate the Analysis Active Indicator. The Analysis
active indicator makes a financial object (the trade) visible for the evaluations of Market Risk
Analyzer.
To define the derivation strategies, follow the customizing path Financial Supply Chain
Management → Treasury and Risk Management → Basic Analyzer Settings → Automatic
Integration of Financial Objects in Transaction Manager Data → Foreign Exchange → Define
Derivation Strategy.
Note: To capture your derivation strategy configuration, you must select the derivation
strategy and click the transport icon.

Figure 689: Analysis Parameters Tab
After Market Risk Analyzer configuration is completed and the analysis structure is activated,
when new trades are created, the Analysis Param. tab is added to the trades that integrate
into Market Risk Analyzer, as shown above.
How to Activate the Online Single Transaction Check
Simulation: How to Activate the Online Single Transaction Check

For more information on How to Activate the Online Single Transaction Check,
please view the simulation in the lesson Configuring the Market Risk Analyzer
How to View a Market Risk Analyzer Report
Simulation: How to View a Market Risk Analyzer Report

For more information on How to View a Market Risk Analyzer Report, please view
the simulation in the lesson Configuring the Market Risk Analyzer online in the
SAP Learning Hub.
Define the Basic Analyzer Settings
Simulation: Define the Basic Analyzer Settings

For more information on Define the Basic Analyzer Settings, please view the
simulation in the lesson Configuring the Market Risk Analyzer online in the SAP
Learning Hub.


Unit 9
Exercise 37
Business Example
In an earlier exercise, a money market product type was defined. For this new product type,
you need to set up Market Risk Analyzer integration.
Dependencies
This exercise uses the following dependencies:
● This exercise uses the Business Partner that was created in Exercise 1.
● This exercise is also using the product type 5## and transaction type 100.
100.
type 100.
Note:
1. Activate the risk management (CRA, MRA) integration for product type 5## in company
code TA##.

Field Name Value
Product Type 5##
2. Enter a transaction with the business partner BP## and product type 5##. Use
transaction type 100 (purchasing). Check if MRA integration is available for this product.
Field Name Value
Amount 5M EUR
Interest rate 2.6%
Start 0
End One month out (++1)

Unit 9
Solution 37
Business Example
In an earlier exercise, a money market product type was defined. For this new product type,
you need to set up Market Risk Analyzer integration.
Dependencies
● This exercise uses the Business Partner that was created in Exercise 1.
● This exercise is also using the product type 5## and transaction type 100.
100.
type 100.
Note:
1. Activate the risk management (CRA, MRA) integration for product type 5## in company
code TA##.

Field Name Value
Product Type 5##

Settings → Automatic Integration of Financial Objects in Transaction Master
Data → Money Market → Activate/Deactivate Financial Object Integration.
b) Select the tab to the left of the entry with company code TA## and component
Analysis (APFO Analysis), and choose the Product types folder.
d) Enter the settings provided in the table.

This step activates the product type for Market Risk Analyzer.

e) Choose Save.
transaction type 100 (purchasing). Check if MRA integration is available for this product.
Field Name Value
Amount 5M EUR
Interest rate 2.6%
Start 0
End One month out (++1)
a) In your company code (TA##), choose the Create Financial Transaction tile. Use the
business partner you created.
c) Choose the Analysis Param. tab in the trade. Note that it is the derivation strategy
configuration that populates the data on this tab.
d) Choose Save.

Calculation of Value at Risk (VAR)
Figure 693: Value at Risk Approach
Value at risk (VaR) is a measure of the risk of loss for investments. It estimates how much a
set of investments might lose (with a given probability), given normal market conditions, in a
set time period such as a day. VaR is typically used by firms and regulators in the financial
industry to gauge the amount of assets needed to cover possible losses.
Risk Analysis supports the following procedures for calculating the value at risk: historical
simulation, the variance-covariance approach, and Monte Carlo simulation.
The curve represents a hypothetical profit and loss probability density function. It has mean
one and standard deviation one, but fatter tails than a normal distribution. The 5% VaR point
is 1.82 standard deviations below the mean, versus 1.64 for a normal distribution. The blue
area to the right of the line represents 95% of the total area under the curve. The red area to
the left of the line represents 5% of the total area under the curve.
Historic simulation offers different procedures for determining value-at-risk. You can use
historical simulation to arrange the gains and losses and the value-at-risk key figure is
determined according to the confidence level. For example, to take a drift into account, you
also can also double the gains and losses so that the value-at-risk is calculated on the basis of
an evenly distributed spread. Another procedure for determining value-at-risk is to assume
normal distribution for the calculated gains and losses.
The variance/covariance approach is based on the method suggested by J.P. Morgan/
RiskMetrics. You can determine volatilities and correlations using the SAP statistics
calculator and save them automatically or get them by way of a datafeed.
Like historical simulation, the Monte Carlo simulation is a method that describes the potential
changes in value of the risk factors using scenarios. However, in contrast to historical
simulation, the scenarios are not determined from historical data, but shown using a
stochastic process. The random numbers you need for this are provided by a random number
generator and can be transformed by various methods into the normal distribution.
IFRS 7 requires you to perform a value-at-risk calculation (historical or Monte Carlo) and/or
sensitivity analysis. For demonstration purposes, you can show only the historical simulation
and/or the variance/covariance approach in the training system.

Figure 694: Value at Risk Term and Precision
Animation: Value at Risk Term and Precision

For more information on Value at Risk Term and Precision, please view the
animation in the lesson Configuring the Market Risk Analyzer, online in the SAP
Learning Hub.
As part of the complete evaluation, changes in NPV are simulated by using historical changes
in the market price based on the real price functions. The advantage of this procedure is the
considerable calculation accuracy. The disadvantage is the calculation intensity of the
procedure.
As part of delta evaluation, NPV changes are simulated by applying historical changes in the
market price to a standardized change in NPV. The advantage of this approximation is that
this procedures is less calculation-intensive. However, the assumption that the NPV function
is linear leads to inaccuracies, especially in the area of option transactions.
The delta/gamma approach returns more accurate calculation results than the delta
evaluation at a significantly higher calculation speed than the complete evaluation. The
gamma add-on calculation can be applied to products or single transactions.
You can define these methods for specific products by way of the valuation rule in the
combination procedure as well. To prevent the settings specific to the valuation rule from
being ignored, you have to enter the combination procedure in the VaR type in Customizing.

Configure Value at Risk
Figure 696: Defining Number Ranges for Back Testing
To perform back testing, you must generate datasets for a certain key date and save them.
This way, you can exclude that, for example, a saved position of the last year-end closing can
be modified again. If changes occur nonetheless, you can use the saved position to determine
the difference. You must define a number range interval based as the basis for backing up the
position.
In this customizing activity, number range intervals for freezing data positions in the context
of back testing are defined.
To get to this customizing step, follow the menu path Financial Supply Chain Management →
Treasury and Risk Management → Market Risk Analyzer → Value at Risk → Manage number
ranges for Backtesting.
Figure 697: Define Value at Risk Type
The value at risk describes the risk potential of an asset under consideration of all existing
market risks. The value at risk can be calculated using the historical simulation, the
covariance approach, or the Monte Carlo simulation. Furthermore, you can include additional
information such as confidence interval or retention period for each procedure. The normal
distribution is assumed as the basis for all procedures. Double-clicking an existing entry
displays the details.

To get to this customizing step, follow the menu path Financial Supply Chain Management →
Treasury and Risk Management → Market Risk Analyzer → Value at Risk → Define Value at
Risk Type.
You have to make the following entries to specify the value-at-risk type:
● Simulation calculation
You use this parameter to specify whether, in the simulations, the transactions are evaluated
completely or approximate procedures are used (Delta, Delta-Gamma).
In the context of the full valuation, simulated NPV changes are determined by applying
historical market price changes based on the actual price functions. The advantage of this
procedure is its high calculation accuracy. The disadvantage is the calculation intensity of the
procedure.
In the context of the delta valuation, simulated NPV changes are determined by applying the
historical market price changes to a standardized NPV change. The advantage of this
approximation is that the procedure is less calculation-intensive. However, assuming a linear
NPV function leads to imprecision, particularly in the area of option contracts.
The delta/gamma approach returns more precise calculation results than the delta valuation
while offering significantly higher calculation speeds than the full valuation. The calculation of
the gamma add-on can take place specific to a product or specific to a single transaction.
You can also store the methods product-specifically by using the valuation rule in the
combination procedure. To ensure that these valuation-rule-specific settings are not ignored,
you must enter the combination procedure in the VaR type in Customizing.
The choice of procedure affects the runtime of the valuations. The complete valuation is more
precise but can result in long runtimes. For linear instruments, you can use an approximate
procedure, thus achieving shorter runtimes without a loss of precision.
● Element type: The determination category describes whether sample elements are
calculated as absolute, relative, or logarithmic.
● Historical period: The idea behind the historical simulation is to determine what gains or
losses you could expect if the market price development of the past would occur today.
This historical period is the time series (calculated from the valuation date backwards)
that returns the historical market price changes for the simulation.
● Retention period: The retention period describes the period that is used as the basis for
the liquidation or hedging of the commitment items to be valued.
● Error tolerance: This is the maximum allowed number of errors in the history.
For the valuation of volatilities and correlations, the system selects the historical market data.
If market data is missing, the sample scope is extended into the history. That is, if 10 days are
allowed to be missing, a maximum of 10 additional market data records are read and used for
volatility calculation. If, in the selection, more market data is missing than what you specified
with the maximum allowed number, the system terminates the selection and therefore also
the valuation.
In the calculation of correlations, market data pairs are required for the involved market
prices. If the value of a price parameter is missing for a business day, this is also interpreted
as an error for the corresponding pair value and the history is extended by one day for both
market prices.

● Value-at-risk method: Depending on the user entry, the value at risk is determined
according to different methods:
1. VaR determination using profits and losses
2. VaR determination using absolute profits and losses
3. VaR determination assuming normal distribution
4. VaR determination using absolute profits and losses with double values
● Number of values: The values are stored as fixed values and you can therefore use F4 to
call them up while making an entry. The selected VaR determination method can also be
disclosed in reporting.
Figure 698: Define Value at Risk Type
Continuing from the last screen…

In the calculation of correlations, market data pairs are required for the involved market
prices. If the value of a price parameter is missing for a business day, this is also interpreted
as an error for the corresponding pair value and the history is extended by one day for both
market prices.
● Value-at-risk method: Depending on the user entry, the value at risk is determined
according to different methods:
1. VaR determination using profits and losses
2. VaR determination using absolute profits and losses
3. VaR determination assuming normal distribution
4. VaR determination using absolute profits and losses with double values
● Number of values: The values are stored as fixed values and you can therefore use F4 to
call them up while making an entry. The selected VaR determination method can also be
disclosed in reporting.

Define Value at Risk
Simulation: Define Value at Risk

For more information on Define Value at Risk, please view the simulation in the
lesson Configuring the Market Risk Analyzer online in the SAP Learning Hub.


Unit 9
Exercise 38
Business Example
You need to meet the IFRS requirements using the value-at-risk approach. Create a value-at-
risk type.
Note:
1. Create new value at risk type F##.

Field Name Value
VaR Type F##
Name of VaR Type F## Historical Simulation (99/10)
VaR category 0 (Simulation)
VaR Simulation calculation 0 (Historical Simulation)
With Simulation 2 (Delta and Gamma Positions)
Sample Element Category 2 (Logarithmed)
Historical period 50
Error tolerance 9.999
VaR Method 1 (VaR determination based on profit and
Loss)
Calculate VaR <Select>
Calculate P+L <Select>
Consolidated VaR <Select>
Calendar ID 01
Holding Period 1
Confidence Level 99
2. Execute the VaR individual analysis for the new risk type.
Field Name Value
VaR Type <select this toggle>

Field Name Value

Value at risk type F##
Evaluation Type Y001
Evaluation Date 30.06.2017
Risk Hierarchy Y01
Risk Hierarchy Node 1
Start of History 30.06.2017
Detailed Log <select>
Portfolio Hierarchy 11

Unit 9
Solution 38
Business Example
You need to meet the IFRS requirements using the value-at-risk approach. Create a value-at-
risk type.
Note:
1. Create new value at risk type F##.

Field Name Value
VaR Type F##
Name of VaR Type F## Historical Simulation (99/10)
VaR category 0 (Simulation)
VaR Simulation calculation 0 (Historical Simulation)
With Simulation 2 (Delta and Gamma Positions)
Sample Element Category 2 (Logarithmed)
Historical period 50
Error tolerance 9.999
VaR Method 1 (VaR determination based on profit and
Loss)
Calculate VaR <Select>
Calculate P+L <Select>
Consolidated VaR <Select>
Calendar ID 01
Holding Period 1
Confidence Level 99

Management → Treasury and Risk Management → Market Risk Analyzer → Value at
Risk → Define Value at Risk Type.

d) Choose Save.
2. Execute the VaR individual analysis for the new risk type.
Field Name Value
VaR Type <select this toggle>
Value at risk type F##
Evaluation Type Y001
Evaluation Date 30.06.2017
Risk Hierarchy Y01
Risk Hierarchy Node 1
Start of History 30.06.2017
Detailed Log <select>
Portfolio Hierarchy 11
b) From the Treasury - Market Risk Analyzer submenu, choose the VaR individual analysis
(RMV0) tile.
d) To run the report, at the bottom of the screen, choose Execute.
e) Check the log, and then return to the SAP Fiori Launchpad.

Results Database
Below you will find the information how to set filters or edit Key Figures and Evaluation
Procedures.
Figure 701: Results Database Process
Animation: Results Database Process

For more information on Results Database Process, please view the animation in
the lesson Configuring the Market Risk Analyzer, online in the SAP Learning Hub.
The results database is used as part of end-of-day processing to calculate defined key figures
and save these key figures that can be used for later reporting. This complements the
existing options for saving and displaying the results of valuations. The advantage of the
results database process is the resulting data that has been generated can be used many
times in reports without having to recalculate the data.
Using Result Database
Below are the steps involved in using the results database:
1. Definition of key figures
Specification of the business content by the values of persisted key figure definitions

2. Definition of procedures and assignment of key figures to procedures

Procedures bundle key figures that are calculated and stored together. Single record
procedures store key figures at the financial object level, whereas final results procedures
calculate and store key figures in nodes of portfolio hierarchies.
3. Calculation of single records and of final results
The procedures can be scheduled to run. The procedures calculate the key figures they
contain, for the selected set of financial objects, and store the data in the results database.
4. Definition of layouts
Definition of the layouts for the presentation of the results in the Analyzer Information System
(AIS)
5. Definition of formulas
Definition of formulas in the Analyzer Information System (AIS) is an optional step.
Once the above steps are done, reporting using the Analyzer Information System (AIS) can be
done.
Structure of NPV Evaluations
Figure 703: Structure of NPV Evaluations
Animation: Structure of NPV Evaluations

For more information on Structure of NPV Evaluations, please view the animation
in the lesson Configuring the Market Risk Analyzer, online in the SAP Learning
Hub.
There are two types of evaluations – single value analysis and portfolio evaluations.
Single value analysis can be run as NPV analysis, historical simulation, and sensitivity
analysis. Portfolio evaluations can be run using grid analysis and sensitivity analysis.

With the results database, the following is possible:

● Separation of calculation and reporting
● Results of the evaluations are permanently available
● Subsequent additions to the results are possible
● Flexible reporting using even the most diverse key figures
To calculate key figures, the figures are grouped in different evaluation procedures. An
evaluation procedure is a summarization of key figures you want to calculate in a single step.
A distinction is made between single-record procedures and final-results procedures.
In the first step of the single-record procedures (SRP), the system selects position values
over the relevant financial objects.
If there is a complete set of correctly calculated key figures, further processing can be
performed with a final-results procedure. The task of a final results procedure (FRP) is to
calculate and store key figures based on the key figure already calculated in single-record
procedures and stored in the single-record results database.
The focus is the correct calculation of non-additive key figures like yields, sensitivities, or
Value at Risk, which are successively calculated for the individual nodes of a portfolio
hierarchy and stored in the final-results database for the portfolio hierarchy nodes.
Key Figures and Evaluation Procedures
Figure 705: Key Figures and Evaluation Procedures
The following key figures can be reported:

● NPV with shift rule
● Exposure
● Value at Risk
● Fisher-Weil Duration
● Convexity

● Sensitivity per basis point (PVBP)

● Macaulay Duration
● Modified Duration
● Clean price
● Backtesting for Profit and Loss
To define filters, follow the customizing path Financial Supply Chain Management → Treasury
and Risk Management → Market Risk Analyzer → Results Database → Edit Key Figures and
Evaluation Procedures.
Figure 706: Key Figure and Evaluation Procedures
The calculation in the results database is based on the calculation of key figures that are
summarized in procedures for single records and procedures for final results.
After finishing the definition of key figures, they can be assigned to single and final results
procedures.
● Single Records:
The procedure for single records is a method for calculating key figures, and is the basis
for the procedure for final results. Procedures for single records are supplied with key
figures, filters, and views.
● Final Results:
The procedure for final results controls how the final results of analyses are generated. Its
tasks are as follows:
- To group the key figures that are to be calculated in the same analysis run, and then
written to the results database
- In the case of non-additive key figures: To group portfolio hierarchies whose key figures
are to be calculated in the same analysis run and then written to the results database
- To ensure that no redundant data is stored in the results database

- In the case of a deletion run: To ensure that the data is deleted completely and
consistently from the results database procedures for final results (like those for single
records) are created in customizing, and are supplied with key figures and portfolio
hierarchies.
The following rules apply:

● Each key figure can be assigned to one, and only one, evaluation procedure (this avoids
redundancy). This is checked by the system during customizing.
● A procedure for final results can be changed or deleted in customizing, but only if there is
no evaluation data for it on the results database for this particular evaluation date. If the
evaluation procedure really has to be changed or deleted, then you have to delete all the
results database data first in a deletion run.
To edit key figures and evaluation procedures, follow the customizing path Financial Supply
Chain Management → Treasury and Risk Management → Market Risk Analyzer → Results
Database → Edit Key Figures and Evaluation Procedures.
To restrict output and calculations to certain criteria, filters can be defined. Filters can be
defined for a portfolio hierarchy or for the calculation in the results database.
A filter contains a particular combination of characteristic values (selections). In addition to
these, attributes are stored for each filter. In the test system, you can also define test
selections for the filter, which can be used to simplify the testing of evaluation methods.
For example, the analysis structure contains the characteristics “Product Type” and “Trader”.
You want to analyze the key figures for the product type Interest Rate Swap, regardless of
which trader concluded the swap transaction. You therefore define a filter that contains the
value Interest Rate Swap only.
To define filters, follow the customizing path Financial Supply Chain Management → Treasury
and Risk Management → Market Risk Analyzer → Results Database, Define Filter.
Figure 707: Define Initial Layout
To ensure the output in the results database is structured, the key figures are assigned to
different usage areas. The assignment is always made for each defined initial layout.
The definition of a new initial layout is done to ensure output to the results database.
In this customizing step, you define in which part of the screen in the Analyzer information
system key figures are to be displayed. From the result database, the system reads only the
key figures you define here. You can choose from the following parts of the screen:
● Portfolio hierarchy

● Single records
● Risk hierarchy
● Position trend (relevant for Portfolio Analyzer evaluations only)
● Maturity band
● Back testing
Via the initial layout, the relevant key figures per reporting level can be selected. The results
data base reporting support 6 different levels. Sub totals are available at portfolio hierarchy
level.
A maximum of 26 key figures can be assigned to one level.
To edit key figures and evaluation procedures, follow the customizing path Financial Supply
Chain Management → Treasury and Risk Management → Market Risk Analyzer → Results
Database → Define Initial Layout.

LESSON SUMMARY

Unit 9
Lesson 2
Credit Risk Analyzer
LESSON OBJECTIVES
Credit Risk Analyzer
Figure 708: Overview of Credit Risk Analyzer
Animation: Overview of Credit Risk Analyzer

For more information on Overview of Credit Risk Analyzer, please view the
animation in the lesson Credit Risk Analyzer, online in the SAP Learning Hub.
Within SAP's Treasury and Risk Management modules are three analyzers: Market Risk
Analyzer, Credit Risk Analyzer, and Portfolio Analyzer. This section focuses on Credit Risk
Analyzer.

Lesson: Credit Risk Analyzer
The Credit Risk Analyzer includes a risk control through limits and flexible limit management
with online monitoring and reporting. This functionality allows corporate executives to set
limit controls in their SAP systems, monitor their risk exposure, and minimize default risks.
The inputs to Credit Risk Analyzer are limits, bank account balances, and treasury trades.
Based on the inputs specified, Credit Risk Analyzer reports on the credit and or settlement
risk exposure to counterparties (banks). The Credit Risk Analyzer is for exposure to banks
either through bank accounts or treasury trades. It is not to monitor exposure to customers.
Exposure to customers is supported through SAP's Credit Management module.
You can use Credit Risk Analyzer to calculate and assess different credit risks at a single
transaction level or at a portfolio level. A credit risk refers to the risk on a financial transaction
that is the result caused by country risks, default risks, and settlement risks.
Treasury and Risk Management
Treasury and Risk Management: The tightening of regulations regarding risk controlling
underlines the increasing significance of analyzing and limiting the risk of insolvency. It also
makes business sense to have system support for measuring, analyzing, and managing credit
risks.
The integration into central limit management enables you to set limits for default risk and
monitor them online. You can then let the system calculate the settlement and default risks
arising from your activities on the financial and capital markets, as well as classical credit
risks. By defining differentiated upper risk limits, you can restrict potential losses on financial
transactions as a result of business partner insolvency. In the same way, you can use the limit
system to maintain control over the activities of your traders.
The default risk limitation offers comprehensive standard reports, and is linked to both the
SAP drilldown reporting tool and SAP Query. You can display all the existing utilizations in
aggregated form for any given key date and, with the appropriated system settings, taking
business partner relationships into account. This allows you to track the limit utilizations over
time and see exactly which transactions are behind the exposure. This enables you to monitor
all trading activities, thus offering you a high level of security.
Figure 710: Credit Risk Analyzer
SAP's Credit Risk Analyzer module is used to measure, analyze, and attempt to control
counterparty default risk. Counterparty default risk refers to the possible loss arising should a
counterparty not fulfill its contractual obligations. Counterparty risks are subdivided into
credit risk and settlement risk. Credit risks exist over the complete life of the transactions.
Settlement risks only exist during the settlement period of the transactions. The module
provides a limit utilization (exposure) report that is available in both real time and in an end-
of-day report across banks showing the risk exposure to different counterparties or banks.
Counterparty default risk refers to the possible loss arising should a counterparty not fulfill its
contractual obligations.

Animation: Credit Risk Analyzer

For more information on Credit Risk Analyzer, please view the animation in the
lesson Credit Risk Analyzer, online in the SAP Learning Hub.
In the Business partner relationships section, you specify if the business partner relationship
settings should be incorporated into the limit tracking. For example, with this configuration,
you specify that the subsidiary or branch-level business partners roll up to the group or
parent-level business partners. In most situations you would want this. Most companies track
their risk exposure to the parent company. For example, bank business partners are typically
created at the branch level (e.g., Bank1 Mumbai and Bank1 Frankfurt), and roll up to a group
business partner (e.g., Bank1 Group).
Counterparty versus Settlement risk
Figure 712: Counterparty versus Settlement risk
Animation: Counterparty versus Settlement risk

For more information on Counterparty versus Settlement risk, please view the
It is important to know the difference between counterparty risk and settlement risk.
Counterparty default risk refers to the possible loss arising should a counterparty not fulfill its
contractual obligations. Counterparty risks are subdivided into credit risk and settlement risk.
Credit risks exist over the complete life of the transactions.
Settlement risks only exist during the settlement period of the transactions.

Definition of Terms
Animation: Definition of Terms

For more information on Definition of Terms, please view the animation in the
lesson Credit Risk Analyzer, online in the SAP Learning Hub.
It is important to understand the definition of key terms used in this lesson. They are:
Attributable amount: SAP uses the term attributable amount to be the amount of the default
risk that arises when a trade is executed (saved in the SAP system). The attributable amount
is driven by configuration settings. How attributable amounts are to be calculated is a key part
of the Credit Risk Analyzer configuration. Different trade types can have different formulas for
calculating the attributable amounts. The system determines an attributable amount for
every expected incoming cash flow or asset. The attributable amounts are accumulated to
determine the utilization in the Credit Risk Analyzer reports.
Characteristics: Credit Risk Analyzer limits are defined by one or more characteristics. Credit
Risk Analyzer provides seven direct characteristics for the default risk limit: company code,
business partner, limit product group, portfolio, trader, currency, and monitoring unit. In
addition, the country, industry, and credit rating are indirect characteristics that can be
derived from the business partner master record. There can be up to 15 additional
characteristics added using a custom exit. The limit type characteristics for the use case
scenario in this article are business partner and limit product group.
Evaluation type: The evaluation type determines the market data used in calculations of
valuations. Some examples of market data are exchange rates, interest rates, volatilities, and
security prices. When you define an evaluation type, the exchange rate types, yield curves, or
volatility types are entered into the definition of an evaluation type. The evaluation type
defines the yield curve type for discounting. If market values are used in the calculation of risk
in Credit Risk Analyzer, you must define an evaluation type. The definition of an evaluation
type is a configuration step not covered in this article.

Financial objects: A financial object is an internal object used by Credit Risk Analyzer typically
to represent a trade, but it can also represent a ledger position such as a bank account
balance. Each financial object contains the values corresponding to each characteristic
specified in the limit type definition. The financial object holds the fields relevant for Credit
Risk Analyzer. These fields are the limit characteristics, the evaluation parameters for
attributable amount determination, transaction assignment for netting groups, and validity
period of the financial transaction. The application side transaction Manual Maintenance of a
Financial Object (transaction code JBDO) can be used to view a financial object.
Credit Risk Analyzer Process Flow
Figure 716: Credit Risk Analyzer Process Flow
The CRA process includes the following steps:

• Activate CRA functionality
• Set up customizing settings (for example, risk rules, determination procedure, and limit
types)
• Set up master data per limit types
• Run transaction KLNACHT
• Create financial transactions
Note: Online limit check is available for money market and foreign exchange. The limit update
base of the NPV, for example, takes place via transaction KLNACHT.
The first step in using the Credit Risk Analyzer is to define limits. This step is similar to master
data and needs to be done only when new counterparty business partners or bank accounts
at new banks are created in an SAP system.
Creating limits is done using transaction code TBL1 or by following menu path Accounting →
Financial Supply Chain Management → Treasury and Risk Management → Credit Risk
Analyzer → Master Data → Limits → Maintain.
The following fields are relevant to creating a limit:
● Valid from Date should be set to the date the limit goes into effect.
● Valid to Date should be set to the end date of the limit.

● The internal limit fields relate to the actual limits. These may hold some padding, meaning
the internal limits may be higher than the external limits. The external limits are softer
limits that may be communicated outside the treasury department. Therefore, the
external limit fields should be set equal to or more restrictive (lower) than the internal limit
fields.
● The Critical Limit Utilizat. (critical limit utilization) field gives the system a percentage
range above which the early warning control should generate a warning message. For
example, if the limit utilization is 90 percent utilized, a warning message is triggered letting
the user know that the limit is close to being fully utilized.
● The Max. Risk Commit Per.Mth. (maximum risk commitment per month) field is the
maximum expected term of trade in months. If the term of the trade exceeds this amount
of time (in months), a warning message is triggered at trade entry. Set the field to 12
assuming the investment trades will not exceed one year.
● If you want to check against the limit, you must set the value of the Limit parameter to
Check. Set the field to Check.
Credit Risk Analyzer End of Day Processing
Figure 717: Credit Risk Analyzer End of Day Processing
Running the End-of-Day Processing program recalculates the utilization of limits with Status
of Limit Utilization 2. (The limits with Status of Limit 1 are updated at trade entry.) To
generate utilizations at the end of day, execute transaction code KLNACHT or follow menu
path Accounting → Financial Supply Chain Management → Treasury and Risk Management
→ Credit Risk Analyzer → Tools → End-of-Day Processing → Generate Utilizations.
End-of-day processing is a specific function designed specially for Treasury and Risk
Management. This must not be confused with other end-of-day processing functions from
other modules.
After the Generate Utilizations program is run, the following message is displayed: End-of-day
processing was completed successfully. No additional information is given by this report.
To check for any error messages, run the Execute Postprocessing transaction code
KLNACHT2 or follow menu path Accounting → Financial Supply Chain Management →
Treasury and Risk Management → Credit Risk Analyzer → Tools → End-of-Day Processing →
Execute Postprocessing (not shown).

Credit Limit Utilization Report
Figure 718: Credit Limit Utilization Report
The credit limit utilization report, which shows the current credit exposure to counterparty
banks, is available from the SAP system to the front office traders to help them decide the
counterparties to take positions against during the day. Limits are checked both at trade
entry and at the end of day, and both are visible through this utilization report. (Limits with
Status of Limit Utilization 2 are created during trade entry. Limits with Status of Limit
Utilization 1 are created during the end-of-day calculation).
To access the Overview of Utilizations report, execute transaction code TBL4 (Direct
Characteristics) or TBLB (All Characteristics) and follow menu path Accounting → Financial
Supply Chain Management → Treasury and Risk Management → Credit Risk Analyzer →
Information System → Reporting → Utilizations → Overview Utilizations.
The end-of-day utilization report shows, by counterparty bank, the following information: the
limit amount, the current exposure to the counterparty (which is the credit exposure to the
counterparty banks), the available limit amount, and the percentage of the limit that is
utilized.
You can drill into a utilization to see the detail that makes up the utilization, including drilling
into the actual trades (to see all the details of the trades). To do this, click the indicator on the
left side of the utilization line.
Global Settings
Figure 719: Global Settings

After the Credit Risk Analyzer is activated, the Default Risk Limit tab displays in trades. This
tab holds the credit exposure characteristics that are used in the determination of credit risk.
The primary characteristics should be automatically filled by derivation rules in configuration.
Some basic settings are done in the basic analyzer settings. The definition of an Analysis
Structure, discussed in the Market Risk Analyzer lesson, is required for using CRA. To use the
NPV calculation, Market Risk Analyzer functionality must be activated.
The first configuration step is to make the initial settings for Credit Risk Analyzer. To access
the configuration node, follow the IMG menu path Financial Supply Chain Management →
Treasury and Risk Management → Credit Risk Analyzer → Basic Settings → Global Settings.
The fields relevant to this configuration step are the following:
● Select the Default Risk Active check box to activate Credit Risk Analyzer. You use the
indicator Derivation Active to define whether the system is supposed to automatically
derive the default risk rule for the transactions of Transaction Managers (TR-TM).
● Enter an Evaluation Type if any trade valuations are relevant to the Credit Risk Analyzer
processing. This is used if the market value of certain trades were used to determine the
amount of credit risk relevant for the trade. The Evaluation Type determines the market
data used in any Credit Risk Analyzer market value calculations.
● Select the Deriv. Active indicator if default risk rules will be used and should be derived by
configuration, which is relevant for my use case.
● Select the Sec.Acct Pos. indicator if issuer risk should be tracked on securities account
positions defined in the SAP system.
● Select the CM link is active indicator if bank account balances should be incorporated into
Credit Risk Analyzer, which is the case for the use case scenario.
● Set the Workflow is active indicator if a workflow message will be triggered if a limit has
been exceeded. The sending of the workflow message is part of the integrated single
transaction check (STC) when a limit is exceeded.
After you finish making the settings, click the save icon to save the changes.
Financial Object Integration
Figure 720: Activate Financial Object Integration - Overview
By activating the limit check, an additional Default Risk Limit tab is added in the creation of
the financial transaction. You can see whether limit attribution has been set up for this
product type when you create the financial transaction. Credit Risk Analyzer supports an
integrated online default risk limit check. Traders can use this function to determine the
transaction risk and check the deal against the defined limits before it is finalized.

Once a transaction has been concluded, the exposure automatically increases the utilization
of the affected limits. As a basis for the integrated limit check, all the financial positions must
be valued consistently. The system displays the result of the limit check. To do this, limit
utilizations are determined from the single transaction exposure calculated on the basis of
current market data. They are then updated in Limit Management. In addition to the
utilizations for each centrally-defined limit, the system also generates individual records for
each transaction. You can therefore see the impact of individual deals on the total utilization
and use this information as a basis for changing financial transactions during the course of
the day.
In this step, you indicate how errors encountered when integrating trades into Credit Risk
Analyzer should be handled. You also specify the trade types that should be included in Credit
Risk Analyzer, which is done by specifying the company code and product types to be
included.
In the first part of this configuration, you specify what to do in the case of errors. Do you want
to allow the trade to save even if the trade cannot be fully integrated into Credit Risk
Analyzer? If this is the case, select the radio button under the Part.act. (partially active)
column. If saving the trade should not be possible if there are errors integrating with Credit
Risk Analyzer, select the radio button under the Fully active column. Note that this
configuration is company code specific.
To complete this step, execute the configuration node Financial Supply Chain Management →
Treasury and Risk Management → Credit Risk Analyzer → Basic Settings → Automatic
Integration of Financial Objects in Transaction Master Data. Activate the component in this
step. For a limit check to be able to take place, it must be activated for each contract type
(OTC derivatives, foreign exchange, money market trading, and securities). This item is also
part of the basic Analyzer settings and can also be set up there.
For a limit check to take place, it must be activated for each contract type separately, e.g.
OTC derivatives, foreign exchange, money market trading, and securities.
To complete this step, execute the configuration node Financial Supply Chain Management →
Treasury and Risk Management → Credit Risk Analyzer → Basic Settings → Automatic
Integration of Financial Objects in Transaction Master Data → OTC Derivatives → Activate /
Deactivate Financial Object Integration.

Figure 721: Activate Financial Object Integration - Default Risk Limit
The default risk limit component is relevant for the Credit Risk Analyzer area. This step has to
be assigned and activated for each company code and product type. To get to this
configuration, select the box to the left of a row (from previous step), and then double-click
the Product Types folder. Specify all product types that should integrate into Credit Risk
Analyzer.
Note: There are different configuration nodes based on the type of financial object. For
example, there are nodes to activate money market transactions, foreign exchange
transactions, derivative transactions, loans, security trades, internal (In-House Cash) and
external bank accounts. Because the configuration is similar for each type of financial object,
only one type of trade is covered here.
Integrated Default Risk Limit Check
Figure 722: Activate Integrated Default Risk Limit Check
The purpose of this step is to activate an online limit check. The online limit check is done
while entering a deal and the check icon is clicked, or immediately after the save icon is
clicked. This gives the trader immediate feedback about whether the trade being entered

exceeds any limits. After the trade is saved, the limit utilization is updated in real time,
reflecting the exposure of the trade just saved.
Click the New Entries button and enter the data for each company code and Transaction
Manager sub-module. The Application field indicates the Transaction Manager sub-module.
To access this configuration node, follow IMG menu path Financial Supply Chain Management
→ Treasury and Risk Management → Credit Risk Analyzer → Basic Settings → Activate
Integrated Default Risk Limit Check.
Default Risk Rule
Figure 723: Define a Default Risk Rule
The default risk rule is used to group transactions from a business perspective and to classify
them. Each financial transaction must be assigned a Default Risk Rule.
In this section, you define default risk rules. A default risk rule is assigned to each financial
transaction to group transactions for business purposes. In the following step, these "groups"
are valued using standard methods. Default risk rules control the input parameters for
attributable amount determination.
The following settings are required for defining the default risk rule:
● You can store date determination for calculating market value change periods for each
default risk rule.
● You can store date determination for calculating the risk commitment period for each
default risk rule.
● The default risk rule also controls the type of recovery rate determination.
You are also able to set an indicator to determine whether the system is to calculate
settlement risk.
The default risk rule defines the criteria used to determine the date for market value change
period (term) and the risk commitment period of a transaction. You can choose from end of
term of the transaction or interest commitment period of the transaction. The recovery rate
determination, if used, is also stored in the default risk rule.

The default risk rule specifies whether, in addition to credit risks, settlement risks should also
be calculated for the trades assigned to this rule. When settlement risks are to be calculated,
select the Settlement Risk indicator.
One default risk rule is assigned to a trade or financial object. Default risk rules are assigned
to the determination procedures in the later configuration steps. In customizing of Derivation
Strategies, you define how the default risk rule is determined. It can be derived from the
product types or derived individually.
To access the configuration node, follow the IMG menu path Financial Supply Chain
Management → Treasury and Risk Management → Credit Risk Analyzer → Basic Settings →
Definitions → Define Default Risk Rule.
How to Activate the Online Single Transaction Check
Simulation: How to Activate the Online Single Transaction Check

For more information on How to Activate the Online Single Transaction Check,
please view the simulation in the lesson Credit Risk Analyzer online in the SAP
Learning Hub.
Activate the Credit Risk Analyzer Integration
Simulation: Activate the Credit Risk Analyzer Integration

For more information on Activate the Credit Risk Analyzer Integration, please
view the simulation in the lesson Credit Risk Analyzer online in the SAP Learning
Hub.


Unit 9
Exercise 39
Business Example
To fit the internal and external limit management requirements, the newly defined money
market product type needs to be included in Credit Risk Analyzer.
Dependencies
● Flow types were assigned to the product type 5## and transaction type 100.
● Condition types were assigned to the product type 5## and transaction type 100.
● A general valuation class was assigned to the product type 5## and transaction type 100.
Note:
1. Activate the financial object integration for your company code TA## and product type
5##.
Application Money market

FO component Default risk limit
Company Code TA##
Component active Yes
Partially active Yes
2. Verify the derivation rules for Credit Risk Analyzer to ensure that they work for your new
product type.
transaction type 100 (purchase). Verify that Credit Risk Analyzer integration is available
for this product type by validating the Default Risk Limit tab is in the trade.
Field Name Value
Amount 5M EUR
Interest rate 2.6%

Field Name Value
Start 0 (for the current date)

End ++1 (for out 1 month into the future)

Unit 9
Solution 39
Business Example
To fit the internal and external limit management requirements, the newly defined money
market product type needs to be included in Credit Risk Analyzer.
Dependencies
● Flow types were assigned to the product type 5## and transaction type 100.
● Condition types were assigned to the product type 5## and transaction type 100.
● A general valuation class was assigned to the product type 5## and transaction type 100.
Note:
1. Activate the financial object integration for your company code TA## and product type
5##.
Application Money market

FO component Default risk limit
Company Code TA##
Component active Yes
Partially active Yes

Settings → Automatic Financial Object Integration in Transaction Master
Data → Money Market → Activate/Deactivate Financial Object Integration.
b) Select the tab to the left of the entry provided in the table.
c) Double click on the Product Types folder.
d) Press New Entries and enter your product type 5##.
e) Choose Save.

2. Verify the derivation rules for Credit Risk Analyzer to ensure that they work for your new
product type.
Management → Treasury and Risk Management → Basic Analyzer Settings → Basic
Settings → Automatic Financial Object Integration in Transaction Master
Data → Money Market → Derive Default Risk Control Parameters for MM Transactions.
b) There are three derivation rules. Check the settings and conditions on each to ensure
the Credit Risk Analyzer parameters defaults into your new product type. To check the
settings of each, double-click the rules.
Note:
It should not be necessary to change the configuration.
transaction type 100 (purchase). Verify that Credit Risk Analyzer integration is available
for this product type by validating the Default Risk Limit tab is in the trade.
Field Name Value
Amount 5M EUR
Interest rate 2.6%
Start 0 (for the current date)
End ++1 (for out 1 month into the future)
a) In your company code (TA##), choose the Create Financial Transaction tile (Treasury -
Trade Processing). Use the business partner you created (BP##).
c) Verify the Default Risk Limit tab is in the trade.

It is not necessary to save the trade.

Single Transaction Check Product
Figure 726: Define the Single Transaction Check Product
Single transaction check (STC) refers to the online limit check from a trade. An STC is done
both while entering a deal and the check icon is clicked, or immediately after the save icon is
clicked. This functionality gives the trader immediate feedback about whether the trade being
entered exceeds any limits.
To have the integrated limit checking while entering a trade, the following must be done:
● You must have configured the automatic financial object integration. (This was described
in the "Activate Financial Object Integration" section.)
● Integrated default risk limit check must be active. (This was described in the "Activate
Integrated Default Risk Limit Check" section.)
● You need to have defined at least one single-transaction-check product for the single-
transaction-check transaction. (This is described here.)
The External Financial Transaction Category defines the type of trades to which the STC
product applies. There must be one STC product defined as the default for each External
Financial Transaction Category.
To access the configuration node, follow IMG menu path Financial Supply Chain Management
→ Treasury and Risk Management → Credit Risk Analyzer → Basic Settings → Definitions →
Define Single Transaction Check Product.

Derivation Strategies
Figure 727: Default Risk Limit
After the Credit Risk Analyzer is activated, the Default Risk Limit tab displays in the trade. This
tab holds the credit exposure characteristics that are used in the determination of credit risk.
The primary characteristics should be automatically filled by derivation rules in configuration.
Determination Procedure
Figure 728: Define Determination Procedure
The default probabilities, valuation principles, and risk potentials can be very different.
Because of this, it is necessary to define different determination procedures.
Determination procedures enable you to define flexibly which risk category is to be used for
calculating the limit utilization: credit risk or settlement risk. If for one trade, both credit risk
and settlement risk should be tracked, at least two determination procedures are required to

measure each of these risks. (One determination procedure is required for each risk
category.)
A determination procedure includes all rules and definitions that are required for determining,
for transactions with default risks, the risks relating to a certain risk category from a certain
business perspective. This definition can be demonstrated as follows: If you want to mark a
transaction as having both credit and settlement risks, you need to define two determination
procedures (one for each risk category).
If, for a particular risk category, you want to value one transaction using different methods,
you can set up different determination procedures. This would allow you, for example, to
value the transaction risk for regulatory purposes and for internal purposes at the same time.
Within a determination procedure, different transactions with different risk properties can be
valued using different methods.
Gross exposure refers to a volume-oriented attributable amount for the primary business
partner and collateral giver without taking into account the risk-reducing and transferring
effect of collateral provisions.
Net exposure refers to a volume-oriented attributable amount for the primary business
partner and collateral giver, taking into account the risk-reducing and transferring effect of
collateral provisions.
Calculate the Attributable Amounts
This step defines how to calculate the attributable amounts (amount of credit exposure) for
the financial positions. (Keep in mind that the attributable amounts are accumulated to
determine the utilization amounts in the Credit Risk Analyzer reports.) Examples are:
● NPV
● Nominal amounts
● Mixed exposures (such as mixture of NPVs or nominal values)
● Incorporating default risk probabilities
● Incorporating add-on factors
● Incorporating issuer risks
The calculation of the attributable amount can be straightforward, such as using the nominal
value or market value of a trade, or complex, such as incorporating the credit rating of the
business partner, a mark-up percentage or a recovery percentage if a business partner
defaults the expected amount to be recovered.
With the variable assignment ID configuration, you set how attributable amounts for
counterparty risks are to be calculated. Based on my use case scenario, one Valuation Factor
Determinations needs to be created for market value (NPV) for derivative trades.
→ Treasury and Risk Management → Credit Risk Analyzer → Basic Settings → Definitions →
Define Determination Procedures.

Figure 729: Attributable Amount Determination
Animation: Attributable Amount Determination

For more information on Attributable Amount Determination, please view the
The diagram above shows the relationship between the different elements in Credit Risk
Analyzer.
If a transaction represents more than one risk (counterparty credit risk, issuer credit risk, or
counterparty settlement risk), it is possible to calculate several attributable amounts. This is
controlled by your choice of determination procedure. The determination procedure is a set
of methods used to determine attributable amounts for credit risk for all transactions that
represent a particular risk category.
This means that if a transaction contains both credit risk and settlement risk, at least two
determination procedures are required to measure both these risks. This toolset also permits
the calculation of a transaction's attributable amount for the same risk category to be carried
out in different ways. If required, you can use two determination procedures to value the
credit risk of a money market transaction, for example. One procedure could match your
internal risk control requirements, and the other would fulfill legal requirements. You can
value transactions that have different risk characteristics by differentiated methods within
one determination procedure. This gives you the option of allowing the nominal amount of a
money market transaction to count towards a limit, and taking the NPV in the case of
derivatives. You can adapt this to your individual requirements.
Another important factor for calculating the attributable amount is the default risk rule. This
defines which criteria are used to determine the market value change period and the risk
commitment period of a transaction. You can choose from the options End of term of the
transaction or Interest commitment period of the transaction. The recovery rate
determination is also stored in the default risk rule.

The procedure for determining limit utilization determines the data, calculation formulas, and
risk categories that are to be used for generating the single and total records of limit
utilization. Formula determination is used, for example, to define whether the amount is
calculated using the nominal amount or the net present value.
The definition of determination procedures takes place in connection to the product and cash
flows structure. Determination procedure for e.g. nominal, NPV or a combination of both can
be defined. Show the possible customizing settings and explain the determination procedure
which are relevant for MM, FX, DE and SE.
The credit standing of a counterparty is reflected in the respective rating. The lower the rating
and the longer the risk commitment period, the higher the default probability. Each of these
combinations of rating and risk commitment period is valued with a percentage value and can
be adjusted time-dependently.
Figure 731: Edit Settings for Determination Procedures
The definition for determination procedures and default risk rules are important customizing
settings to ensure the Credit Risk Analyzer works correctly. They are combined to create
formulas for the attributable amount calculation of financial instruments.
An SAP system uses formulas to determine the attributable amounts. For each combination
of determination procedure and default risk rule, you specify the formula to be used to
calculate the attributable amount (amount of risk exposure).
For example:
● The attributable amount is the max (0, calculation basis)
● The attributable amount is the max (0, calculation basis) * default probability (probability
of default)
There is one determination procedure needed, which is for the market value (NPV) of trades.
Each of the determination procedures need to be assigned to the default risk rule. The
formula for market value (NPV) to use is max (0, NPV amount).

To access this configuration node, follow the IMG menu path Financial Supply Chain
Management → Treasury and Risk Management → Credit Risk Analyzer → Attributable
Amount Determination → Edit Settings for Determination Procedures.
Figure 732: Attributable Amount Determination
The credit standing of a counterparty is reflected in the respective rating. The lower the rating
and the longer the risk commitment period, the higher the default probability. Each of these
combinations of rating and risk commitment period is valued with a percentage value and can
be adjusted time-dependently.
The value entered in this configuration step is the likelihood of a business partner paying less
than is due or going into default.
To access this configuration node, follow the IMG menu path Financial Supply Chain
Amount Determination → Edit Counterparty Default Probabilities.
Figure 733: Edit Recovery Rates
Recovery rates play a critical role in the estimation and pricing of credit risk, and yet to date
this has been a neglected area - both in terms of financial modeling and empirical research.
Recovery rates are an often-neglected aspect of credit risk analysis. The emphasis on
validating the accuracy of default probabilities and default correlations often obscures their
importance, but a few simple examples serve to highlight the effect that even a first order
improvement in estimation can make:
Example: Expected loss on a standalone loan assuming an exposure of R100, an EDF of 0.1,
and a recovery rate of 50%. Then:

Expected loss = exposure * EDF * LGD

Expected loss = R100 * 0,1 * 0,5
Management → Treasury and Risk Management → Credit Risk Analyzer → Basic Settings →
Definitions → Define Recovery Rate Class.
In connection to the rating different recovery rates are defined. The defined recovery rates
are now assigned a percentage value which, if the business partner defaults, describes the
amount of receivables that will probably be paid.
Amount Determination → Edit Recovery Rates.
Limit Product Groups
Figure 734: Structure of Limit Attributes
Animation: Structure of Limit Attributes

For more information on Structure of Limit Attributes, please view the animation
in the lesson Credit Risk Analyzer, online in the SAP Learning Hub.
In addition to internal and external limit requirements, a company specific limit structure
needs to be defined. Specially, for BASEL II it is required that business partner limits are
reported.
The combination of limit characteristics makes it possible to form multidimensional limit
types. See the 'Define Limit Types' slides to see the different characteristics available.
By enabling you to combine different limit characteristics in a limit type, the system provides
a flexible range of options for limiting your default risks and monitoring the activities of your
traders. The limit is then stored in a limit characteristic combination. In the above example,

the trader Smith can enter into a default risk situation of a maximum of 1 million euros for the
product type foreign exchange transactions. In this case, it does not matter with which
business partner the transaction is made.
By defining a three-dimensional limit type, it is possible to take the business partner into
account as well. For example, to make sure that your money market trader does not exceed a
certain exposure level with a business partner, you could define a limit type with the limit
characteristics trader, limit product group, and business partner, and then set a limit amount
for the exposure.
Figure 736: Define Limit Product Groups
Animation: Define Limit Product Groups

For more information on Define Limit Product Groups, please view the animation
in the lesson Credit Risk Analyzer, online in the SAP Learning Hub.
For each contract type, at least one limit product group should be defined. In other words, all
trades should fall into one limit product group.
Limit product groups can be used to combine specific trades or transactions into subgroups.
Using limit product groups as a limit characteristic, you are able to assign limit amounts to the
limit product group, which is what you have done for this use case scenario. In the use case
scenario, you specified that the amount of investment trades with a group business partner or
bank should not exceed $15 million, that the amount of derivative trades with a group
business partner or bank should not exceed $25 million, and that the amount of cash
balances with a group business partner or bank should not exceed $5 million. The total of the
subgroups ($40 million) is the maximum amount that should be exposed to a group bank.
→ Treasury and Risk Management → Credit Risk Analyzer → Limit Management → Define
Limit Product Groups.
● Enter a three character key for each limit product group

● Enter a textual description for each limit product group
After you have defined the limit product groups, you can use the limit product groups as a
characteristic to the limits that are to be maintained.
Limit Types
Figure 738: Define Limit Types
The limit types determine which combinations of limit characteristic limits and limit
utilizations refer to.
The last configuration step is to define limit types. The definition of limit types pulls together
most of the Credit Risk Analyzer configuration to meet the business requirements. This is key
configuration for Credit Risk Analyzer. The limit types determine which determination
procedures are used and which transactions are taken into account in calculating limit
utilizations.
The limit type is the key limit management instrument. You must first define limit types in the
system settings before you can create limits and calculate the corresponding limit utilizations.
In the first step, only the name of the limit type is specified. The characteristics and filters are
defined afterwards. You do not have to include filter attributes. One major step is to assign to
each limit type a determination procedure. If you use a hierarchy solution, the determination
procedure for each level is the same.
For example, the limit type configuration drives that the transactions are tracked at a global
business partner level, by country, or by portfolio. Limits are defined by one or more
characteristics. Credit Risk Analyzer provides you the seven direct characteristics for the
default risk limit: company code, business partner, limit product group, portfolio, trader,
currency, and monitoring unit. In addition, the country, industry, and credit rating are indirect
characteristics that can be derived from the business partner master record. In addition,
there can be up to 15 additional characteristics individually using a custom exit. The limit type
characteristics for my use case scenario are business partner and limit product group.
→ Treasury and Risk Management → Credit Risk Analyzer → Limit Management → Define
Limit Types.

The following fields are relevant to this configuration step:

The Determination Procedure defines the type of risk to be calculated by the limit type. The
types of risk in the use case scenario are nominal value and market value (NPV). Enter the
determination procedure created in the "Define Determination Procedure" configuration step.
Using the Transactions field you specify whether only asset or only liability trades are included
in the utilization determination, or whether asset and liability trades are to be totaled or
accumulated. Set the Transactions field to Netting of asset-side and liability-side transactions
because my use case scenario specified to use trades on a net basis. (This means the
incoming and outgoing flows for a trade should be netted to determine the attributable
amount for the trade.)
The Update Category sets when utilizations are generated. The choices are 1 - Only update
when utilizations are generated and 2 - Update when utilizations are generated and online.
Select (2) so that utilizations are updated both when trades are entered and when the end-of-
day processing program (transaction code KLNACHT) is run.
The Limit Currency field is used to determine the currency in which limits are kept. Enter the
currency the limits should be displayed in in this field. For my use case scenario, enter USD. If
the currency field is not populated, the SAP system uses the company currency.
The Generate Limits Automatically field controls if limits are generated automatically if they
have not yet been created. If the indicator automatically generate limits is not set, making a
trade does not result in any update of utilizations if a limit has not already been created. Set
the field to Generate limit with check because you only know if a limit has been exceeded if
there is a limit of at least 0.
With the Early warning cntrl field, you can specify whether a warning should be given when a
percentage barrier or the external limit is reached. For example, you can specify that once 90
percent of the limit is utilized, a warning message is triggered as new trades are entered into
the SAP system. Set the Early Warning Cntrl field to Percentage Barrier to activate the
warning at a percentage level (e.g. activate the warning when the limit is 90 percent or more
utilized).
The Release Section
The Release section controls if a release step is required when new limits are added or
existing limits are changed. Select the Release Active indicator and set the Initial Release
Status to Limit flagged for release to require releasing of limits.
A release workflow for the definition of limit master data settings can be defined. The initial
release status is the status which is set when a release-relevant limit is changed.
● If an initial status of "0" is set, and release is active, when a limit is changed, it will be set to
status "0", "Limit is not released". Later, the same user can mark the limit as requiring
release by a second user.
● If the initial status is "1", and release is active, when a limit is changed, it will be directly set
to release status "1", "Limit is marked for release".
● In both cases, changes have to be released by a second user to achieve status "2", "Limit is
released".

Figure 739: Define Limit Types
In the example above, we have selected limit type Y03 (Business partner only), and assigned
only the characteristic business partner to it.
The limit characteristics listed above can be assigned to a limit type individually or in any
combination:
● The business partner can be interpreted as the counterparty or the issuer.
● The monitoring unit is a free field in the transaction data that can be filled with anything
you want. A limit can be assigned to all transactions with the same field assignments.
● Using a user exit, you can derive up to 15 customer characteristics from existing limit
characteristics. This enables you, for example, to create a limit for the country group Latin
America, against which every transaction with business partners in this region would be
checked. Latin America would in this case be a value of customer characteristic
"Geographic country group." The characteristics country risk country, internal
organizational unit, and country rating are available only in the banking solution and are
used if the country risk is active.
Generated characteristics refer to characteristics that were generated in Limit Management

from the active analysis structure of the Market Risk component, and can be used as limit
characteristics there. These characteristics can be defined freely.
Keep in mind, only characteristics which are part of the analyzing structure can be reported
and assigned.
Once you have defined the limit type you can assign the limit characteristics. Only
characteristic which are assigned to the active analysis structure can be filled and reported.
Hint: The country for country risk, internal organizational unit, and country rating
characteristics are available only in the banking solution. Generated characteristics are those
characteristics that were taken from the active analysis structure in the Market Risk
component and generated in Limit Management. They can then be used as limit
characteristics in Limit Management. These characteristics are user-defined.
SAP provides the following characteristics by default:

● Company code
● Product type
● Limit product group
● Business partner
● Sector
● Trader
● Security ID number
● Country
● Portfolio
● Currency
● Monitoring unit
● Contract type
In addition, there are 15 characteristics that you can define individually for evaluation
purposes. These characteristics do not necessarily have to occur at a different point in the
system already
Customer characteristic 1 - 15
Lastly, you can include up to 50 characteristics using direct table access or make them
available to the credit risk analyzer using the characteristics of Market Risk Analyzer.
Structure of Limit Attribution (Hierarchy)
Figure 740: Structure of Limit Attribution (Hierarchy)

Animation: Structure of Limit Attribution (Hierarchy)

For more information on Structure of Limit Attribution (Hierarchy), please view
the animation in the lesson Credit Risk Analyzer, online in the SAP Learning Hub.
The above picture shows an example of the structure of limit attribution. Limit types have no
clear structure, only the relevant levels are reported.
Information from one to many characteristics can be included in the definition of limit types.
The characteristic value of a particular limit type should always be regarded in conjunction
with the internal company limit structure. When you define the limit structure, you should
therefore make sure that the number of limit types used remains manageable, since it is
otherwise difficult to produce meaningful reports.
Derive Default Risk Control Parameters for Derivatives
Figure 742: Derive Default Risk Control Parameters for Derivatives
In this configuration node, the derivation strategies used to derive the characteristic values
defined for each trade or financial object are defined for Credit Risk Analyzer. The derivation
strategies may be derivation rules, table lookups, moves, clears, or enhancements. The
derivation strategies populate the characteristics in Credit Risk Analyzer structures for each
trade or financial object on the Default Risk Limit tab of trades. Any characteristic values used
in the limit types should be automatically populated using the derivation rules.
The derivation rules are configured in two steps. First the derivation strategy is specified,
then, depending on the derivation rule specified, the source and target fields are specified.
Once the structure of the derivation rule has been specified, the rule entries have to be
maintained. Use the Maintain Rule Entries button to do so. For each product type, you have to
assign a default risk rule and a limit product group. This assignment enables you to use
different limit product groups in the derivatives area.
In this step, you can define the derivation strategy. A derivation strategy consists of several
derivation steps that can be used to derive characteristic values and other control parameters

one after another. In each of these steps, you assign a derivation type, which is used to fill a
given set of target fields on the basis of a given set of source fields. In this way, a logical link
between target and source fields is defined for each step.
The following types of derivation steps are possible:
● Derivation rules
● Table accesses
● Assignments
● Initializations
In addition, customer specific derivation steps can be added using customer exit FKLA0001.
In this configuration step, the following derivation rules are created for derivative trades:
● Activate the Counterparty/Issuer Risk Active indicator
● Assign the limit product group
● Populate the business partner field
● Assign the Default Risk Rule, which was created in the Define a Default Risk Rule
configuration step.
To complete this step, follow IMG menu path Financial Supply Chain Management → Treasury
and Risk Management → Credit Risk Analyzer → Basic Settings → Automatic Integration of
Financial Objects in Transaction Master Data → OTC Derivatives → Derive Default Risk
Control Parameters for Derivatives.
Note: To capture your derivation strategy configuration, you must select each derivation
strategy and click the transport icon. The derivation strategy configuration is saved to a
workbench transport.
Set Up Limit Types and Limits
Simulation: Set Up Limit Types and Limits

For more information on Set Up Limit Types and Limits, please view the
simulation in the lesson Credit Risk Analyzer online in the SAP Learning Hub.

Unit 9
Exercise 40
Business Example
You need to set up a limit structure to fit new internal and external requirements. Create a
new limit type and new limit structure.
Use the characteristics company code, business partner, limit product group, and portfolio
for this exercise.
Note:
1. View the customizing of the existing limit structure using limit types Y21 and Y29.
2. Create a new hierarchy limit structure that includes the characteristics company code,
business partner, limit product group, and portfolio. Write down the limit structure. Create
limit types E## and F## and assign the following characteristics to each: E##: Company
Code, Business Partner Number, and Limit Product Group. F##: Company Code,
Business Partner Number, Limit Product Group, and Portfolio.
Table 113: E## Limit Type Details

Limit type E##

Name of limit type EE##: CoCd/BP/LPG (Nominal)
Determination procedure 20
Transactions Netting of asset-side and liability-side
transactions
Update category Update when utilizations are generated and
online
Limit currency -
Selection filter -
Autom. limit Do not generate limit
Early warning control Percentage Barrier

Table 114: F## Limit Type Details

Limit type F##

Name of limit type FF##: CoCd/BP/ LPG(Nom.)Portf.
transactions
online
Limit currency -
Selection filter -

Unit 9
Solution 40
Business Example
You need to set up a limit structure to fit new internal and external requirements. Create a
new limit type and new limit structure.
Use the characteristics company code, business partner, limit product group, and portfolio
for this exercise.
Note:
1. View the customizing of the existing limit structure using limit types Y21 and Y29.
a) The existing limit structure using limit types Y21 and Y29 can be referenced. In the next
step, additional characteristics will be added to new limit types. In this step, view the
definition in customizing of limit types Y21 and Y29.
Figure 744: Limit Hierarchy
2. Create a new hierarchy limit structure that includes the characteristics company code,
business partner, limit product group, and portfolio. Write down the limit structure. Create
limit types E## and F## and assign the following characteristics to each: E##: Company
Code, Business Partner Number, and Limit Product Group. F##: Company Code,
Business Partner Number, Limit Product Group, and Portfolio.

Table 113: E## Limit Type Details

Limit type E##

Name of limit type EE##: CoCd/BP/LPG (Nominal)
transactions
online
Limit currency -
Selection filter -
Table 114: F## Limit Type Details

Limit type F##

Name of limit type FF##: CoCd/BP/ LPG(Nom.)Portf.
transactions
online
Limit currency -
Selection filter -

Management → Treasury and Risk Management → Credit Risk Analyzer → Limit
Management → Define Limit Types.
The existing limit types Y21 and Y29 can be used. New limit types need to be set up
only for characteristics company code, business partner, limit product group (E##)
and company code, business partner, limit product group, and portfolio (F##).
b) Change to edit mode, and choose New Entries.
c) For the E## limit type, enter the data provided in the table, E## Limit Type Details.

d) Assign the characteristics Company Code, Business Partner Number, and Limit
Product Group to the new defined limit type E##. Select the limit type E## and choose
the Assign Limit Characteristics folder. Select characteristics as following:
● Company Code
● Limit Product Group
e) Choose Save.
f) For the F## limit type, enter the data provided in the table, F## Limit Type Details.
g) Assign the characteristics Company Code, Business Partner Number, Limit Product
Group and Portfolio to the new defined limit type F##. Select the limit type F## and
choose the Assign Limit Characteristics folder. Select characteristics as following:
● Company Code
● Limit Product Group
● Portfolio
h) Choose Save.

How to Define a Limit Type
Simulation: How to Define a Limit Type

For more information on How to Define a Limit Type, please view the simulation
in the lesson Credit Risk Analyzer online in the SAP Learning Hub.
How to Create a Credit Risk Analyzer Trade
Simulation: How to Create a Credit Risk Analyzer Trade

For more information on How to Create a Credit Risk Analyzer Trade, please view
the simulation in the lesson Credit Risk Analyzer online in the SAP Learning Hub.
How to View Limit Management Reports
Simulation: How to View Limit Management Reports

For more information on How to View Limit Management Reports, please view
Set Up the Limit Management Application
Simulation: Set Up the Limit Management Application

For more information on Set Up the Limit Management Application, please view

Unit 9
Exercise 41
Business Example
You want to understand the full application process for Limit Management. Use CRA as a
central limit management tool and set up an individual limit amount for the defined limit
types. After that, execute the end-of-day processing run.
Dependencies
● A portfolio was created in a previous exercise.
● Limit types E## and F## were created in a previous exercise.
Note:
1. Maintain a limit for limit types Y21, Y29, E##, and F##.
Table 115: Limit Details 1

Company Code TA##

Limit Group MM
Portfolio S4F51-##

Valid To (Internal) 31/12/9999

Valid To (External) 31/12/9999
Limit Currency EUR
Limits Check
Internal limit amount 10000000
External limit amount 10000000
Critical Limit Utilization in % 90

Max. Risk Commit. per Month 12
Table 117: Limit Amounts

Limit Type Limit Amount
Y21 (Company Code) 50000000

Y29 (Company Code + Business Partner) 30000000
E## (Company Code + Business Partner + 15000000
LPG)
F## (CoCd/BP/ LPG(Nom.)Portf.) 10000000
2. Start the End-of-Day Processing tile (Treasury - Credit Risk Analyzer) and enter
determination procedure interval 10-20 and log level 4.
Valuation Date today

Determination Procedure 10 to 20
Log Level 4
Company Code TA##
3. Create a money market transaction for product type 55A and transaction type 100. Use
business partner BP##. Invest am amount of 1 million EUR from now for 2 months. The
current market rate is 2.3%. Execute an online limit check for this financial transaction.
Company Code TA##

Product Type 55A
Amount 1M
Start of Term Today’s date
End of Term ++2 (for two months into the future)
Interest Structure – Percentage 2%
Int.Calc.Method Act/360 (proposed)
Frequency Monthly

Note the number of the financial transaction.
4. Check the limit attribution in the application using the Limit Utilization Analysis - Simplified
tile (Treasury - Credit Risk Analyzer) and the Limit Utilization tile (Treasury - Credit Risk
Analyzer).
Table 118: Simplified Overview

Limit type E##, F##, Y03, Y21, Y29

Limit Utilization Base 1 to 2
Determination date today
Company Code TA##
Table 119: Limit Utilization


Validity date for utilization today - 31/12/9999
Company Code TA##

Unit 9
Solution 41
Business Example
You want to understand the full application process for Limit Management. Use CRA as a
central limit management tool and set up an individual limit amount for the defined limit
types. After that, execute the end-of-day processing run.
Dependencies
● A portfolio was created in a previous exercise.
● Limit types E## and F## were created in a previous exercise.
Note:
1. Maintain a limit for limit types Y21, Y29, E##, and F##.

Company Code TA##

Limit Group MM
Portfolio S4F51-##

Valid To (Internal) 31/12/9999

Valid To (External) 31/12/9999
Limit Currency EUR
Limits Check
Internal limit amount 10000000
External limit amount 10000000
Critical Limit Utilization in % 90

Max. Risk Commit. per Month 12
Table 117: Limit Amounts

Limit Type Limit Amount
Y21 (Company Code) 50000000

Y29 (Company Code + Business Partner) 30000000
E## (Company Code + Business Partner + 15000000
LPG)
F## (CoCd/BP/ LPG(Nom.)Portf.) 10000000
a) Choose the Maintain Limits tile (Treasury - Credit Risk Analyzer).
b) Maintain limits for limit types Y21, Y29, E##, and F##.
c) Select the indicator to the left of limit type F##, choose Create Limits.
d) Enter the data provided in the table, Limit Details 1, and confirm the settings.
e) Enter the data provided in the table, Limit Details 2.
f) Choose Save.
g) Repeat these steps for limit types Y21, Y29, and E##. Use the data provided in the
table Limit Amounts.
2. Start the End-of-Day Processing tile (Treasury - Credit Risk Analyzer) and enter
determination procedure interval 10-20 and log level 4.
Valuation Date today

Determination Procedure 10 to 20
Log Level 4
Company Code TA##
a) For attribution to take place based on the determination procedures, choose the End-
of-Day Processing tile (Treasury - Credit Risk Analyzer).
b) After entering the inputs, press the Execute button to run the End-of-Day Processing
program.
3. Create a money market transaction for product type 55A and transaction type 100. Use
business partner BP##. Invest am amount of 1 million EUR from now for 2 months. The
current market rate is 2.3%. Execute an online limit check for this financial transaction.
Company Code TA##

Product Type 55A


Amount 1M
Start of Term Today’s date
End of Term ++2 (for two months into the future)
Interest Structure – Percentage 2%
Int.Calc.Method Act/360 (proposed)
Frequency Monthly
Note the number of the financial transaction.
b) Create an investment and execute an online limit check before you save this
transaction. Use the data provided in the table.
c) Switch to the Default Risk Limit tab.

The characteristics populated on the tab are due to the derivation strategy
customizing. To view the derivation history for this trade, in the Functions area of the
screen, choose Display Derivation Log.
d) To perform the online check, in the Functions area of the screen, choose Limit
Utilization Details.
In the dialog, the utilized amount and the remaining difference between it and the limit
maintained display. When the traffic light is green, you can see that no limit is
exceeded and nothing has approached the limit.
e) Choose Save to save the trade.
4. Check the limit attribution in the application using the Limit Utilization Analysis - Simplified
tile (Treasury - Credit Risk Analyzer) and the Limit Utilization tile (Treasury - Credit Risk
Analyzer).
Table 118: Simplified Overview


Company Code TA##

Table 119: Limit Utilization


Validity date for utilization today - 31/12/9999
Company Code TA##
a) Choose the Limits utilization Analysis - Simplified (TISCLU) tile, and maintain the
data provided in the table, Simplified Overview.
b) Press the Execute button.
c) Review the results.
d) Choose the Limit Utilization Analysis tile, and maintain the data provided in the table,
Limit Utilization.
e) Press the Execute button.
f) Review the results.
g) Select the indicator to the left of one of the output lines for Y03 (limit by Business
Partner), and press the Individual Utilization button to view the financial transactions
making up the utilization.

LESSON SUMMARY

Unit 9
Learning Assessment
1. Which of the following fields are available to be used as characteristics in Market Risk
Analyzer using SAP standard functionality?
X A Business Partner.
X B Country.
X C Trader.
X D Profit Center.
2. The Market Risk Analyzer helps with the following.

X A Helps to analyze and minimize risk including optimizing the companies financial
position.
X B Helps to minimize risk by setting and monitoring limits to business partners.
X C Helps to analyze risk and to optimize companies financial position.
3. What are inputs to Market Risk Analyzer reports?

X A Transaction Manager trades
X B Market Data
X C AP invoices
X D Profit Centers

4. Which of the following fields are available to be used as characteristics in Credit Risk
Analyzer using SAP standard functionality?
X A Business Partner.
X B Planning Level.
X C Trader.
X D Profit Center.
5. Which of the following is true with respect to the attributable amount for counterparty
Default Risk?
X A Net Present value (NPV) only.
X B NPV or nominal are used as the basis of calculation.
6. Which are the features of the Credit Risk Analyzer?

X A Limit Management.
X B Simulation Scenarios.
X C Interim Limits.
X D Measurement of Utilization.
X E Online Limit Check.

UNIT 10 Commodities
Lesson 1
Understanding Commodities 791
Lesson 2
Defining Commodities Basic Data 794
Exercise 42: Define Commodity Market Data Elements 799
Lesson 3
Understanding Derivative Contract Specifications 805
Lesson 4
Defining Period Determination 811
Lesson 5
Defining Commodity Trade Types 814
Exercise 43: Define Product and Transaction Type Commodities 819
Exercise 44: Assign Flow Types Commodity Product Types 825
Exercise 45: Define Open and Close Position Commodities 829
Exercise 46: Create a Commodity Transaction 833
UNIT OBJECTIVES
● Understand the SAP Commodity Management solution

● Understand the end-to-end process flow for commodities
● Define commodities basic data
● Understand derivative contract specifications
● Define period determination
● Define commodity trade types
● Understand the end-to-end process flow
● Understand the settings made at the product type, transaction type, and flow type levels

Unit 10: Commodities

Unit 10
Lesson 1
Understanding Commodities
LESSON OBJECTIVES
Commodities Overview
Commodities Building Blocks
Figure 749: Commodities Building Blocks
Only SAP offers Commodity Management in a unified and integrated platform with embedded
intelligent technologies.
SAP Commodity Management is part of the intelligent suite - powered by SAP Leonardo.
It is a single instance with fully integrated end-to-end processes that utilizes SAP's latest
technology.

Figure 750: Commodities Building Blocks
The SAP Commodity Management solution streamlines business processes from end-to-end
- enabling accurate, timely, and profitable procurement, sales, and hedging of commodities.
In addition, the Commodity Management solution fits into the back-office and accounting
framework that is part of the Treasury and Risk Management solution.
Business units that do not align on commodity management now have a platform on which to
collaborate resulting in an effective and efficient solution across multiple disciplines. Different
departments of an organization now have one version of the truth.
SAP Commodity Management Functionality
Figure 751: SAP Commodity Management functionality
The system supports the requirements from the definition and capture of commodity
contracts through back-office processing and risk management.
There is snapshot functionality to record the current situation as well as end-of-day mark-to-
market reporting. This is in addition to the SAP standard functionality supporting a full audit
trail on all transactions and processing.

Lesson: Understanding Commodities
SAP S/4HANA Commodity Risk Management Application
Figure 752: SAP S/4HANA Commodity Risk Management application
Here we see the functionality available at each point along the life cycle of the commodities
trades. As mentioned, the Commodities module uses the Treasury and Risk Management
framework for deal capture and back-office processing.
The Key Functions and Features of the Commodities Risk Management Application are the
following:
● Financial Transactions Management for Commodity Derivative Types Futures, Options,
Swaps and Forwards, seamlessly provided within the underlying SAP Treasury and Risk
Management functionality
● Full integration into SAP Accounting and SAP Payment Engine functionality.
● Query based real time and end-of-day commodity risk reporting including financial
commodity derivatives, physical transactions* and material stock*, covering
- Position reporting
- Mark-to-Market reporting
- Day-over-day TpL (Traders P&L) reporting
*Risk reporting including physical commodity transactions and material stock is only
provided within SAP Commodity Risk Management, requires however additional deployment
and licensing of either SAP Commodity Management for S/4HANA or SAP Agricultural
Contract Management for SAP S/4HANA.
LESSON SUMMARY

Unit 10
Lesson 2
Defining Commodities Basic Data
LESSON OBJECTIVES
Commodities Basic Data
Figure 753: Define Commodities Basic Data
The Commodities Risk Management processes and functionality follows the same trade
entry, back office processing and accounting framework that the other Treasury and Risk
Management submodules follow.
Some Commodities are traded at exchanges as physically or cash settled futures. Other
exchange traded derivatives are Options on Futures. In these cases, the exchanges publish
reference prices after or during their trading session (Open prices, Mid term, Closing,
Settlement) that are then are used as reference prices for the price calculations of physical
commodity trades. These prices are also used as reference prices for the cash settlement of
OTC-Commodity Derivatives. For other commodity markets with either lesser liquidity or
more regional or commodity related quality distinctions, specialized market data provider
assess the physical trading markets and publish commodity reference price information that
are then equally used for physical and financial OTC-Derivative trading. SAP Commodity Risk
Management manages both types or such original market data as well as option market data
based on the general data model of Derivative Contract Specification (DCS), by 3 different
categories ( "Future", "Forward Index" and "Listed Options").

Lesson: Defining Commodities Basic Data
Note:
To activate the Commodities functionality, the business function
FIN_TRM_COMM_RM needs to be activated. Please consult with your SAP
Account Executive before activating this business function.
Figure 754: Specify Commodities
In this customizing activity, you specify the commodities that will be the underlying of the
derivatives traded. Commodities represent traded goods with a specific quality.
For each commodity a basis measure of unit is specified. This unit defines the primary
quantity reporting for this commodity in SAP Commodity Risk Reporting. The dimension of
this unit (Mass, Volume, Energy) also defines the potential units of measure that can be used
in DCS-definitions or financial commodity derivatives related to this commodity. They all need
to be in the dimension of the unit of measure defined for the commodity to be able to be
deployed and to converted between each other.
Therefore, even if the same sort of commodity is traded in two different DCSs, different
physical commodities may need to be defined. For example, heating oil that is traded in
gallons (Dimension Volume) in the US but in metric tons (Dimension Mass) in Europe. Wheat
are corn are traded in bushels (Dimension Volume) in the US and in metric tons (Dimension
Mass) in the rest of the world.
Examples of commodities may be:
● Grade A Copper
● Light Sweet Crude Oil (WTI)
● Brent Crude Oil
● CBOT Soft Red Wheat
● EURONEXT Milling Wheat
● Gold
● Silver
● Steel

Transaction Manager → Market Data Management → Master Data → Market Data Based on
Derivative Contract Specifications → Commodities → Specify Commodities.
Specify Market Identifier Codes
Figure 755: Specify Market Identifier Codes
In this customizing step, Market Identifier Codes (MICs) are defined.

MICs identify the markets on which your commodities are traded. MICs are assigned to
derivative contract specifications (DCS). This assignment dependent on which market
commodity forward or future is traded. For each MIC, you can specify an individual calendar
that is used in identifying the commodity that is traded.
MICs are applied according to the ISO 10383. See http://www.iso10383.org/ for more
information on ISO 10383.
This customizing node is located in the IMG under Treasury and Risk Management→
Derivative Contract Specifications → Specify Market Identifier Codes.
Assign Exchanges to Market Identifier Codes
Figure 756: Assign Exchanges to Market Identifier Codes
In this customizing step, exchanges are assigned to MICs. These represent the exchanges
represented by the MICs.
For example, you have defined the Exchange LSE - London Stock Exchange and the Market
Identifier Code XLME - London Metal Exchange MICs. Now you want to assign the
corresponding exchanges, e.g. LSE - London Stock Exchange to XLME - London Metal
Exchange, to the MICs.
This customizing node is located in the IMG under Treasury and Risk Management → Basic
Functions → Market Data Management → Master Data → Commodities → Derivative
Contract Specification and MIC → Assign Exchanges to Market Identifier Codes.

Figure 757: Assign Exchanges to Market Identifier Codes
In this customizing step, exchanges are assigned to MICs. These represent the actual
exchanges represented by the MICs.
For example, you have defined the Exchange LSE - London Stock Exchange and the Market
Identifier Code XLME - London Metal Exchange MICs. Now you want to assign the
corresponding exchanges, e.g. LSE - London Stock Exchange to XLME - London Metal
Exchange, to the MICs.
Derivative Contract Specifications → Assign Exchanges to Market Identifier Codes.
Define Commodity Market Data Elements
Simulation: Define Commodity Market Data Elements

For more information on Define Commodity Market Data Elements, please view
the simulation in the lesson Defining Commodities Basic Data online in the SAP
Learning Hub.


Unit 10
Exercise 42
Business Example
Your company will start trading commodity derivatives. You need to specify commodities,
define a MIC, and assign the MIC to an exchange.
Dependencies: There are no dependencies to this exercise.
Note:
1. Specify a commodity in the system using the following data:

Field Name Value
Commodity STEEL_SCRAP_##
Description <Give a description based on your prefer-
ence>
UoM KT
CommTyp 4 - Steel
2. Create a Market Identifier Code (MIC) where your commodities are traded using the
following data:
Field Name Value
MIC M##
Description <Description of an exchange>
CME ##
Country US
City Chicago
Status Active
Calendar US
MIC Can Be Used <select>

Field Name Value
MIC URL https://www.cmegroup.com/
3. Assign your MIC to an exchange using the following data:

Field Name Value
MIC M##
Exchange CME

Unit 10
Solution 42
Business Example
Your company will start trading commodity derivatives. You need to specify commodities,
define a MIC, and assign the MIC to an exchange.
Dependencies: There are no dependencies to this exercise.
Note:
1. Specify a commodity in the system using the following data:

Field Name Value
Commodity STEEL_SCRAP_##
Description <Give a description based on your prefer-
ence>
UoM KT
CommTyp 4 - Steel

Management → Master Data → Commodities → Specify Commodities.
b) Choose New Entries and enter the data provided in the table.
c) Save your entry.
2. Create a Market Identifier Code (MIC) where your commodities are traded using the
following data:
Field Name Value
MIC M##
Description <Description of an exchange>
CME ##
Country US

Field Name Value
City Chicago
Status Active
Calendar US
MIC Can Be Used <select>
MIC URL https://www.cmegroup.com/

Management → Master Data → Specify Market Identifier Codes.
c) Save your entry.
3. Assign your MIC to an exchange using the following data:

Field Name Value
MIC M##
Exchange CME

Management → Master Data → Commodities → Derivative Contract Specification
→ Assign Exchanges to Market Identifier Codes.
c) Save your entry.

LESSON SUMMARY


Unit 10
Lesson 3
Understanding Derivative Contract
Specifications
LESSON OBJECTIVES
Derivative Contract Specification

Specify Period Determination Methods
Figure 759: Specify Period Determination Methods
Animation: Specify Period Determination Methods

For more information on Specify Period Determination Methods, please view the
animation in the lesson Understanding Derivative Contract Specifications, online
in the SAP Learning Hub.
In this customizing activity, you specify period determination methods that can be used as a
filter for specific BAdI implementations.
These methods are used to determine the dates of the specific traded contracts as stated in
the contract specifications published by the exchanges. They are deployed in a DCS to
calculate the contract periods exactly as defined by the exchange.
A specific traded contract period is identified in SAP by a "maturity key date", to which the
related period information as e.g. contract period, trading period, quotation period, physical
settlement period, etc., are stored. All this information is to be calculated by the BAdI
implementations.
For all the methods that are defined, a BAdI implementation must be implemented.
SAP delivers the above shown Period Determination Methods and according BAdI
implementations as defaults and examples. They can either used directly, if they meet the

customer's requirements, or they can be used as a reference to be copied and to enable

customers to implement the logic they need.
As alternative, SAP also allows the period determination for a DCS to be set manually.
Contract Specifications and MIC → Period Determination → Specify Period Determination
Methods.
This BAdI implementations can be created and accessed also in the IMG under Treasury and
Risk Management → Basic Functions → Market Data Management → Master Data →
Commodities → Derivative Contract Specifications and MIC → Period Determination →
Commodity Futures and Listed Options → BAdI Period Determination Methods.
Specify LME-Specific Period Determination
Figure 761: Specify LME-Specific Period Determination
In this Customizing activity, you define London Metal Exchange-specific (LME) settings of the
BAdI implementation for period determination. You can make the required settings for the
determination of periods where daily, weekly, or monthly futures are identified.
For each combination of period determination method and physical commodity, you can
specify the number of months for daily, weekly, and monthly futures. In addition, you can
enter the Valid From date to specify when the settings for period determination take effect.
The system considers only the last valid settings for a specific combination of a period
determination method and a physical commodity. You can also specify an individual calendar
that is used to identify the non-trading periods of the LME.
Note:
Once you have entered the settings of a new combination of a period
determination method and a physical commodity, the specified number of months
for daily, weekly, and monthly futures can only be retained or increased.
Reducing the number of periods would lead to the loss of derivatives that might already be
used by the period determination for several transactions, like security master data, CPE
data, or market data.
By default, the implementations EI_BADI_TBA_DCS_DYN_PER_LME (for futures on the LME:
period determination method LME) and EI_BADI_TBA_DCS_DYN_PER_LME_M (for LME mini-
futures: period determination method LMEM) are provided.
For example, for the period determination method LME, the following data could be applied:
On the London Metal Exchange and for the commodity Copper, futures are traded over three
months daily, over the subsequent 3 months weekly, and over 123 months monthly.
Derivative Contract Specifications → Derivative Contract Specifications → Period
Determination → Specify LME-Specify Period Determination.

Lesson: Understanding Derivative Contract Specifications
In this Customizing activity, you define London Metal Exchange-specific (LME) settings to be
deployed in the SAP delivered BAdI implementation for period determination. You can make
the required settings for the determination of periods regarding the number of daily, weekly,
or monthly futures that are traded and that the periods need to be determined for.
For each combination of period determination method and commodity, you can specify the
number of months for daily, weekly, and monthly futures. In addition, you can enter the Valid
From date to specify when the settings for period determination take effect.
that is used to identify the prompt dates (settlement dates) for the LME Futures and Options.
By default, the implementations EI_BADI_TBA_DCS_DYN_PER_LME (for futures on the LME:
period determination method LME) and EI_BADI_TBA_DCS_DYN_PER_LME_M (for LME mini-
futures: period determination method LMEM) are provided.
For example, for the period determination method LME, the following data would be
applicable: On the London Metal Exchange and for the commodity copper, over the next three
months, daily futures are traded (so a dedicated future contract for each non holiday date
according to the prompt date calendar for the next 3 month in the future), over the
subsequent 3 months one future per week (with prompt date on Wednesday) and for over 117
months futures with prompt date at the 3rd Wednesday in the month.
Contract Specifications and MIC → Period Determination → Commodity Futures and Listed
Options → Specify LME-Specify Period Determination.
Specify Security ID Determination Methods
Figure 763: Specify Security ID Determination Methods

In this customizing activity, you specify security ID determination methods that are used as
BAdI filters to implement an automated determination of a proposal for the security class ID
when creating a DCS related Future Class by transaction FWZZ or by a BAPI call.
SAP delivers above method as defaults and examples that match to the common
methodologies how specific traded future contracts are identified in the market.
They combine the Product Symbol <ps> as defined in a DCS with the contract period end
date as defined in the period determination.
Customers can define and implement their own methods. Each method specified requires a
specific BAdI implementation.
For security ID determination method "MAN" (for manual), no security ID is proposed when
Security Class data are created.
Contract Specifications and MIC → Specify Security ID Determination Methods.
Specify Determination Methods of Maturity Codes
Figure 764: Specify Determination Methods of Maturity Codes
In this customizing activity, you specify methods of the automatic determination of contract
maturity codes.
For each automatic determination method specified, you also need to assign a BAdI
implementation under BAdI: Automatic Determination of Maturity Codes. As BAdI filters you
use the determination methods defined before.
The customizing entry here shares the definition table with the previously explained Security
ID Determination Method. So for the same Customer Method Definition, different logic could
be implemented to determine the Security IDs and the Contract Maturity Codes. However,
above mentioned SAP implementations provide identical logic for both.
When you define a derivative contract specification (transaction code FDCS01), you can
select a method that determines how the maturity code of the derivative is created. The
implementation for this method as Security ID Determination Method then also defines how
the Security ID is built.
Contract Specifications and MIC → Specify Determination Methods of Maturity Codes.

Lesson: Understanding Derivative Contract Specifications
Derivative Contract Specifications
Figure 765: Define Derivative Contract Specifications
Next, derivative contract specifications (DCS) are defined. A DCS represents a specific
contract specification of an exchange or market. It is a blueprint containing rules and
conditions that are defined by the exchange and that form the contract basis for trading this
specific commodity in the form of Futures. All data that is required for the DCS definition can
be found on the Internet of the respective exchanges and markets.
The DCS, by its period definitions, also defines the granularity and data points for recording
market data. A specific future contract is identified by a specific key date (representing a
settlement date or last trading date), and the relevant prices are stored in the market data
table related to that key date.
A DCS allows the automatic determination of the key dates of the single future contracts that
are traded, so that, for example, DCS with a daily future granularity do not need to be
maintained for a new maturity key date and related periods manually on a daily basis.
Contract Specifications and MIC → Specify Derivative Contract Specifications. It can also be
accessed in production systems using transaction code FDCS01.
Figure 766: Define Derivative Contract Specifications

On the Periods tab, the single traded contracts are identified by the Maturity Key date and
related period types related to it.
As explained previously, the period determination can be maintained either manual or by a

period determination method.
How to Create a Commodity Derivative Contract Specification
Simulation: How to Create a Commodity Derivative Contract Specification

For more information on How to Create a Commodity Derivative Contract
Specification, please view the simulation in the lesson Understanding Derivative
Contract Specifications online in the SAP Learning Hub.
LESSON SUMMARY

Unit 10
Lesson 4
Defining Period Determination
LESSON OBJECTIVES
Period Determination
Figure 768: Specify Period Determination Methods
In this Customizing activity, you specify period determination methods that can be used as a
filter for specific BAdI implementations.
When you specify derivative contract specifications, periods such as the trading period can be
either entered manually or determined automatically by a BAdI implementation. This means
that, for each period determination method, a specific determination logic can be applied. For
all methods provided, a BAdI implementation must be defined here.
Determination → Specify Period Determination Methods.
In this Customizing activity, you define London Metal Exchange-specific (LME) settings of the
BAdI implementation for period determination. You can make the required settings for the
determination of periods where daily, weekly, or monthly futures are identified.

For each combination of period determination method and physical commodity, you can
specify the number of months for daily, weekly, and monthly futures. In addition, you can
enter the Valid From date to specify when the settings for period determination take effect.
that is used to identify the non-trading periods of the LME.
Note: Once you have entered the settings of a new combination of a period determination
method and a physical commodity, the specified number of months for daily, weekly, and
monthly futures can only be retained or increased.
Reducing the number of periods would lead to the loss of derivatives that might already be
used by the period determination for several transactions, like security master data, CPE
data, or market data.
By default, the implementations EI_BADI_TBA_DCS_DYN_PER_LME (for futures on the
LME:period determination method LME) and EI_BADI_TBA_DCS_DYN_PER_LME_M (for LME
mini-futures: period determination method LMEM) are provided.
For example, for the period determination method LME, the following data could be applied:
On the London Metal Exchange and for the commodity Copper, futures are traded over three
months daily, over the subsequent 3 months weekly, and over 123 months monthly.
Determination → Specify LME-Specify Period Determination.
Figure 770: Specify Security ID Determination Methods
In this Customizing activity, you specify security ID determination methods that are used as
BAdI filters to determine the security ID. When you define a derivative contract specification,
you can select a method that determines how the security ID of the derivative is created. For
each method specified, you also need to assign a BAdI implementation.
For security ID determination method "MAN" (for manual), no security ID is generated. This
method can be used for a DCS that is only used for saving market data.
Determination → Specify Security ID Determination Methods.

Lesson: Defining Period Determination
LESSON SUMMARY

Unit 10
Lesson 5
Defining Commodity Trade Types
LESSON OBJECTIVES
Commodity Trade Types
Figure 771: Overview of Derivatives and Commodities
Animation: Overview of Derivatives and Commodities

For more information on Overview of Derivatives and Commodities, please view
the animation in the lesson Defining Commodity Trade Types, online in the SAP
Learning Hub.
Based on the details of the item to be hedged, the hedging instruments will be selected. For
example, to eliminate currency risk, interest rate risk, or commodity risk different hedging
instruments would be selected.
Derivative financial instruments can roughly be divided into exchange transactions (upper half
of right-most box) and option-related transactions (lower half of right-most box). The latter
can also be further subdivided into listed (exchange traded) and OTC (over-the-counter)
options.
The building block concept applies to commodity trade types, as it did to money market and
foreign exchange trade types.

Lesson: Defining Commodity Trade Types
Figure 773: Process Flow of Commodity Forward
This slide shows the process flow for commodity forward, which is a type of commodity
derivative trade. As is clear from above, and will be clear after completing this section, the
process flow and customizing for commodity trades is very similar to other trade types such
as money market and foreign exchange, with just minor differences.
Note that the commodity trade functionality uses the same framework for trade entry, back-
office processing, correspondence, and accounting as are used for the other submodules of
Treasury and Risk Management.
At the define product type level, the product category and settlement method is assigned to
the product type.
The OTC Commodities product types can be customized by following the menu path Financial
OTC Derivatives → Transaction Management → Product Types → Define Product Types.

The settings at the transaction type level are the same as are at the define transaction type
customizing level for other trade types.
Processing step settings at the transaction type level:
● With or without settlement → Processing category (Define transaction types)
● Counter confirmation → Correspondence settings (Define correspondence activities)
● Deal-Release workflow → Define workflow settings
● Release cash flow → Define transaction type
Transaction Types.
Figure 776: Defining Number Ranges
For Commodities, three different types of number ranges are defined:

● Define Number Ranges for Transaction
The configuration path to set the number ranges is:

Number Ranges for Transaction.

Figure 777: Define Flow Types
The cash flow structures from commodity forwards are quite different to money market. At
the inception of the contract, no posting is made. At the maturity of the contract, the current
market value is calculated.
Assign flow types to each product type at the transaction-type level that are necessary in
order to completely portray a financial product.
classification, the category is used by the system to interpret the concrete business-
management significance of flows and conditions.
The following categories belong to the classification "terms":
● Nominal interest
● Final repayment
The following categories belong to the classification "accrual/deferral":

● Accrual Deferral
The following categories belong to the classification "valuation":

● Realized price gains and losses from foreign-currency transactions
Manager → OTC Derivatives → Transaction Management → Flow Types → Define Flow Types.

Figure 778: Assign Flow Types
In this step, all relevant cash flows which represent the basic transactional product are
assigned. Cash flows for valuation, interest accrued and derived busses transactions are not
to be assigned in this customizing activity.
The assign flow types to the product and transaction types customizing can be found by
following the customizing menu Financial Supply Chain Management → Treasury and Risk
Management →Transaction Manager → OTC Derivatives → Transaction Management → Flow
Types → Assign Flow Types to Transaction Type.
Define Product and Transaction Type Commodities
Simulation: Define Product and Transaction Type Commodities

For more information on Define Product and Transaction Type Commodities,
please view the simulation in the lesson Defining Commodity Trade Types online
in the SAP Learning Hub.

Unit 10
Exercise 43
Define Product and Transaction Type
Commodities
Business Example
A new commodity forward product type needs to be set up based on the requirements from
your front-office department.
Note:
1. Create a new product type 8## with product category 800 (commodity forward).
Product Type 8##

Long Text Commodity forward 8##
Short Text Com Fwd 8##
Product Category 800 Commodity forward
Settlement Cash Settlement
2. Assign the existing transaction type 100 (purchase) to product type 8##.
Product Type 8##
Transaction Type 100 (Purchase)
Transaction Cat 100 (Buy)
Number ranges
Transactions 01
Underlying -
Processing


tion

Unit 10
Solution 43
Define Product and Transaction Type
Commodities
Business Example
A new commodity forward product type needs to be set up based on the requirements from
your front-office department.
Note:
1. Create a new product type 8## with product category 800 (commodity forward).
Product Type 8##

Long Text Commodity forward 8##
Short Text Com Fwd 8##
Product Category 800 Commodity forward
Settlement Cash Settlement

Derivatives → Transaction Management → Product Types → Define Product Type.
b) Choose the Commodity Forwards folder.
d) Enter the data provided in the table.
e) Choose Save.
2. Assign the existing transaction type 100 (purchase) to product type 8##.
Product Type 8##

Transaction Type 100 (Purchase)
Transaction Cat 100 (Buy)
Number ranges
Transactions 01
Underlying -
Processing

tion

Derivatives → Transaction Management → Transaction Type → Define Transaction
Types.
d) Choose Save.

Assign Flow Types Commodity Product Types
Simulation: Assign Flow Types Commodity Product Types

For more information on Assign Flow Types Commodity Product Types, please
view the simulation in the lesson Defining Commodity Trade Types online in the
SAP Learning Hub.


Unit 10
Exercise 44
Business Example
Continuing with building the commodity forward product types, you now need to assign the
Dependencies
8## 100 Commodity Fwd
Note:
1. Assign to product type 8## (commodity forward) with transaction type 100 (purchase)
the following required flow types:
1004 Commodity forward -
1310 Cash settlement -
1900 Charges -

Unit 10
Solution 44
Business Example
Continuing with building the commodity forward product types, you now need to assign the
Dependencies
8## 100 Commodity Fwd
Note:
1. Assign to product type 8## (commodity forward) with transaction type 100 (purchase)
the following required flow types:
1004 Commodity forward -
1310 Cash settlement -
1900 Charges -

Derivatives → Transaction Management → Flow Types → Assign Flow Types to
Transaction Type - OTC Derivatives.
b) Assign the flow types provided in the table.
c) Choose Save.

Define Open and Close Position Commodities
Simulation: Define Open and Close Position Commodities

For more information on Define Open and Close Position Commodities, please
view the simulation in the lesson Defining Commodity Trade Types online in the
SAP Learning Hub.


Unit 10
Exercise 45
Business Example
Continuing with building the commodity forward 8## product type, you now need to update
the open and close position cash flows customizing to ensure that the system properly
manages the position for buy and sell transactions.
Dependencies
8## 100
Note:

Unit 10
Solution 45
Business Example
Continuing with building the commodity forward 8## product type, you now need to update
the open and close position cash flows customizing to ensure that the system properly
manages the position for buy and sell transactions.
Dependencies
8## 100
Note:

Derivatives → Transaction Management → Update Types → Assign Update Types for
Position Update.
b) Press the New Entries button.
c) Enter product type 8## with transaction type 100 and assign the update types
provided in the table.
d) Choose Save.

Create a Commodity Transaction
Simulation: Create a Commodity Transaction

For more information on Create a Commodity Transaction, please view the
simulation in the lesson Defining Commodity Trade Types online in the SAP
Learning Hub.


Unit 10
Exercise 46
Business Example
The creation of the commodity forward customizing is complete. Test the customizing by
creating a commodity forward trade.
To create financial transaction, select the Create Financial Transaction tile (Treasury – Trade
Processing).
Dependencies
8## 100
The flow types were assigned to the product and transaction types provided in the table.
The condition types were assigned to the interest rate swap product and transaction type
The open and close position update types were assigned.
Note:
would like to create a new financial transaction. Purchase 10 KT of steel in 2 months.
Choose business partner BP1000 or BP## (authorization is required).
Company Code TA##
Product Type 8##


DCS ID LME_STEEL_SCRAP00
Number of contracts 100
Quantity/Unit 10.000
Price/CUnit/UoM 555
Spot Price/CUnit <blank>
Cont.or Backward <blank>
Forward Date ++2
Payment Date +2

Unit 10
Solution 46
Business Example
The creation of the commodity forward customizing is complete. Test the customizing by
creating a commodity forward trade.
To create financial transaction, select the Create Financial Transaction tile (Treasury – Trade
Processing).
Dependencies
8## 100
The flow types were assigned to the product and transaction types provided in the table.
The condition types were assigned to the interest rate swap product and transaction type
The open and close position update types were assigned.
Note:
would like to create a new financial transaction. Purchase 10 KT of steel in 2 months.
Choose business partner BP1000 or BP## (authorization is required).
Company Code TA##
Product Type 8##


DCS ID LME_STEEL_SCRAP00
Number of contracts 100
Quantity/Unit 10.000
Price/CUnit/UoM 555
Spot Price/CUnit <blank>
Cont.or Backward <blank>
Forward Date ++2
Payment Date +2
b) Use the data provided in the table, Commodity Data.
c) Press the Enter key.
d) Enter the data provided in the table, Transaction Data.
e) Navigate to the Administration tab, and choose the Commodity: 001: No Valuation,
002: No Valuation general valuation class.
A portfolio selection is not required.
f) Choose Save.
Note of the transaction number for later settlement activities and posting:

LESSON SUMMARY


Unit 10
Learning Assessment
1. The Commodity Management solution provides which of the following?

X A Trade capture
X B Back-office processing
X C Direct integration to the SAP general ledger
X D Risk reporting
2. MICs represent the markets in which a commodity is traded.

X True
X False
3. Quotation groups are used to determine a security price.

X True
X False
4. Which of the following elements are specified in the definition of a Derivative Contract
Specification?
X A MIC
X B Currency
X C Number of contracts
X D Maturity date

5. Which of the following can be said about trading periods when specifying derivative
contract?
X A When specifying derivative contract, trading periods can be determined

automatically by a BAdI implementation.
X B When specifying derivative contract, trading periods are entered to configure the
automatic financial object integration.
X C When specifying derivative contract, trading periods can be used to specify one-to-
one relationship between trader name and SAP user.
X D When specifying derivative contract, trading periods are specified in the context of
the company code to ensure that the transactions can be uniquely identified.
6. Trades created in the Commodity Management solution fall into the back-office and
accounting framework of Treasury and Risk Management.
X True
X False

Customizing SHANA Treasury

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Customizing SHANA Treasury

Uploaded by

Copyright:

Available Formats

S4F51

Customizing in Treasury and Risk

© 2021 SAP SE or an SAP affiliate company. All rights reserved.

© Copyright. All rights reserved. iii

American English is the standard used in this handbook.

This information is displayed in the instructor’s presentation

Related or Additional Information

User interface control Example text

Window title Example text

iv © Copyright. All rights reserved.

1 Unit 1: Overview of Financials for SAP S/4HANA

3 Lesson: Describing SAP HANA and SAP S/4HANA

17 Unit 2: Customizing in Treasury and Risk Management in SAP S/4HANA

19 Lesson: Understanding the SAP Treasury and Risk Management

93 Unit 3: General Configuration Settings

95 Lesson: Configuring the Company Code

© Copyright. All rights reserved. v

112 Lesson: Creating Traders and Portfolios

401 Unit 5: Additional Configuration

403 Lesson: Maintaining Company Code Additional Information

vi © Copyright. All rights reserved.

432 Lesson: Configuring the Correspondence Monitor

513 Unit 7: Hedge Management and Accounting

515 Lesson: Defining Exposure Management

641 Unit 8: Market Data

642 Lesson: Defining Market Data

695 Unit 9: Risk Management

696 Lesson: Configuring the Market Risk Analyzer

© Copyright. All rights reserved. vii

791 Lesson: Understanding Commodities

viii © Copyright. All rights reserved.

© Copyright. All rights reserved. ix

● Describe SAP S/4HANA and SAP Fiori

© Copyright. All rights reserved. 1

2 © Copyright. All rights reserved.

SAP S/4HANA Core Products

Figure 1: Evolution of SAP Products

© Copyright. All rights reserved. 3

Main SAP ERP Core Products

Figure 2: Key Aspects of SAP S/4HANA

Animation: Key Aspects of SAP S/4HANA

4 © Copyright. All rights reserved.

SAP S/4HANA Product Portfolio

Figure 4: SAP S/4HANA Product Portfolio

Animation: SAP S/4HANA Product Portfolio

© Copyright. All rights reserved. 5

Core Processes within SAP S/4HANA

Figure 6: Core Processes Within SAP S/4HANA

SAP S/4HANA Enterprise Management

SAP S/4HANA Line of Business

6 © Copyright. All rights reserved.

Animation: Core Processes Within SAP S/4HANA

Evolution of the Finance Application

Figure 8: Evolution of the Finance Application

© Copyright. All rights reserved. 7

Animation: Evolution of the Finance Application

Both options were part of an SAP ERP running on a traditional database.

Overview on the Functionality of SAP S/4HANA Finance

Figure 10: Overview on the Functionality of SAP S/4HANA Finance

8 © Copyright. All rights reserved.

Animation: Overview on the Functionality of SAP S/4HANA Finance

Management Accounting in SAP S/4HANA Finance

© Copyright. All rights reserved. 9

● Product Cost Controlling